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

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

2、ema),不過(guò)在使用這種方法產(chǎn)生的 應(yīng)用程序中，數(shù)據(jù)庫(kù)成為了關(guān)注的中心。數(shù)據(jù)庫(kù)是實(shí)現(xiàn)細(xì)節(jié)，應(yīng)該盡可能推遲考慮 數(shù)據(jù)庫(kù)。有太多的應(yīng)用程序，之所以和數(shù)據(jù)庫(kù)綁定在一起而無(wú)法分開，就是因?yàn)橐?開始設(shè)計(jì)時(shí)就把數(shù)據(jù)庫(kù)考慮在內(nèi)。請(qǐng)記住，抽象的定義，本質(zhì)部分的放大，無(wú)關(guān)緊 要部分的祛除。在項(xiàng)目的當(dāng)前階段，數(shù)據(jù)庫(kù)是無(wú)關(guān)緊要的；它只不過(guò)是用來(lái)存儲(chǔ)和 訪問(wèn)數(shù)據(jù)的技術(shù)而已。第18章薪水支付案例研究：第一次迭代開始-18.2基于 用例的分析先來(lái)考慮一下系統(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)行用例分析時(shí)，我們關(guān)注用戶素材和驗(yàn)收 測(cè)試，以找出系統(tǒng)的用戶會(huì)執(zhí)行的操作種類。接著我們會(huì)努力弄清楚系統(tǒng)怎樣去響 應(yīng)這些操作。列舉了 7個(gè)本地迭代選取的用戶素材。下面把用戶素材轉(zhuǎn)化為詳細(xì)的 用例。只要有助于考慮出每個(gè)素材的代碼設(shè)計(jì)即可，不要陷入過(guò)多的細(xì)節(jié)。第18章薪水支付案例研究：第一次迭代開始-18.2.1增加雇員根據(jù)增加雇員用 例分析操作方面：利用 COMMANDS,創(chuàng)建 AddEmployeeTransaction基類，三個(gè) 派生類 AddHourlyEmployeeTransaction、AddSalarie

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

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

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

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

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

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

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

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

12、S平面文件（flatfile）、或者OODBM現(xiàn)?，F(xiàn)在僅對(duì)API感興趣，隨后會(huì)發(fā)現(xiàn)有關(guān)數(shù)據(jù)庫(kù)的合適實(shí) 現(xiàn)。推進(jìn)有關(guān)數(shù)據(jù)庫(kù)的細(xì)節(jié)，是一項(xiàng)不常見的、但卻很值得的實(shí)踐。直到對(duì)需求有 了更多的了解，才進(jìn)行有關(guān)的數(shù)據(jù)庫(kù)的決策。通過(guò)等待，避免把過(guò)多的基礎(chǔ)結(jié)構(gòu)放 入數(shù)據(jù)庫(kù)中。我們僅僅實(shí)現(xiàn)剛好實(shí)現(xiàn)滿足應(yīng)用程序功能的數(shù)據(jù)庫(kù)。第19章薪水支付案例研究：實(shí)現(xiàn)-19.1.2使用TEMPLATE METHOD來(lái)增加雇員圖19.4,展示 了增加雇員的動(dòng)態(tài)模型。圖中， AddEmployeeTransaction向自己發(fā)送了一條消息 （SLS:調(diào)用），其子類實(shí)現(xiàn)了這條消息（SLS:方法）。這是一個(gè)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)，動(dòng)態(tài)實(shí)現(xiàn)。主要類為 DeleteEmployeeTransaction 。 第19章薪水支付案例 研究：實(shí)現(xiàn)-19.2.1全局變量對(duì)于全局變量 GpayrollDatabase ,數(shù)十年來(lái)，教科書 和教師一直有好的理由不鼓勵(lì)使用全局變量。在本例中，使用SINGLETONEMINISTATE真式具有不

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

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

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

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

18、Transaction 的測(cè)試用例。程序 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)時(shí)抽了什么煙了 PayrollDatabase應(yīng)該記錄Bill的協(xié) 會(huì)成員關(guān)系，但在UML中并沒(méi)有顯示這一點(diǎn)。SLS:也就是說(shuō)，雇員與協(xié)會(huì)這件 的關(guān)系，沒(méi)有被持久化到數(shù)據(jù)庫(kù)中。通過(guò)為 ChangeAffiliation 增加 RecordMemership(Employee*)來(lái)解決這個(gè)問(wèn)題。SLS：以前白程序 19.23 ChangeNameTransaction.cpp ,也沒(méi)有把改動(dòng)持久化啊？有點(diǎn)迷糊。 ChangeUnaffiliationTransaction是一件讓人不快的事，在 Affiliation 放入RecordMemberShip和 EraseMember

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

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

22、圖。他們希望再次運(yùn)行以便檢查錯(cuò)誤?？蛻粽f(shuō)根 本不必考慮支付時(shí)間以外的時(shí)間卡或者銷售條。登記方案被拋棄。SLS：作者寫這段的意思是，開發(fā)人員不應(yīng)該做商務(wù)覺(jué)得，要多與客戶溝通。第19章薪水支付案例研究：實(shí)現(xiàn)-19.5.2支付帶薪雇員薪水程序19.36為支付帶薪雇員的測(cè)試用 例。程序 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是一個(gè)數(shù)據(jù)類。 第 19 章薪

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

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

25、Deductions(),展 示如何計(jì)算雇員的會(huì)費(fèi)。程序19.51 ,為按小時(shí)支付雇員的會(huì)費(fèi)扣除的測(cè)試用例。 程序19.52,驗(yàn)證當(dāng)前支付之間外的會(huì)費(fèi)沒(méi)有被扣除。將判斷日期是否在某個(gè)時(shí)間 段內(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)和動(dòng)態(tài)結(jié)構(gòu)。PayrollApplication處在一個(gè)循環(huán)之中，交替從 TransactionSource獲取操作，然后執(zhí)行。Tran

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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