敏捷軟件開發(fā)原則模式與實(shí)踐讀書筆記3

1、精品文檔敏捷軟件開發(fā)原則、模式與實(shí)踐讀 書筆記3敏捷軟件開發(fā)：原則、模式與實(shí)踐讀書筆記 32010年04月01日星期四17: 20第18章薪水支付案例研究：第一次迭代開始第18章薪水支付案例研究：第一次迭代開始-18.1介紹本章使用的用戶素材都 是很簡單的，這是初期迭代的特征，僅提供用戶所需商業(yè)價值中最小的部分。本章 進(jìn)行快速的分析和會話設(shè)計，這通常發(fā)生在一次迭代開始時。下一章進(jìn)行實(shí)際的設(shè) 計工作，完成但愿測試和實(shí)現(xiàn)。 第18章薪水支付案例研究：第一次迭代開始- 18.1.1規(guī)格說明描述在和客戶交談時關(guān)于第一次迭代中的素材的記錄。根據(jù)用戶 素材，可以首先生成數(shù)據(jù)庫模式(database sch

2、ema),不過在使用這種方法產(chǎn)生的 應(yīng)用程序中，數(shù)據(jù)庫成為了關(guān)注的中心。數(shù)據(jù)庫是實(shí)現(xiàn)細(xì)節(jié)，應(yīng)該盡可能推遲考慮 數(shù)據(jù)庫。有太多的應(yīng)用程序，之所以和數(shù)據(jù)庫綁定在一起而無法分開，就是因?yàn)橐?開始設(shè)計時就把數(shù)據(jù)庫考慮在內(nèi)。請記住，抽象的定義，本質(zhì)部分的放大，無關(guān)緊 要部分的祛除。在項(xiàng)目的當(dāng)前階段，數(shù)據(jù)庫是無關(guān)緊要的；它只不過是用來存儲和 訪問數(shù)據(jù)的技術(shù)而已。第18章薪水支付案例研究：第一次迭代開始-18.2基于 用例的分析先來考慮一下系統(tǒng)行為，而不是系統(tǒng)的數(shù)據(jù)。一種捕獲、分析系統(tǒng)行為的方法是創(chuàng)建用例(user case)。按照最初Jacobson的描述，用例和XP中的用 戶素材的概念非常相似。用例就是

3、更詳細(xì)一點(diǎn)的用戶素材。一旦在迭代中要實(shí)現(xiàn)當(dāng) 前該用戶素材，這種詳細(xì)是合適的。在進(jìn)行用例分析時，我們關(guān)注用戶素材和驗(yàn)收 測試，以找出系統(tǒng)的用戶會執(zhí)行的操作種類。接著我們會努力弄清楚系統(tǒng)怎樣去響 應(yīng)這些操作。列舉了 7個本地迭代選取的用戶素材。下面把用戶素材轉(zhuǎn)化為詳細(xì)的 用例。只要有助于考慮出每個素材的代碼設(shè)計即可，不要陷入過多的細(xì)節(jié)。第18章薪水支付案例研究：第一次迭代開始-18.2.1增加雇員根據(jù)增加雇員用 例分析操作方面：利用 COMMANDS,創(chuàng)建 AddEmployeeTransaction基類，三個 派生類 AddHourlyEmployeeTransaction、AddSalarie

4、dEmployeeTransaction 、 AddCommissionedEmployeeTransaction。把每項(xiàng)工作戈U分至U自己的類中，遵循 SRP 原則。也可以把所有代碼放到一個模塊中，這樣就減少了類的數(shù)量，系統(tǒng)也更簡 單，但使所有的操作代碼集中于一個模塊造成龐大切可能出錯的模塊。對象模型： 抵制住記錄規(guī)劃或字段結(jié)構(gòu)等數(shù)據(jù)庫傾向的誘惑，從對象模型的角度思考：圖18.2： Employee基類，3 個派生類 HourlyEmployee、CommissionedEmployee SalariedEmployee。第18章薪水支付案例研究：第一次迭代開始-18.2.2刪除 雇員描述刪

5、除雇員用例。第18章薪水支付案例研究：第一次迭代開始-18.2.3 登記時間卡描述等級時間卡用例。用例表示，一些操作只能應(yīng)用于某類雇員。這加 強(qiáng)了不同類的雇員應(yīng)該使用不同的類表的觀點(diǎn)。第18章薪水支付案例研究：第一次迭代開始-18.2.4登記銷售憑條用例4:登記銷售憑條。與用例3類似，暗示 一些操作只能應(yīng)用于某類雇員。第18章薪水支付案例研究：第一次迭代開始-18.2.5登記協(xié)會服務(wù)費(fèi)用例5:登記協(xié)會服務(wù)費(fèi)協(xié)會會員有自己的成員標(biāo)識。第18章薪水支付案例研究：第一次迭代開始-18.2.6更改雇員明細(xì)用例6:更改雇員 明細(xì)該用例具有啟迪性。由于可以把雇員從鐘點(diǎn)工，修改為帶薪雇員。顯然圖 18.2并

6、不合適。在薪水計算中，使用 STRATEGY式也許更恰當(dāng)。圖18.6: Employee類持有一個名為Paymentclassification的對象，這個對象具有HourlyClassification 、SalariedClassification 、 CommissionedClassification 。HourlyClassification 含有 Timecard 對象歹U表。 CommissionedClassification 含有 SalesReceipt 。者B是采用了組合(composition) 方式使用STRATEGY現(xiàn)支付方式的改變。對于協(xié)會成員使用了NULL OB

7、JECT式。這些模式的使用使得系統(tǒng)很好的符合了OCP Employee對于支付方式、支付類別、協(xié)會從屬關(guān)系的變化都是封閉的。這樣，可以在不影響Employee的情況下，向系統(tǒng)增加新的支付方式，支付類別以及協(xié)會從屬關(guān)系。圖 18.6成為了我們的核 心模型，(core model)或者架構(gòu)(architecture)。是薪水支付系統(tǒng)所有事情的核 心。在薪水支付案例中的其他類和設(shè)計，相對于這個基礎(chǔ)結(jié)構(gòu)而言都是次要的。當(dāng) 然，這個結(jié)構(gòu)也會和其他部分儀一起演化。 第18章薪水支付案例研究：第一次迭代開始-18.2.7發(fā)薪日用例7現(xiàn)在運(yùn)行薪 水支付應(yīng)用程序?qū)⑿剿嬎愕娜蝿?wù)交付給PaymentClassif

8、ication 。 第18章薪水支付案例研究：第一次迭代開始-18.3反思：我們學(xué)到了什么用簡單的用力分析 可以提供豐富以及系統(tǒng)設(shè)計的洞察力。圖18.6-18.10就是通過思考這些用例得到的，更確切地說，是思考行為得到的。 第18章薪水支付案例研究：第一次迭代 開始-18.4找出潛在的抽象為了有效的OCP必須搜尋出隱藏于應(yīng)用背后的對象。 應(yīng)用需求，甚至用例，不會表達(dá)，這些抽象。需求和用例太關(guān)注細(xì)節(jié)以至于不能潛 在抽象的一般性。SLS:提煉公用組件也是這個道理。 第18章薪水支付案例研 究：第一次迭代開始-18.4.1支付薪水時間表抽象支付時間是非常多邊的。過度依 過工具和過程低估智力和經(jīng)驗(yàn)都是

9、災(zāi)難的源泉。結(jié)果是：增加PaymentSchedule,以及其3個子類對應(yīng)已知的三種方式。Employee包含了 PaymentSchedule。第 18章薪水支付案例研究：第一次迭代開始-18.4.2支付方式支付方式的抽象已經(jīng)從 18.6圖中表現(xiàn)出來了，他就是 PayMethod 第18章薪水支付案例研究：第一次 迭代開始-18.4.3從屬關(guān)系某一雇員可能屬于某一協(xié)會，但實(shí)際是一個雇員可能屬 于多個協(xié)會。結(jié)果是Employe持有Affiliation的列表，如果不屬于任何協(xié)會Affiliation列表，置空即可，不必使用 NULL OBJECT式了。第18章薪水支付案例研究：第一次迭代開始-

10、18.5結(jié)論在一次迭代開始，開發(fā)團(tuán)隊通常會聚集在 一個白板前，一起思考需要實(shí)現(xiàn)的用戶素材。這類快速設(shè)計會話持續(xù)時間會小于1小時。也許會產(chǎn)生UML但最終這些UML會留在白板上。會話的目的就是發(fā)起思 考活動，并為開發(fā)人員提供一個公共的，可依據(jù)其展開工作的智力模型，而不是為 了確定設(shè)計。本章就是一個快速設(shè)計會話的原原本本的例子。 第19章薪水支付案例研究：實(shí)現(xiàn)本章以微笑增量的方式來創(chuàng)建代碼。UMLS用于展現(xiàn)我們的想法，為交流提供媒介。圖 19.1 ,使用名為Transaction的抽象基 類代表操作。采用COMMANDS具有execute方法。第19章薪水支付案例研究:實(shí)現(xiàn)-19.1增加雇員圖19.

11、2,描述AddEmployeeTransaction的上下結(jié)構(gòu)。像 往常一樣，使用測試優(yōu)先的方法編寫代碼：程序 19.1. 第19章薪水支付案例研 究:實(shí)現(xiàn)-19.1.1薪水支付系統(tǒng)數(shù)據(jù)庫 AddEmployeeTransaction類使用了 PayrollDatabase 的類，PayrollDatabase 中保存了一 empID為鍵值的 Dictionary 。 PayrollDatabase 是 FACADE（式的列子。程序 19.3 , 19.4 該實(shí)現(xiàn)是 為了幫助通過最初的測試用例。一般而言，我們認(rèn)為數(shù)據(jù)庫實(shí)現(xiàn)是細(xì)節(jié)。應(yīng)該盡可 能推遲細(xì)節(jié)的設(shè)計決策。不管這個特定的數(shù)據(jù)庫，是RDBM

12、S平面文件（flatfile）、或者OODBM現(xiàn)。現(xiàn)在僅對API感興趣，隨后會發(fā)現(xiàn)有關(guān)數(shù)據(jù)庫的合適實(shí) 現(xiàn)。推進(jìn)有關(guān)數(shù)據(jù)庫的細(xì)節(jié)，是一項(xiàng)不常見的、但卻很值得的實(shí)踐。直到對需求有 了更多的了解，才進(jìn)行有關(guān)的數(shù)據(jù)庫的決策。通過等待，避免把過多的基礎(chǔ)結(jié)構(gòu)放 入數(shù)據(jù)庫中。我們僅僅實(shí)現(xiàn)剛好實(shí)現(xiàn)滿足應(yīng)用程序功能的數(shù)據(jù)庫。第19章薪水支付案例研究：實(shí)現(xiàn)-19.1.2使用TEMPLATE METHOD來增加雇員圖19.4,展示 了增加雇員的動態(tài)模型。圖中， AddEmployeeTransaction向自己發(fā)送了一條消息 （SLS:調(diào)用），其子類實(shí)現(xiàn)了這條消息（SLS:方法）。這是一個TEMPLATE METH

13、OD 式的應(yīng)用。程序19.5、19.6是AddEmployeeTransaction的頭文件和cpp文件。程 序19.7、19.8是AddSalariedTransaction 的頭文件和cpp文件。第19章薪水 支付案例研究：實(shí)現(xiàn)-19.2刪除雇員圖19.5、19.6中展現(xiàn)了刪除雇員操作的靜 態(tài)，動態(tài)實(shí)現(xiàn)。主要類為 DeleteEmployeeTransaction 。 第19章薪水支付案例 研究：實(shí)現(xiàn)-19.2.1全局變量對于全局變量 GpayrollDatabase ,數(shù)十年來，教科書 和教師一直有好的理由不鼓勵使用全局變量。在本例中，使用SINGLETONEMINISTATE真式具有不

14、必要復(fù)雜性的臭味。但并不認(rèn)為全局變量本身是邪惡的，本 例中就很適合使用。 第19章薪水支付案例研究：實(shí)現(xiàn)-19.3時間卡、銷售憑條以及服務(wù)費(fèi)用圖19.7、19.8展示了時間卡操作的靜態(tài)和動態(tài)結(jié)構(gòu)。主要思路：從 PayrollDatabase 得至ij Employee-PaymentClassification ,將 TimeCard放入其中。將 TimeCard放 入 PaymentClassification 中時，需要使用，dynamic_cast 操作符。程序 19.12 為測試用例。程序19.13為TimeCard的實(shí)現(xiàn)，目前就店一個數(shù)據(jù)類。程序 19.13 為TimeCardTra

15、nsaction類的實(shí)現(xiàn)。其中使用了字符串異常。這不是一個好的長期 實(shí)踐，在拋出異常時很容易出現(xiàn)泄漏內(nèi)存或資源的代碼，要注意。圖 19.9、19.10 展示了向應(yīng)支付薪水的雇員中登記銷售憑條的設(shè)計。圖19.11、19.12展示了向協(xié)會成員等級服務(wù)費(fèi)用的設(shè)計。程序19.16為測試用例，第19章薪水支付案例研 究：實(shí)現(xiàn)-19.3.1代碼與UMLB UMM沒有驗(yàn)證它的代碼是很危險的。代碼可以告 訴你UML能告訴你的設(shè)計內(nèi)容。在 UML中放入不需要的內(nèi)容，也許總有一天會用 上，但在用上之前必須要不斷的維護(hù)。所以關(guān)于員工的會員，我們從對象列表改會 NULL OBJECT式。程序 19.17、19.18

16、展示了使用 NULL OBJEC模式的 ServiceChangeTransaction 類的實(shí)現(xiàn)。第19章薪水支付案例研究：實(shí)現(xiàn)-19.4 更改雇員屬性圖19.3、19.4展示了修改雇員屬性的動態(tài)結(jié)構(gòu)，SLS:我覺得作者的設(shè)計，一直是按照一個操作一個類的方式設(shè)計的，如果這樣的設(shè)計放到很多系統(tǒng) 中，肯定會有類爆炸的問題。又t道作者沒有發(fā)現(xiàn)這個問題？圖19.15、19.16、19.17 展示了改動的動態(tài)模型。使用 TEMPLATE METHOD,從 PayrollDatabase取Employee對象的操作在基類中，然后調(diào)用自己的 change函數(shù)，在子類中實(shí)現(xiàn) change函數(shù)。程序19.19

17、展示了 ChangeNameTransaction的測試用例。程序 19.20、19.21展示了抽象基類 ChangeEmployeeTransaction的實(shí)現(xiàn)。一個明顯的 TEMPLATE METHOD。程序 19.22、19.23 展示了 ChangeNameTransaction類的 實(shí)現(xiàn)。TEMPLATE METHOD的另一半。第19章薪水支付案例研究：實(shí)現(xiàn)- 19.4.1 更改雇員類別圖 19.18-19.21 展示了 ChangeClassificationTransaction 的動態(tài)行為。又一個 TEMPLATE METHOD；。程序19.24展示了 ChangeHourly

18、Transaction 的測試用例。程序 19.24、19.25 展示了 ChangeClassificationTransaction 的實(shí)現(xiàn)。TEMPLATE METHOD。程序 19.26、19.27 展示了 ChangeHourlyTransaction 的實(shí)現(xiàn)。TEMPLATE METHOD；。 圖 19.22-19.28 展示了 ChangeMethodTransaction、 ChangeAffilicationTransaction 以及子類的 UMLH。與 ChangeClassificationTransaction 的實(shí)現(xiàn)是一脈相承的。 第19章薪水支付案 例研究：實(shí)現(xiàn)-

19、19.4.2我當(dāng)時抽了什么煙了 PayrollDatabase應(yīng)該記錄Bill的協(xié) 會成員關(guān)系，但在UML中并沒有顯示這一點(diǎn)。SLS:也就是說，雇員與協(xié)會這件 的關(guān)系，沒有被持久化到數(shù)據(jù)庫中。通過為 ChangeAffiliation 增加 RecordMemership(Employee*)來解決這個問題。SLS：以前白程序 19.23 ChangeNameTransaction.cpp ,也沒有把改動持久化??？有點(diǎn)迷糊。 ChangeUnaffiliationTransaction是一件讓人不快的事，在 Affiliation 放入RecordMemberShip和 EraseMember

20、Ship,會解決這個問題，但會讓 Affiliation 知 道PayrollDatabase也讓人不快。最終保持這個輕微違反 OCP勺設(shè)計。SLS：這 塊感覺有點(diǎn)學(xué)究氣。第19章薪水支付案例研究：實(shí)現(xiàn)-19.5支付雇員薪水圖19.29-19.33展示了支 付薪水的動態(tài)行為和靜態(tài)結(jié)構(gòu)。CalculatePay算法依賴于Employee依賴的 PaymentClassification ,是否支付日期依賴于 Empoyeefl勺 PaymentSchelue,支付 信息依賴于Employee的PaymentMethod這種高度的抽象，使得，這些算法對于 新類型的支付類別、支付薪水的時間、從屬關(guān)系

21、，以及支付方式，都可以做到封 閉。其中引入了登記的概念，也就是計算正確的支付金額，并發(fā)送給Employee后，會等級支付信息。這樣 Calculate的計算方法為從最近的支付日期到指定日期 的薪水。第19章薪水支付案例研究：實(shí)現(xiàn)-19.5.1我們希望開發(fā)人員做商務(wù)決 策嗎登記這個概念，在用戶素材中并沒有提到，只是我用這個概念解決遇到的問題 -擔(dān)心同一時間，同一日期多次調(diào)用 Payday方法，所以要確保不會出現(xiàn)多次支付 薪水的情況。我并沒有咨詢客戶。實(shí)際我做了一個商務(wù)決策，我斷定，多次運(yùn)行薪 水支付程序，會有不同的結(jié)果。其實(shí)我應(yīng)該咨詢客戶和項(xiàng)目管理人員。在和客戶的 協(xié)商中，我發(fā)現(xiàn)等級違反了客戶意

22、圖。他們希望再次運(yùn)行以便檢查錯誤?？蛻粽f根 本不必考慮支付時間以外的時間卡或者銷售條。登記方案被拋棄。SLS：作者寫這段的意思是，開發(fā)人員不應(yīng)該做商務(wù)覺得，要多與客戶溝通。第19章薪水支付案例研究：實(shí)現(xiàn)-19.5.2支付帶薪雇員薪水程序19.36為支付帶薪雇員的測試用 例。程序 19.37 為 PaydayTransaction : Execute :取得所有 Employee,并循環(huán)調(diào) 用IsPayDate方法。程序19.38為Monthshedule.cpp的部分實(shí)現(xiàn)。程序19.39為Employee： PayDay()的實(shí)現(xiàn)。SLS：注意：PayCheckM是一個數(shù)據(jù)類。 第 19 章薪

23、水支付案例研究：實(shí)現(xiàn)-19.5.3支付鐘點(diǎn)雇員薪水支付鐘點(diǎn)雇員薪水的實(shí)現(xiàn)， 是用來說明測優(yōu)先設(shè)計增量型的很好示例。我們會從最簡單的測試用例開始，直到 更加復(fù)雜的測試用例。程序19.40-19.46都為逐步增加復(fù)雜度的測試用例，以及 HourlyClassification.cpp 、WeeklySchedule.cpp 的代碼片段。第 19 章薪水支 付案例研究：實(shí)現(xiàn)-19.5.4支付期：一個設(shè)計問題本節(jié)實(shí)現(xiàn)計算會費(fèi)和服務(wù)費(fèi)的功 能。程序19.47為帶薪雇員轉(zhuǎn)變?yōu)閰f(xié)會會員后，支付其薪水。問題：用戶素材說會 費(fèi)每周提交一次，帶薪雇員的薪水是每月支付，一個月包含幾周？詢問客戶得知會費(fèi)每周五累加一次

24、。將IsInPayPeriod 函數(shù)放到HourlyClassification ,是錯誤 的。用于確定支付期的函數(shù)應(yīng)該屬于 PaymentSchedule類。UMLJEI并沒有幫我們捕 捉這個問題，再次說明代碼反饋對于設(shè)計是多么重要。程序 19.48,PaydayTransaction : Execute 程序 19.49 , PaymentClassification : IsInPayPeriod 以上兩個程序演示了，將 IsInPayPeriod A HourlyClassification 轉(zhuǎn)移出來的代碼。程序 19.50 , UnionAffiliation : Calculate

25、Deductions(),展 示如何計算雇員的會費(fèi)。程序19.51 ,為按小時支付雇員的會費(fèi)扣除的測試用例。 程序19.52,驗(yàn)證當(dāng)前支付之間外的會費(fèi)沒有被扣除。將判斷日期是否在某個時間 段內(nèi)的IsInPayPeriod 的函數(shù)放到了 Date中，改名IsBetween。程序19.53程序 19.54、19.55 展示了 Employee.h 和Employee.cpp 第19章薪水支付案例研究： 實(shí)現(xiàn)-19.6主程序圖19.34、19.35描繪了主程序的靜態(tài)和動態(tài)結(jié)構(gòu)。PayrollApplication處在一個循環(huán)之中，交替從 TransactionSource獲取操作，然后執(zhí)行。Tran

26、sactionSource是一個抽象類，可以有各種實(shí)現(xiàn)，圖中為TextTransactionSource 。TransactionSource 中接口和實(shí)現(xiàn)的分離使操作的來源 可以成為抽象的。例如： GUITransactionSource、RemoteTransactionSource 第 19章薪水支付案例研究：實(shí)現(xiàn)-19.7數(shù)據(jù)庫在完成了本次的迭代中的分析、設(shè)計、 實(shí)現(xiàn)工作后，可以考慮數(shù)據(jù)庫了。可以使用OODBMS實(shí)現(xiàn)PayrollDatabase ,對應(yīng)用程序的對象模型沒有影響?？梢允褂闷矫嫖募?，實(shí)現(xiàn) PayrollDatabase，但 對于大量數(shù)據(jù)或并發(fā)訪問的應(yīng)用來講，則無法滿足需

27、求。可以使用RDBMS實(shí)現(xiàn)PayrollDatabase 。關(guān)鍵在于，數(shù)據(jù)庫只是管理存儲的機(jī)制。通常不應(yīng)該作為設(shè)計 和實(shí)現(xiàn)的主要因素。流到最后，作為細(xì)節(jié)處理。這樣實(shí)現(xiàn)持久化功能時，我們就會 有很多方案可供選擇。也沒有和任何數(shù)據(jù)庫或產(chǎn)品綁定，我們可以選擇，替換數(shù)據(jù) 庫。設(shè)計者應(yīng)該解除設(shè)計和數(shù)據(jù)庫之間的耦合，應(yīng)用設(shè)計不應(yīng)該依賴于任何特定的 數(shù)據(jù)庫。SLS:我覺得上邊的觀點(diǎn)，是極端的面向?qū)ο笥^點(diǎn)，或叫極端的設(shè)計觀 點(diǎn)。實(shí)際使用時，這樣設(shè)計會導(dǎo)致巨大的不必要的復(fù)雜性。數(shù)據(jù)庫應(yīng)用，還是面向 數(shù)據(jù)庫比較好。沒想到看著面向?qū)ο笤O(shè)計的書，卻要不使用面向?qū)ο笤O(shè)計。首先我 們的目的，是為了滿足客戶需求，而不是做面

28、向?qū)ο笤O(shè)計，所以，應(yīng)該有一套面向 數(shù)據(jù)庫的設(shè)計方法。我們不應(yīng)該為了面向?qū)ο蠖ッ嫦驅(qū)ο?。就像前邊一直有所?述的“知道何時不運(yùn)用運(yùn)行一個設(shè)計原則、模式或最佳實(shí)踐，比知道如何運(yùn)用它同 樣重要”，第二章一開始也說，XP并不是唯一的選擇。同樣，面向?qū)ο笠膊皇俏ㄒ?的選擇，或者我們可以選擇面向數(shù)據(jù)庫設(shè)計 ？知道何時不運(yùn)用面向?qū)ο笤O(shè)計也同樣 重要。當(dāng)然，作者是在講面向?qū)ο笤O(shè)計，不可能突然將，面向數(shù)據(jù)庫方面的設(shè)計， 但面向數(shù)據(jù)庫的設(shè)計也值得研究。第19章薪水支付案例研究：實(shí)現(xiàn)-19.8薪水支付系統(tǒng)設(shè)計總計由于使用了大量的抽象和多態(tài)，使得絕大部分設(shè)計對于薪水支 付策略更改做了封閉。在這個過程中，我們很少考慮

29、我們是否在進(jìn)行分析、設(shè)計、 實(shí)現(xiàn)（SLS:意思是沒有考慮處于哪個階段），相反，我們?nèi)褙炞⒂谇宄头忾]問 題。盡力找出潛在的抽象。最終，我們獲得一個薪水支付應(yīng)用的初始設(shè)計，并且擁 有了一組在整體上和問題域密切關(guān)聯(lián)的核心類。SLS:對于18章，圖18.6薪水支付的核心模型，是通過分析行為得到的靜態(tài)結(jié)構(gòu)。我覺得這個結(jié)構(gòu)是簡潔的。但 19章，由于使用了 COMMANDS,導(dǎo)致了類爆炸，增加了復(fù)雜性。當(dāng)然，使用 COMMA得了巨大的好處，19.6主程序?qū)@種好處有所闡述。SLS:對于 本例，我覺作者的目的，是要獲得一組在整體上和問題域密切關(guān)聯(lián)的核心類,所 以作者沒有考慮數(shù)據(jù)庫和界面。而這種去界面，去數(shù)

30、據(jù)庫的“一組核心類”是對問題域的高度抽象，由于其巨大的可擴(kuò)展性，所以在以后的設(shè)計中，非常值得借鑒。至 于”面向數(shù)據(jù)庫設(shè)計“那是另一碼事。第19章薪水支付案例研究：實(shí)現(xiàn)-19.8.1 歷史講述，本例子的歷史，是1994年就創(chuàng)建了圖示，并在1995年出版的一本書中 使用。但由于當(dāng)時沒有代碼反饋，所以犯了一些錯誤。從而凸顯出，代碼反饋的重 要性。第19章薪水支付案例研究：實(shí)現(xiàn)-19.8.2資源 第IV部分打包薪水支付系統(tǒng)本章部分研究把大的軟件系統(tǒng)分割成包的設(shè)計原則。第20章包的設(shè)計原則優(yōu)美的包裹-安東尼類對于小的應(yīng)用程序來說是非常方便 的組織單元，但對于應(yīng)用程序規(guī)模和復(fù)雜度比較高的程序，需要在更高的

31、層次對應(yīng) 用程序進(jìn)行組織，那就是包。本章講述6個原則，前三個關(guān)注包的內(nèi)聚性，如何 把類劃分到包中，后三個關(guān)注包的耦合性（確定包之間的關(guān)系），最后兩個還描述了 一組依賴性管理度量，據(jù)此對設(shè)計中的依賴結(jié)構(gòu)進(jìn)行度量。第20章包的設(shè)計原則-20.1如何進(jìn)行包的設(shè)計UM葉包可以是類的容器。把類組織成包，可以在更高 的層次理解設(shè)計。根據(jù)一些原則對應(yīng)用程序的類進(jìn)行劃分?？绨念惖囊蕾囮P(guān)系， 導(dǎo)致了包之間的依賴關(guān)系，這就提出了如下幾個問題：1.想包中分配類時應(yīng)該依據(jù)什么原則？2.應(yīng)該使用什么設(shè)計原則管理包之間的關(guān)系 ？3.包的設(shè)計應(yīng)該先于類（自 頂向下）？還是類的設(shè)計先于包（自底向上）?4.如何實(shí)際表現(xiàn)出包?

32、C+中，JAVA 中，其他環(huán)境5.包創(chuàng)建好后，應(yīng)該用于何種目的？第20章包的設(shè)計原則-20.2粒 度：包的內(nèi)聚性原則本節(jié)講述包的內(nèi)聚性的三個原則，幫助開發(fā)者把類劃分到包 中。這些原則依賴于：至少存在一些類，并且他們之間的關(guān)系已經(jīng)確定。這些原則 是依據(jù)自底向上的觀點(diǎn)劃分的。第20章包的設(shè)計原則-20.2.1重用發(fā)布等價 原則RE的重用發(fā)布等價原則當(dāng)重用一個類庫時，對這個類庫的作者的期望當(dāng)然 是：好的文檔、可工作的代碼、規(guī)格清晰的接口。但除了這些還有：首先，希望代 碼作者這保證維護(hù)代碼。其次，希望代碼作者計劃修改接口和功能等改動時，通知 你。但僅僅是通知是不夠的，要允許你具有不使用新版本的權(quán)利。當(dāng)

33、不使用新版本 時，必須對舊版本繼續(xù)提供支持。這是一個行政問題。REP旨出，一個包的重用粒度可以和發(fā)布粒度一樣大。重用的東西必須被同時發(fā)布和跟蹤。簡單的聲稱重用是 不夠的，要建立一個跟蹤系統(tǒng)，為潛在的使用者提供需要的變更通知，安全性，支 持后，重用才有可能。REP合我們關(guān)于如何把設(shè)計劃分到包中的第一個提示，由于 重用性必須是基于包的，所以可重用的包，必須基于可重用的類，因此該包必須有 可重用的類組成。我們必須從重用者的角度考慮包的內(nèi)容，如果包中的軟件是為了可重用的，那么他就不能包含不是為重用目的而設(shè)計的軟件。一個包中的軟件要么 都是可重用的，要么都不是可重用的。SLS:為包的使用者提供一個干凈的

34、純粹的用于重用的包。但這好像和共同重用原則一樣。對于這個原則，我理解為，重用 和發(fā)布一樣重要。要重用就要配合發(fā)布，跟蹤等。但這和包的劃分有什么關(guān)系 呢？ SLS:網(wǎng)絡(luò)資料的輔助理解：OOS計模式和設(shè)計原則一個可重用的元件（組 件、一個類、一組類等），只有在它們被某種發(fā)布（Release）系統(tǒng)管理以后，才能被 重用。將什么類放在一個包中的判斷標(biāo)準(zhǔn)之一就是重用，并且因?yàn)榘前l(fā)布的最小 單元，它們同樣也是重用的最小單元。體系結(jié)構(gòu)師應(yīng)該將可重用的類都放在包中。 SLS: REPfc要講述重用和發(fā)布的關(guān)系，同時指出將重用的類都放在包中。CR比指那些放入包中的可重用的類，都要為了一個目的而重用。第20章包

35、的設(shè)計原則-20.2.2共同重用原則CRPr一個包中的所有類都應(yīng)該是共同重用的。如果重用 了包中的一個類，那么就要重用包中的所有類。這一原則，決定哪些類放入同一個 包中。規(guī)定趨向共同重用的類應(yīng)該屬于同一個包。簡稱 CRP止匕外，包經(jīng)常以共享 庫、DLL jar等物理表示的形式出現(xiàn)。當(dāng)我依賴于一個包，我將依賴于包中的每 一個類。防止包中與我無關(guān)的修改導(dǎo)致重新驗(yàn)證和發(fā)行。第20章包的設(shè)計原則-20.2.3共同封閉原則CCPr包中的所有類，對于同一類性質(zhì)的變化應(yīng)該是共同封閉 的。一個變化若對一個包產(chǎn)生影響，將對包中的所有類產(chǎn)生影響，而對于其他的包 中的類不產(chǎn)生任何影響。簡稱 CCP這是單一職責(zé)對于包

36、的重新規(guī)定。這一原則規(guī) 定，對于包，不應(yīng)該包含多個引起其變化的原因。在大多數(shù)應(yīng)用程序中，可維護(hù)性 的重要性要大于可重用性。如果一個應(yīng)用中的代碼必須修改，那么我們更改都集中 在一個包中。CC限勵由于同樣原因而更改的所有類聚集在同一個地方。以減少軟 件的發(fā)布、重新驗(yàn)證、重新發(fā)行的工作量。這個原則和開放封閉原則密切相關(guān)。但 正如我們學(xué)的的，100%寸閉是不可能做到的，應(yīng)該有策略的進(jìn)行封閉。我們設(shè)計的 系統(tǒng)應(yīng)該對于我們最常見的變化做到封閉。第20章包的設(shè)計原則-20.2.4包的內(nèi)聚性過去，我們隊內(nèi)聚性的認(rèn)識，遠(yuǎn)比上面 3個原則所蘊(yùn)含的簡單。我們習(xí)慣于 認(rèn)為內(nèi)聚性，不過是一個模塊執(zhí)行一項(xiàng)并且僅能執(zhí)行一項(xiàng)

37、功能。在選擇共同組織到 包中的類時，必須考慮重用性和可開發(fā)性之間的相反作用力。這不是一個簡單的工 作。并且這個作用力是動態(tài)的。今天關(guān)注可開發(fā)行，明天可能關(guān)注可重用性。 SLS:我理解可開發(fā)行為，是一個相對于重用性的概念。就是只關(guān)注當(dāng)前功能的 實(shí)現(xiàn)。而不是重用。就叫可開發(fā)性?？赡軐?shí)際開發(fā)效率。如果關(guān)注可重用性，從重 用多角度增加功能點(diǎn)。SLS:軟件行業(yè)呼喚可開發(fā)性設(shè)計，DFD（Design for Developability ,可開發(fā)性設(shè)計）簡單說來，可開發(fā)性設(shè)計就是我們在開發(fā)一個軟 件（相關(guān)）產(chǎn)品時，軟件的設(shè)計應(yīng)當(dāng)考慮方便開發(fā)人員（大部分情況下就是我們自己） 進(jìn)行開發(fā)，或者說在設(shè)計時應(yīng)考慮如

38、何提高開發(fā)效率。DFMM1 Design forManufacturability（ 可制造性設(shè)計）的簡稱，主要研究產(chǎn)品本身的物理設(shè)計與制造 系統(tǒng)各部分之間的相互關(guān)系，并把它用于產(chǎn)品設(shè)計中以便將整個制造系統(tǒng)融合在一 起進(jìn)行總體優(yōu)化。DFMP以降低產(chǎn)品的開發(fā)周期和成本，使之能更順利地投入生產(chǎn) 第20章包的設(shè)計原則-20.3穩(wěn)定性：包的耦合性原則我們會再次看到，可開發(fā) 性和邏輯設(shè)計之間的沖突，來自技術(shù)和行政方面的作用力會影響包的組織結(jié)構(gòu)，這 種作用力，還是易變的。 第20章包的設(shè)計原則-20.3.1無環(huán)依賴原則AD的在包 的依賴關(guān)系圖中，不允許存在環(huán)?！俺亢缶C合癥：造成來后，因?yàn)槠渌伦蛲韺?代

39、碼的修改，導(dǎo)致自己的程序出現(xiàn)問題。在幾個開發(fā)人員的小項(xiàng)目中，這不是大問 題。但當(dāng)開發(fā)團(tuán)隊的規(guī)模增長時，就會帶來噩夢。在缺乏紀(jì)律的團(tuán)隊中，幾周都無 法構(gòu)建出一個穩(wěn)定的項(xiàng)目版本是很常見的。每個人都在忙于修改代碼以適應(yīng)別人的 代碼。對于這種問題的解決方法有：每周構(gòu)建， ADP 第20章包的設(shè)計原則- 20.3.2每周構(gòu)建每周構(gòu)建嘗嘗應(yīng)用在中等規(guī)模的項(xiàng)目中：每周前四天各自工作， 互不打擾。周五集成。糟糕的是，隨著項(xiàng)目的增長，集成工作量越來越大。從而導(dǎo) 致效率下降，導(dǎo)致危機(jī)。第20章包的設(shè)計原則-20.3.3消除依賴環(huán)通過把開發(fā) 環(huán)境劃分為可發(fā)布的包可以解決上述問題。這些包可以作為工作單元拆分出來。每

40、個工作單元都收版本控制，都有發(fā)布。其他團(tuán)隊會可以決定是否采用其他團(tuán)隊的新 版本。這是一個非常簡單合理的過程，并被廣泛使用。要使這個方法起效。包的依 賴關(guān)系中不能存在環(huán)。SLS:上述方法，對每個單元都建立版本，會增加版本控 制的工作量，對于超大的項(xiàng)目也許合適。我認(rèn)為由架構(gòu)師，從總體的角度劃分包， 劃分包之間的結(jié)構(gòu)，是解決這個這個問題的更好的方法。也許是敏捷開發(fā)不允許架 構(gòu)師的存在，所以作者沒有提到這個問題。圖 20.1包結(jié)構(gòu)是有向無環(huán)圖。這類表 明包之間依賴關(guān)系的圖，非常好。第20章包的設(shè)計原則-20.3.4包的依賴關(guān)系 圖中環(huán)造成的影響依賴環(huán)，會導(dǎo)致這些有依賴關(guān)系的包，編程一個大包。從而影響

41、發(fā)布，造成相互影響。單元測試和發(fā)布非常困難，容易出錯。難于確定構(gòu)建關(guān)系。第20章包的設(shè)計原則-20.3.5解除依賴環(huán)將依賴關(guān)系圖恢復(fù)為 DAG勺方法：1. 使用依賴導(dǎo)致。從客戶角度（函數(shù)調(diào)用者），而不是服務(wù)者（函數(shù)提供者）的角度命名 接口。是接口屬于客戶規(guī)則的又一應(yīng)用。2.將組成環(huán)的包，合并為一個包。 第 20章包的設(shè)計原則-20.3.6抖動第二個方案意味著，在需求改變面前，包的結(jié)構(gòu)是 不穩(wěn)定的。第20章包的設(shè)計原則-20.4自頂向下設(shè)計現(xiàn)在可以得出結(jié)論：不能 自頂向下的設(shè)計包的結(jié)構(gòu)。這意味著包的結(jié)構(gòu)，不是設(shè)計系統(tǒng)首先考慮的事情之 一，事實(shí)上，包的結(jié)構(gòu)，應(yīng)該是隨著系統(tǒng)的增長、變化而逐步演化的。

42、也許這違反 直覺，我們已經(jīng)認(rèn)為包這樣的大粒度分解，也是高層功能分解。事實(shí)上，包的依賴 關(guān)系圖，幾乎和描述應(yīng)用程序功能之間，沒有關(guān)系。項(xiàng)目開始無軟件可構(gòu)件，就沒 有關(guān)系圖。隨著項(xiàng)目規(guī)模的增長，不斷使用 SRP CCP ADP等同類放到一個包中， 關(guān)注重用，去掉依賴環(huán)。包的依賴關(guān)系，是和系統(tǒng)邏輯設(shè)計一同增長和演化的。第20章包的設(shè)計原則-20.5穩(wěn)定依賴原則SDPr朝著穩(wěn)定的方向進(jìn)行依賴設(shè)計不 能是固定的，設(shè)計的可維護(hù)和某種程度的易變性是必要的。通過共同封閉原則，我 們創(chuàng)建變化敏感型的包，這些包期待變化。對于任何包而言，如果其時可變的，就 不能讓難于改變的包依賴它。這會導(dǎo)致一邊包的難以改變。通過

43、SDP要確保易于 更改的包不會被難于更改的包所依賴。第20章包的設(shè)計原則-20.5.1穩(wěn)定性硬幣豎在桌子上，我們認(rèn)為它是不穩(wěn)定的。雖然沒有人碰他，他不會倒?？梢姺€(wěn)定性 與變化的頻率（不碰硬幣他不會動）沒有直接關(guān)系。韋伯斯特認(rèn)為：”不容易被移 動，被認(rèn)為是穩(wěn)定穩(wěn)定性和更改所需要的工作量有關(guān)。對于軟件來說，被依賴的 包越多，那么這個包就應(yīng)該越穩(wěn)定。因?yàn)橐蕾囮P(guān)系導(dǎo)致改動的工作量變大。第20章包的設(shè)計原則-20.5.2穩(wěn)定性度量度量一個包的穩(wěn)定性：計算該包進(jìn)出依賴關(guān) 系的數(shù)目。不穩(wěn)定性I二輸出耦合度（處于該包內(nèi)部并依賴該包外類的數(shù)目）/輸入耦 合度（處于該包外部并依賴該包類的數(shù)目）+輸出耦合度。箭頭所

44、指是被依賴者。1=0最大穩(wěn)定性。C+”，通過計算#include語句表示。java中計算import 。 SPD 定，一個包的I的度量值應(yīng)該大于它所依賴的包的I度量值。也即是說I應(yīng)該順著 依賴的方向減小。第20章包的設(shè)計原則-20.5.3并非所有的包都應(yīng)該是穩(wěn)定的 如果一個系統(tǒng)中所有的包都是最大程度的問題，那么這個系統(tǒng)是不可變的。這并不 是希望的事情。我們希望系統(tǒng)中，一些包是穩(wěn)定的，一些是不穩(wěn)定的。可變色位于 頂部，依賴于底部穩(wěn)定的包。這樣向上的箭頭意味著違反SDP 第20章包的設(shè)計原則-20.5.4在那里放置高層設(shè)計系統(tǒng)中，某些軟件并不經(jīng)常改變，改軟件代表 系統(tǒng)的高層架構(gòu)和設(shè)計決策。我們希望

45、這些架構(gòu)覺得是穩(wěn)定的。然而，如果把高層 設(shè)計放入穩(wěn)定的包中，那么體現(xiàn)高層設(shè)計的源代碼會很難改變，這樣又不具有靈活 性。怎樣具有最高穩(wěn)定性，又具有靈活性 ？OC就是答案，抽象類符合OCP 第 20章包的設(shè)計原則-20.6穩(wěn)定抽象原則SA的包的抽象，應(yīng)該和其穩(wěn)定程度一致。 該原則將穩(wěn)定性和抽象性聯(lián)系起來。該規(guī)則規(guī)定：穩(wěn)定的包應(yīng)該是抽象的，這樣他 的穩(wěn)定性就不會使其無法擴(kuò)展。不穩(wěn)定的包應(yīng)該是具體的，因?yàn)椴环€(wěn)定性使其內(nèi)部 代碼易于更改。SD濟(jì)口 SAP在一起，形成了針對包的DIP原則。結(jié)論是，依賴應(yīng)該 朝抽象的方向進(jìn)行。DIP是一個處理類的原則，類沒有灰度的概念。類要么是抽 象，要么是具體的。第20章

46、包的設(shè)計原則-20.6.1抽象性度量抽象性A才由象類 的數(shù)目/包中類的總數(shù)第20章包的設(shè)計原則-20.6.2主序列現(xiàn)在我們定義不穩(wěn)定 性I和抽象性A的關(guān)系，創(chuàng)建一個以A為縱軸，I為橫軸的坐標(biāo)圖，在坐標(biāo)圖中兩 種好的包的類型。最穩(wěn)定最抽象的包位于左上角，最不穩(wěn)定最具體的包位于右下 角。位于（0,0）附近的被稱為痛苦地帶。高度穩(wěn)定且具體的。應(yīng)該注意，數(shù)據(jù)庫模 式就是這樣的一個例子。數(shù)據(jù)庫模式的異變眾所周之 （SLS:就算使用數(shù)據(jù)類，也依 然是異變的）并且他是非常具體，高度被依賴的。這就是為什么面向?qū)ο髴?yīng)用程序 和數(shù)據(jù)庫之間的接口難以定義，以及數(shù)據(jù)庫模式更新通常都很痛苦的原因。還有工 具庫也位于（0,0）位于（1,1）附近的被稱為無用地帶，抽象，但不被依賴。主序列： （1,0）至（0,1）的線。（命名來自作者對天文學(xué)和HR圖（赫羅圖橫行真實(shí)亮度與表面 問的的關(guān)系）第20章包的設(shè)計原則-20.6.3到主序列的距離度量包到主序列的 距離。距離D=|A+L-1/根號二規(guī)范化距離D=|A+L-1|使用這個度量，可以全面分析 一個設(shè)計和主序