?? ?? 馬上就要回北京，兩個(gè)月的假期就這樣轉(zhuǎn)瞬即逝了，一邊修養(yǎng)生息，一邊學(xué)習(xí)新東西，因?yàn)橐骖櫺摒B(yǎng)，因此沒有很固定的時(shí)間很有計(jì)劃的學(xué)習(xí)，本來可以就很多學(xué)習(xí)內(nèi)容做些總結(jié)，也可以做一些學(xué)習(xí)筆記。但始終也沒有時(shí)間來做這些，因?yàn)榫湍骋粚ｎ}具體論述，都要經(jīng)過細(xì)推敲，于是把一些要點(diǎn)總結(jié)一下。

假期主要閱讀了下面這些書，由于每本書都很有難度，所以每本都只讀了一半，而且發(fā)現(xiàn)看一本書時(shí)忽然需要另一本書的概念支持，所以又看看別的書：

1 、 Refactoring 重構(gòu)， Martin Fowler

2 、 Design 設(shè)計(jì)模式。 GoF

3 、 UML 與模式應(yīng)用 Apply UML and Patterns ， Craig Larman

4 、 Pro Spring （在書店看了前兩章）

下面這本看了三遍，而且很多主題經(jīng)過了反復(fù)的研究并進(jìn)行了實(shí)驗(yàn)

5 、 Spring 從入門到精通，郭峰

下面這本看了兩章，但是做了實(shí)驗(yàn)

6 、精通 SOA ：基于服務(wù)總線的 Struts+EJB+Web Service 整合應(yīng)用開發(fā)，梁愛虎

?

1 、面向?qū)ο箨P(guān)鍵詞

1.1 領(lǐng)域模型（Domain Model）

領(lǐng)域模型 是對①領(lǐng)域內(nèi)的概念類或②現(xiàn)實(shí)世界中的對象的可視化表示。 [MO95 ， Fowler96]

?

1.1.1 領(lǐng)域模型是個(gè)多義詞

在 UP （更廣泛而言，在 OOA 中）領(lǐng)域模型指的是上面的概念，也就是說它是現(xiàn)實(shí)世界中對象的概念透視圖，而非軟件透視圖 (Larman 《 Apply UML and Patterns 》 ) 。 對于上面概念的詳細(xì)解釋如下，它是對于某個(gè)領(lǐng)域（比如醫(yī)藥、保險(xiǎn)、生產(chǎn)制造等）中的概念類（也就是平常所說的那些抽象概念，如思想、事物或?qū)ο蟆１热玟N售、訂貨、指令、商品（在銷售領(lǐng)域叫商品，在生產(chǎn)制造領(lǐng)域就叫產(chǎn)品，在流通領(lǐng)域叫貨品，它們都是抽象概念，這點(diǎn)與蘋果等實(shí)際的事物是有區(qū)別的）等，它們不是現(xiàn)實(shí)世界的東西，而是人們創(chuàng)造的非實(shí)物的想出來的東西。）或現(xiàn)實(shí)世界中的對象（比如汽車、蘋果）的可視化表示（通常就是用圖形進(jìn)行表示）。也就是領(lǐng)域模型的概念由兩要素組成：表示的是什么（①領(lǐng)域內(nèi)的概念類或②現(xiàn)實(shí)世界中的對象）和怎么表示（可視化表示）。我們需要注意領(lǐng)域模型的討論語義來討論它。比如在進(jìn)行 OOA 時(shí)，只需要和領(lǐng)域?qū)＜遥ǜ鼜V泛的講，接受你調(diào)查的需求提供者都應(yīng)該算作領(lǐng)域?qū)＜遥┻M(jìn)行溝通從純業(yè)務(wù)的角度來考慮該模型，而不應(yīng)該摻雜進(jìn)軟件的思想。 在這個(gè)階段，我們創(chuàng)造的是現(xiàn)實(shí)世界或領(lǐng)域內(nèi)的模型，領(lǐng)域之外或現(xiàn)實(shí)世界之外的就不要涉及。

?

領(lǐng)域模型的另一個(gè)語義則是跟軟件有關(guān)了。它指的是 軟件對象的領(lǐng)域?qū)?/span> ，在表示層或 UI 層之下的 軟件對象層 是由領(lǐng)域?qū)ο蠼M成的——領(lǐng)域?qū)ο笫潜硎締栴}領(lǐng)域空間事物的軟件對象，并且與“業(yè)務(wù)邏輯”或“領(lǐng)域邏輯”方法相關(guān)。例如，軟件類 Board 具有 getSquare 方法。 (Larman 《 Apply UML and Patterns 》 ) 。 為避免誤會，在這本書里， Larman 把該語義下的領(lǐng)域模型稱為領(lǐng)域?qū)樱?/span> Domain Layer ）。對象具有屬性和方法，這一點(diǎn)在現(xiàn)實(shí)世界或領(lǐng)域內(nèi)和在軟件語義中是相同的。

?

1.1.2 幾個(gè)概念的區(qū)別

1.1.2 .1 、領(lǐng)域模型與數(shù)據(jù)模型

?? Larman《 Apply UML and Patterns》：

領(lǐng)域模型不是數(shù)據(jù)模型 （通過對數(shù)據(jù)模型的定義來表示存儲于某處的持久性數(shù)據(jù)），所以在領(lǐng)域模型中，并不會排除需求中沒有明確要求記錄其相關(guān)信息的類（這是對關(guān)系數(shù)據(jù)庫進(jìn)行數(shù)據(jù)建模的標(biāo)準(zhǔn)，但與領(lǐng)域建模無關(guān)），也不會排除沒有屬性的概念類。例如沒有屬性的概念類是合法的，或者在領(lǐng)域內(nèi)充當(dāng)純行為角色而不是信息角色的概念類也是有效的。

從直觀感覺來說，數(shù)據(jù)模型是指包含數(shù)據(jù)和數(shù)據(jù)關(guān)系的模型，而領(lǐng)域模型是可以不包含數(shù)據(jù)的模型。從作用上來講，它們也是完全不同的，領(lǐng)域模型是用來表述領(lǐng)域的概念或現(xiàn)實(shí)中的事物的，這些事物或概念不一定要持久化，而數(shù)據(jù)模型描述的都是需要持久化的數(shù)據(jù)。

從第二點(diǎn)區(qū)別來講的話，就出現(xiàn)兩種開始設(shè)計(jì)軟件的方法：面向?qū)ο蠛兔嫦驍?shù)據(jù)。長久以來，我們（指的是筆者和筆者所在的團(tuán)隊(duì)以及周圍的團(tuán)隊(duì)）都是采用面向數(shù)據(jù)的方法開始，也就是先從畫 E-R 圖、設(shè)計(jì)數(shù)據(jù)庫結(jié)構(gòu)開始，然后再設(shè)計(jì)類層次結(jié)構(gòu)，其實(shí)這也是沒有辦法的，在學(xué)校就是這么學(xué)的，也沒有人講過怎么從面向?qū)ο箝_始。而且由于數(shù)據(jù)庫不是面向?qū)ο蟮模覀冏鲂畔⑾到y(tǒng)的很重要一點(diǎn)是要將數(shù)據(jù)保存到數(shù)據(jù)庫。

Apply UML and Patterns 這本書真是堪稱經(jīng)典， Larman 將相關(guān)概念講的十分通透，而且全書采用兩個(gè)例子來傳授敏捷 UP 的實(shí)踐過程，并且旁征博引，讓我受益匪淺。這個(gè)假期很多知識和思考都來自 Larman 這部著作。

?

1.1.2 .2 、領(lǐng)域模型與設(shè)計(jì)模型

在這里我們討論的領(lǐng)域模型都是第一個(gè)語義下的領(lǐng)域模型，因此它與設(shè)計(jì)模型的最大區(qū)別是一個(gè)是面向領(lǐng)域的，一個(gè)是軟件的。而領(lǐng)域模型的第二個(gè)概念，則主要強(qiáng)調(diào)了軟件的領(lǐng)域?qū)ο髮樱@與設(shè)計(jì)模型也是不完全相同的。對于后一種區(qū)別似乎不是很清晰，它們的區(qū)別應(yīng)該著眼于討論范圍的不同。設(shè)計(jì)模型應(yīng)該是個(gè)更宏觀的概念，而領(lǐng)域?qū)邮?b style="mso-bidi-font-weight: normal">特指在多層體系結(jié)構(gòu)中的一層（然而在我們現(xiàn)在接觸的很多項(xiàng)目自然就被設(shè)計(jì)成多層結(jié)構(gòu)的，因此大多數(shù)情況下可能體會不到其區(qū)別）。

設(shè)計(jì)模型可以從領(lǐng)域模型（第一個(gè)語義）推倒出來，你可以在 Spring 的 Sample 中看到給出的例子含有 model 文件夾，里面包含了重要的領(lǐng)域模型（第二個(gè)語義，可以看作是設(shè)計(jì)模型的一部分）。因?yàn)椴⒉皇撬械念惗际穷I(lǐng)域?qū)樱€有其他的類從其他設(shè)計(jì)模型轉(zhuǎn)化而來。

?

1.1.2 .3 、領(lǐng)域模型與領(lǐng)域規(guī)則（業(yè)務(wù)規(guī)則）

領(lǐng)域規(guī)則 [Ross97 ， GK00] 指出領(lǐng)域或業(yè)務(wù)是如何運(yùn)作的。領(lǐng)域規(guī)則通常被稱作業(yè)務(wù)規(guī)則，然而兩者是前者包含后者，后者是前者的子集的關(guān)系。在領(lǐng)域建模階段，我們會通過捕捉領(lǐng)域規(guī)則來捕獲凌駕于特定應(yīng)用之上的長期規(guī)則或政策，例如稅法。（ Larman 《 Apply UML and Patterns 》 ） 某些領(lǐng)域模型描述了領(lǐng)域規(guī)則，很多領(lǐng)域模型中還有領(lǐng)域規(guī)則。

在分層結(jié)構(gòu)中，領(lǐng)域?qū)雍蜆I(yè)務(wù)規(guī)則層往往是對應(yīng)的，比如在 Brown 分層模型、 Marinescu 分層模型中的領(lǐng)域?qū)痈?/span> Core J2EE 分層模型、 DNA 分層模型中的業(yè)務(wù)層（業(yè)務(wù)規(guī)則層）是對應(yīng)的。在叫法上斤斤計(jì)較是沒有意義的，在這里提一下主要是想明確一下各種概念的區(qū)別和聯(lián)系。

?

1.1.2 .4 、領(lǐng)域模型（領(lǐng)域?qū)樱┡c MVC 中的 Model

在《設(shè)計(jì)模式》中，對 MVC 有如下描述：在 Smalltalk-80 中，類的模型 / 視圖 / 控制器（ Model/View/Controller ）三元組（ MVC ）被用來構(gòu)建用戶界面。……模型 Model 是應(yīng)用對象，視圖 View 是它在屏幕上的表示，控制器 Controller 定義用戶界面對用戶輸入的響應(yīng)方式。在《 J2EE 核心模式》中又詳細(xì)地講解了 Model I 和 Model II ，很多書中也都將 MVC 稱為表現(xiàn)層模式。那么這里面的 Model 是不是就是領(lǐng)域模型（領(lǐng)域?qū)樱┠兀靠瓷先ズ孟窬褪沁@么回事。等有時(shí)間我再好好研究一下 MVC ，就可以解答這個(gè)問題了。

?

1.1.2 .5 、領(lǐng)域模型（層）與常見 Object

VO （ Value Object 或 View Object ）

這兩個(gè) VO 是怎么回事我沒仔細(xì)研究過，最早見到 VO 好像是在 Core J2EE Patterns 里，我的理解是 VO 就是個(gè)啞對象， Struts 中的 Form Bean 就是 VO ，它不是 Model ，不過在《 Spring 從入門到精通》（郭鋒著）將 VO 當(dāng)成領(lǐng)域模型，在 SpringFramework 的例子里，相似的代碼放在 domain 目錄下，所以我覺得 VO 可能就是個(gè)用來傳遞數(shù)據(jù)的，而不是像在《 Spring 從入門精通》中那樣，當(dāng)成 domain 。兩套程序都含有 service 目錄，但作用卻不同，在《 Spring 從入門到精通》中它是用來封裝業(yè)務(wù)邏輯的，而在 springframework 里 jpetstore 中， service 是來封裝遠(yuǎn)程服務(wù)的，而在 domain 目錄下的 logic 目錄里的文件是來封裝領(lǐng)域規(guī)則的。從前面論述的結(jié)果來看，我覺得還是 springframework 例子里的結(jié)構(gòu)比較合理（大師級的作品，經(jīng)過全世界無數(shù)大師的驗(yàn)證，而且 Rod Johnson 也是敏捷愛好者，不會犯這種錯(cuò)誤的）。關(guān)于 VO 的具體作用，我還是回去重新看看 Core J2EE Patterns 再下結(jié)論吧。

還有以前我和很多初學(xué)者很疑惑的問題，什么 TO ， PO 都是干什么的？后來也是看了 Core J2EE Patterns 才知道， TO 是傳輸對象，主要是用來在 DAO 層和 BLO 層傳遞數(shù)據(jù)的，而 PO 是持久化對象，主要是用來與數(shù)據(jù)庫表進(jìn)行一一映射的。這都屬于設(shè)計(jì)模式，但是往往被人濫用，不加分別的在同一語境下討論 DM （ Domain Model ）， VO ， TO ， POJO ， JDO ，造成了初學(xué)者的混淆。我覺得 VO 和 PO 分別被包含在了表現(xiàn)層框架和持久層框架中了，表現(xiàn)層框架中那些 FormBean 就應(yīng)該是 VO ，而 Hibernate 中所謂的那些 POJO ，就是 PO 了，而在各個(gè)層次中傳遞數(shù)據(jù)的對象都可以稱為 TO 了（更廣泛的來講）。

1.2 用例

??? 用例是圖形，不是文本。（ P46 ）

用例是文本文檔，而非圖形；用例建模主要是編寫文本的活動，而非制圖。（ P47 ）

用例就是需求，主要是說明系統(tǒng)如何工作的功能性或行為性需求。（ P48 ）

用例是一種優(yōu)秀的方法，使領(lǐng)域?qū)＜一蛐枨筇峁┱咦约壕帉懀ɑ騾⑴c編寫）用例成為可能，并使這項(xiàng)工作難度降低。用例的另一個(gè)價(jià)值是強(qiáng)調(diào)了用戶的目標(biāo)和觀點(diǎn)。（ P48 ）

我們經(jīng)常發(fā)現(xiàn)，用例建模新手（或具有嚴(yán)重 A 型行為的分析員）過于關(guān)心那些次要的問題，比如用例圖、用例關(guān)系、用例包等，而不是致力于簡單的編寫文本情節(jié)的實(shí)際工作中。 （ P48 ）

?????????????????? ???????? —— Larman 《 UML 和模式應(yīng)用（原書第 3 版）》（機(jī)工）

第一次看到 Larman 的這些話，我仿佛找到了一個(gè)出口，因?yàn)橐郧斑M(jìn)行系統(tǒng)分析時(shí)，總覺得用例圖往往只是個(gè)擺設(shè)，因?yàn)樗芎w的內(nèi)容太少了，操作契約、條件分支（在 UP 中叫擴(kuò)展，那時(shí)候不知道有什么主成功場景的說法，然后自己想當(dāng)然的像畫業(yè)務(wù)流程圖一樣分出好多枝杈，其實(shí)每個(gè)有必要說明的“枝杈”都應(yīng)該在有必要的情況下畫一個(gè)用例圖），雖然原來知道有用例文本一說（那時(shí)統(tǒng)而言之叫做用例說明），但常常以為那只是起補(bǔ)充作用的次要部分。然而看了 Larman 的講解后，才知道那些才是關(guān)鍵。正如上面引述的最后一段話所言，那的確是這兩類人最容易犯的錯(cuò)誤，我就是，過于關(guān)注用例圖而非實(shí)用的文本信息。（不過這也不能怪我，因?yàn)楫?dāng)時(shí)學(xué)習(xí)面向?qū)ο髸r(shí)，用例 = 用例圖），還記得那時(shí)在一個(gè)需求提供者面前用 Visio 畫用例圖記錄她的需求的場面，她顯然是看不懂，而在我看來當(dāng)時(shí)那些不過是糊弄外行的畫兒而已，實(shí)際作用甚微。其實(shí)書看到這我還是有很多疑問的，比如用例到底怎么寫，包含哪些要素，何時(shí)寫和寫到何種詳細(xì)程度（因?yàn)?/span> UP 中典型的初始、細(xì)化、構(gòu)造、移交階段對于用例的詳細(xì)程度是不同的，其實(shí)在敏捷 UP 中，只有一個(gè)原則——夠用就好 ~ ）。

下面也是從該書中摘錄出來的一些內(nèi)容，以備他考。

1.2.1 用例三要素

Larman 在書中并沒有給出這樣的說法，但我覺得它們組成了用例的核心部分，它們分別是參與者、場景和用例。

參與者 就是具有行為的事物，可以是人，計(jì)算機(jī)系統(tǒng)或組織。

場景 就是參與者和系統(tǒng)之間一系列特定的活動和交互。

用例 就是一組相關(guān)的成功（主成功場景和其它擴(kuò)展（替換場景））和失敗場景的集合。

1.2.2 用例參與者

????? 參與者是任何具有行為的事物， 在所討論系統(tǒng)（ System under Discussion ， SuD ）調(diào)用其它系統(tǒng)服務(wù)時(shí)，還包括其自身。

????? 參與者三種類型：主要參與者，協(xié)助參與者，幕后參與者。

???? ? 主要參與者 ：具有用戶目標(biāo)，并通過使用 SuD 的服務(wù)完成。例如收銀員。

????? 協(xié)助參與者 ：為 SuD 提供服務(wù)（例如信息服務(wù)）。自動付費(fèi)授權(quán)服務(wù)即是一類。

????? 幕后參與者 ：在用例行為中具有影響或利益，但不是主要或協(xié)助參與者。如政府稅收機(jī)構(gòu)。

1.2.3 三種常用形式

???? 它們被應(yīng)用在不同的 UP 階段。

???? 在初始階段， UP 中提出給出大多數(shù)用例的簡單描述，指的就是這種形式，叫做摘要。它只記錄主成功場景。而非正式用例也出現(xiàn)在這一階段，區(qū)別在于它是不同場景的組合描述。

???? 在初始階段提到的對 10% 需求編寫詳細(xì)用例就是指的詳述用例，它包含所有必要細(xì)節(jié)。

1.2.4 [ 詳述用例 [ 模板

???

?? 這張列表里為我解除對用例最大疑惑的就是主成功場景和擴(kuò)展（替換場景）的出現(xiàn)。它解決了我過去對于在用例中出現(xiàn)條件分支時(shí)手足無措的棘手問題。另外前置條件和成功保證（后置條件）也是相當(dāng)有用的。我覺得成功保證不是一個(gè)好的術(shù)語，它的基本意思其實(shí)是如果系統(tǒng)成功運(yùn)轉(zhuǎn)了，會產(chǎn)生什么樣的結(jié)果——如果看到這些結(jié)果同時(shí)出現(xiàn)，則保證成功了（估計(jì)成功保證這一術(shù)語就是這么來的）。

?

Larman 這本書傳遞的一個(gè)重要思想就是在必要的時(shí)候做必要的事，而且有有效果有價(jià)值，反映用戶目標(biāo)和價(jià)值。與現(xiàn)在整個(gè)軟件業(yè)講求實(shí)用的主流是一致的，正如敏捷宣言所說的那樣，簡單、有效才是最正確的。這種獲益的感覺在讀 Rod Johnson 的三部連續(xù)的巨著時(shí)也產(chǎn)生過，那是第一次聽到循證這個(gè)詞時(shí)，讓我感到了一種特別的歸屬感。我就是一個(gè)講究實(shí)用的人，而且喜歡速效的人——后來看 Martin Fowler 的書和文章，發(fā)現(xiàn)他大抵也是這么一個(gè)人。

Larman 的這本書目前剛看到第 12 章：從需求到設(shè)計(jì)——迭代進(jìn)化。其中“以迭代方式做正確的事，正確的做事”讓我想起來當(dāng)初學(xué)管理學(xué)時(shí)所講的經(jīng)典言論——做正確的事比正確的做事更加重要。這本書一個(gè) 40 章，而且有太多東西需要思考和實(shí)踐，因此看完此書估計(jì)還得有一陣子了。

1.3 類關(guān)系

繼承（ Inheritance ）： 記得好像是在 Rod Johnson 的書里將繼承分為兩類，一種是接口繼承，一種是實(shí)現(xiàn)繼承。我愿意從它們的兩個(gè)關(guān)鍵詞來理解它們，接口繼承使用 Implement 。實(shí)現(xiàn)繼承使用 Extends ，他們正好表現(xiàn)其含義，一個(gè)是實(shí)現(xiàn)接口，一個(gè)是擴(kuò)展父類。比較提倡使用接口繼承——因?yàn)樘岢嫦蚪涌诰幊獭@個(gè)應(yīng)該是業(yè)界的共識。

關(guān)聯(lián)（ Association ）： 指的是類（更精確地說，是這些類的實(shí)例）之間的關(guān)系，表示有意義和值得關(guān)注的連接。在 UML 中，關(guān)聯(lián)被定義為“兩個(gè)或多個(gè)類元之間的語義聯(lián)系，涉及這些類元實(shí)例之間的連接。”關(guān)聯(lián)有點(diǎn)像關(guān)系數(shù)據(jù)庫中的“聯(lián)系”。

1.4 依賴與依賴注入

跑去書店看了看孫衛(wèi)琴寫的《 Java 面向?qū)ο缶幊獭罚沤K于理解了“依賴”這一術(shù)語的含義（可能以前也看過，不過沒有留意）。依賴指的是類（更準(zhǔn)確說應(yīng)該是對象）之間的調(diào)用關(guān)系，在 A 類中創(chuàng)建了 B 類的實(shí)例 b ，然后調(diào)用了 b 的方法，就叫 A 依賴 B 。

???? 明白了什么是依賴，才知道了什么是依賴注入。所謂注入，指的是使用 XML 將被依賴的類注入到需要依賴的類。比如 Spring 中，在 A 類中聲明一個(gè) B 的實(shí)例，產(chǎn)生 setter ，然后在 xml 文件里一配置，就完成注入了。

?

1.5 實(shí)例與對象

不記得哪本書上寫的了，最近剛看到的，很明確的給出了實(shí)例和對象的關(guān)系——對象是類的實(shí)例。（在很多書里經(jīng)常一會對象一會實(shí)例的，而且還是在相同語境下，把我徹底搞懵了。）

?

明天接著寫下一部分：重構(gòu)和設(shè)計(jì)模式