【正文】 有滿足那些改變的新需求。? “ 對于更改是封閉的 ” （ closed for modification）。當(dāng)對模塊進(jìn)行擴(kuò)展時(shí)，不必改動(dòng)模塊的源代碼或二進(jìn)制代碼（如 dll/jar文件）。v 自相矛盾嗎？四、面向?qū)ο笤O(shè)計(jì)原則什么是不封閉、不開放v 如下的模型可以處理月薪制（ SALARIED）和時(shí)薪制（ WAGED）職工工資，時(shí)薪制根據(jù)考勤卡計(jì)算。v 如果增加了一種新的職工類型，其計(jì)酬方式不同（如提成制），則必定要修改 Employee類（即 Employee是不封閉的），如果讓其封閉，開放擴(kuò)展又是不可能的。如何改進(jìn)v 利用抽象機(jī)制? 封閉： Employee及其已有的子類是封閉的，不可改? 開放：可以派生新的子類，實(shí)現(xiàn)新的需求，可擴(kuò)展Liscov替換原則 LSPv 實(shí)現(xiàn) OCP的主要機(jī)制是抽象和多態(tài)。怎樣設(shè)計(jì)最佳的繼承層次， BarbaraLiskov在 1988年首次提出 LSP：子類型（ subtype）必須能夠替換掉它們的基類型（ basetype）。v 假設(shè) S是 T的子類型，所有使用了 T對象的程序 (也稱客戶程序 )，用 S對象替換 T對象后，仍能成功執(zhí)行。v LSP是多態(tài)順利實(shí)現(xiàn)的保證，從而使 OCP成為可能。因?yàn)檎亲宇愋偷目商鎿Q性才使得使用基類的模塊在無需修改的情況下就可以擴(kuò)展。? 增加或修改任何一個(gè)子類型，基類不用修改（封閉）? 基類的使用者（客戶程序）通過多態(tài)得到擴(kuò)展或修改過的行為（開放）。四、面向?qū)ο笤O(shè)計(jì)原則一個(gè)使用繼承的例子v 正方形是長方形的一種特例會發(fā)生什么情況？v 正方形有獨(dú)特的行為方式v 通過覆蓋父類的有關(guān)方法來實(shí)現(xiàn)子類行為客戶程序如何能了解v 長方形的使用者按照長方形的特點(diǎn)來調(diào)用SetWidth和 SetHeight兩個(gè)函數(shù)，并測試面積，代碼如下：void testArea(Rectangleamp。 r) {(5)。(4)。assert(() == 20)。}v 如果傳遞進(jìn)來的是 Square對象又會如何呢？顯然會出現(xiàn)斷言錯(cuò)誤，測試失敗。v 對于客戶程序來說，模型中的層次結(jié)構(gòu)是脆弱的，因?yàn)檫`反了 LSP替換原則， Square對象和Rectangle對象的行為方式不相容，這樣的抽象即使采用虛函數(shù)也無法實(shí)現(xiàn)子類對父類的替換。v 違反 LSP替換原則，多態(tài)的使用是不安全的。依賴倒置原則 DIP，二者都應(yīng)該依賴于抽象（也稱針對抽象編程）；，細(xì)節(jié)應(yīng)該依賴于抽象。?結(jié)構(gòu)化設(shè)計(jì)時(shí)，高層模塊總是依賴于低層模塊。面向?qū)ο蟮姆謱幽Ｊ街幸彩歉邔拥念愐蕾囉诘讓拥念悺?按照自上而下的依賴關(guān)系，高層的策略設(shè)置模塊往往是無法重用的，如果設(shè)法讓高層模塊獨(dú)立于低層模塊，則實(shí)現(xiàn)重用就變?yōu)榭赡堋?依賴倒置原則的啟發(fā)式建議是 “ 依賴于抽象 ” ，具體做法是將高層需要的服務(wù)聲明為抽象接口，高層使用這些接口，低層模塊實(shí)現(xiàn)這些接口，使得高層不再依賴于低層，而是依賴于抽象接口，同樣低層也依賴于抽象接口。傳統(tǒng)的依賴層次v 高層使用低層的對象及其服務(wù)都依賴于抽象v 設(shè)計(jì)抽象接口，上層類使用接口，下層類實(shí)現(xiàn)接口v 這樣 Button類也可以得到重用，也許是開關(guān)燈，也許是開關(guān)電視，根據(jù)創(chuàng)建具體對象完成多態(tài)的行為。v 合成復(fù)用原則又稱為組合 /聚合復(fù)用原則(Composition/AggregateReusePrinciple,CARP)，其定義如下：v 合成復(fù)用原則：盡量使用對象組合，而不是繼承來達(dá)到復(fù)用的目的。 v 合成復(fù)用原則就是在一個(gè)新的對象里通過關(guān)聯(lián)關(guān)系（包括組合關(guān)系和聚合關(guān)系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調(diào)用已有對象的方法達(dá)到復(fù)用功能的目的。簡言之： 復(fù)用時(shí)要盡量使用組合 /聚合關(guān)系（關(guān)聯(lián)關(guān)系），少用繼承 。四、面向?qū)ο笤O(shè)計(jì)原則由于組合或聚合關(guān)系可以將已有的對象（也可稱為成員對象）納入到新對象中，使之成為新對象的一部分，因此新對象可以調(diào)用已有對象的功能，這樣做可以使得成員對象的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)對于新對象不可見，所以這種復(fù)用又稱為 “黑箱 ”復(fù)用，相對繼承關(guān)系而言，其耦合度相對較低，成員對象的變化對新對象的影響不大，可以在新對象中根據(jù)實(shí)際需要有選擇性地調(diào)用成員對象的操作；合成復(fù)用可以在運(yùn)行時(shí)動(dòng)態(tài)進(jìn)行，新對象可以動(dòng)態(tài)地引用與成員對象類型相同的其他對象。下面通過一個(gè)簡單實(shí)例來加深對合成復(fù)用原則的理解： Sunny軟件公司開發(fā)人員在初期的 CRM系統(tǒng)設(shè)計(jì)中，考慮到客戶數(shù)量不多，系統(tǒng)采用 MySQL作為數(shù)據(jù)庫，與數(shù)據(jù)庫操作有關(guān)的類如 CustomerDAO類等都需要連接數(shù)據(jù)庫，連接數(shù)據(jù)庫的方法getConnection()封裝在 DBUtil類中，由于需要重用DBUtil類的 getConnection()方法，設(shè)計(jì)人員將CustomerDAO作為 DBUtil類的子類，初始設(shè)計(jì)方案結(jié)構(gòu)如圖 1所示： 下面通過一個(gè)簡單實(shí)例來加深對合成復(fù)用原則的理解： 圖 1初始設(shè)計(jì)方案結(jié)構(gòu)圖 下面通過一個(gè)簡單實(shí)例來加深對合成復(fù)用原則的理解： 隨著客戶數(shù)量的增加，系統(tǒng)決定升級為Oracle數(shù)據(jù)庫，因此需要增加一個(gè)新的OracleDBUtil類來連接 Oracle數(shù)據(jù)庫，由于在初始設(shè)計(jì)方案中 CustomerDAO和 DBUtil之間是繼承關(guān)系，因此在更換數(shù)據(jù)庫連接方式時(shí)需要修改 CustomerDAO類的源代碼，將CustomerDAO作為 OracleDBUtil的子類，這將違反開閉原則。 【 當(dāng)然也可以修改 DBUtil類的源代碼，同樣會違反開閉原則。 】現(xiàn)使用合成復(fù)用原則對其進(jìn)行重構(gòu)。v 根據(jù)合成復(fù)用原則，我們在實(shí)現(xiàn)復(fù)用時(shí)應(yīng)該多用關(guān)聯(lián)，少用繼承。因此在本實(shí)例中我們可以使用關(guān)聯(lián)復(fù)用來取代繼承復(fù)用，重構(gòu)后的結(jié)構(gòu)如圖 2所示：圖 2重構(gòu)后的結(jié)構(gòu)圖 v 在圖 2中， CustomerDAO和 DBUtil之間的關(guān)系由繼承關(guān)系變?yōu)殛P(guān)聯(lián)關(guān)系，采用依賴注入的方式將DBUtil對象注入到 CustomerDAO中，可以使用構(gòu)造注入，也可以使用 Setter注入。如果需要對DBUtil的功能進(jìn)行擴(kuò)展，可以通過其子類來實(shí)現(xiàn)，如通過子類 OracleDBUtil來連接 Oracle數(shù)據(jù)庫。由于 CustomerDAO針對 DBUtil編程，根據(jù)里氏代換原則， DBUtil子類的對象可以覆蓋 DBUtil對象，只需在 CustomerDAO中注入子類對象即可使用子類所擴(kuò)展的方法。例如在 CustomerDAO中注入OracleDBUtil對象，即可實(shí)現(xiàn) Oracle數(shù)據(jù)庫連接，原有代碼無須進(jìn)行修改，而且還可以很靈活地增加新的數(shù)據(jù)庫連接方式。 接口隔離原則 v 接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細(xì)化接口，接口中的方法盡量少。也就是說，我們要為各個(gè)類建立專用的接口，而不要試圖去建立一個(gè)很龐大的接口供所有依賴它的類去調(diào)用。v 問題由來： 類 A通過接口 I依賴類 B，類 C通過接口 I依賴類 D，如果接口 I對于類 A和類 B來說不是最小接口，則類 B和類 D必須去實(shí)現(xiàn)他們不需要的方法。v 解決方案： 將臃腫的接口 I拆分為獨(dú)立的幾個(gè)接口，類 A和類 C分別與他們需要的接口建立依賴關(guān)系。也就是采用接口隔離原則 。 接口隔離原則 舉例來說明接口隔離原則：未遵循接口隔離原則的設(shè)計(jì) v 這個(gè)圖的意思是：類 A依賴接口 I中的方法 方法 方法 3，類B是對類 A依賴的實(shí)現(xiàn)。類 C依賴接口 I中的方法 方法 方法 5，類 D是對類 C依賴的實(shí)現(xiàn)。對于類 B和類 D來說，雖然他們都存在著用不到的方法（也就是圖中紅色字體標(biāo)記的方法），但由于實(shí)現(xiàn)了接口 I，所以也必須要實(shí)現(xiàn)這些用不到的方法。 接口隔離原則 舉例來說明接口隔離原則：遵循接口隔離原則的設(shè)計(jì) v 可以看到，如果接口過于臃腫，只要接口中出現(xiàn)的方法，不管對依賴于它的類有沒有用處，實(shí)現(xiàn)類中都必須去實(shí)現(xiàn)這些方法，這顯然不是好的設(shè)計(jì)。如果將這個(gè)設(shè)計(jì)修改為符合接口隔離原則，就必須對接口 I進(jìn)行拆分。在這里我們將原有的接口 I拆分為三個(gè)接口，拆分后的設(shè)計(jì)如圖 2所示： 采用接口隔離原則對接口進(jìn)行約束時(shí)，要注意以下幾點(diǎn)：v 接口盡量小，但是要有限度。對接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性是不掙的事實(shí)，但是如果過小，則會造成接口數(shù)量過多，使設(shè)計(jì)復(fù)雜化。所以一定要適度。v 為依賴接口的類定制服務(wù)，只暴露給調(diào)用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個(gè)模塊提供定制服務(wù)，才能建立最小的依賴關(guān)系。v 提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最多的事情。v 運(yùn)用接口隔離原則，一定要適度，接口設(shè)計(jì)的過大或過小都不好。 迪米特原則 迪米特法 則 又稱 為 最少知 識 原 則 (LeastKnowledgePrinciple,LKP)， 其定 義 如下：迪米特法 則 (LawofDemeter,LoD)：一個(gè) 軟 件 實(shí) 體 應(yīng) 當(dāng)盡可能少地與其他 實(shí) 體發(fā) 生相互作用。如果一個(gè)系統(tǒng)符合迪米特法則，那么當(dāng)其中某一個(gè)模塊發(fā)生修改時(shí)，就會盡量少地影響其他模塊，擴(kuò)展會相對容易，這是對軟件實(shí)體之間通信的限制，迪米特法則要求限制軟件實(shí)體之間通信的寬度和深度。迪米特法則可降低系統(tǒng)的耦合度，使類與類之間保持松散的耦合關(guān)系。 迪米特法則還有幾種定義形式，包括 ：不要和 “陌生人 ”說話 、 只與你的直接朋友通信 等，在迪米特法則中，對于一個(gè)對象，其朋友包括以下幾類：(1)當(dāng)前對象本身 (this)；(2)以參數(shù)形式傳入到當(dāng)前對象方法中的對象；(3)當(dāng)前對象的成員對象；(4)如果當(dāng)前對象的成員對象是一個(gè)集合，那么集合中的元素也都是朋友；(5)當(dāng)前對象所創(chuàng)建的對象。v 任何一個(gè)對象，如果滿足上面的條件之一，就是當(dāng)前對象的 “朋友 ”，否則就是 “陌生人 ”。在應(yīng)用迪米特法則時(shí)，一個(gè)對象只能與直接朋友發(fā)生交互，不要與 “陌生人 ”發(fā)生直接交互，這樣做可以降低系統(tǒng)的耦合度，一個(gè)對象的改變不會給太多其他對象帶來影響。v 迪米特法則要求我們在設(shè)計(jì)系統(tǒng)時(shí)，應(yīng)該盡量減少對象之間的交互，如果兩個(gè)對象之間不必彼此直接通信，那么這兩個(gè)對象就不應(yīng)當(dāng)發(fā)生任何直接的相互作用，如果其中的一個(gè)對象需要調(diào)用另一個(gè)對象的某一個(gè)方法的話，可以通過第三者轉(zhuǎn)發(fā)這個(gè)調(diào)用。簡言之，就是 通過引入一個(gè)合理的第三者來降低現(xiàn)有對象之間的耦合度 。v 在將迪米特法則運(yùn)用到系統(tǒng)設(shè)計(jì)中時(shí)，要注意下面的幾點(diǎn)： 在類的劃分上，應(yīng)當(dāng)盡量創(chuàng)建松耦合的類，類之間的耦合度越低，就越有利于復(fù)用，一個(gè)處在松耦合中的類一旦被修改，不會對關(guān)聯(lián)的類造成太大波及 ； 在類的結(jié)構(gòu)設(shè)計(jì)上，每一個(gè)類都應(yīng)當(dāng)盡量降低其成員變量和成員函數(shù)的訪問權(quán)限 ； 在類的設(shè)計(jì)上，只要有可能，一個(gè)類型應(yīng)當(dāng)設(shè)計(jì)成不變類 ； 在對其他類的引用上，一個(gè)對象對其他對象的引用應(yīng)當(dāng)降到最低 。下面通過一個(gè)簡單實(shí)例來加深對迪米特法則的理解： v Sunny軟件公司所開發(fā) CRM系統(tǒng)包含很多業(yè)務(wù)操作窗口，在這些窗口中，某些界面控件之間存在復(fù)雜的交互關(guān)系，一個(gè)控件事件的觸發(fā)將導(dǎo)致多個(gè)其他界面控件產(chǎn)生響應(yīng)，例如，當(dāng)一個(gè)按鈕 (Button)被單擊時(shí)，對應(yīng)的列表框 (List)、組合框 (ComboBox)、文本框 (TextBox)、文本標(biāo)簽 (Label)等都將發(fā)生改變，在初始設(shè)計(jì)方案中，界面控件之間的交互關(guān)系可簡化為如圖 1所示結(jié)構(gòu)： 初始設(shè)計(jì)方案結(jié)構(gòu)圖 在右圖中，由于界面控件之間的交互關(guān)系復(fù)雜，導(dǎo)致在該窗口中增加新的界面控件時(shí)需要修改與之交互的其他控件的源代碼，系統(tǒng)擴(kuò)展性較差，也不便于增加和刪除新控件?，F(xiàn)使用迪米特對其進(jìn)行重構(gòu)。v 在本實(shí)例中，可以通過引入一個(gè)專門用于控制界面控件交互的中間類(Mediator)來降低界面控件之間的耦合度。引入中間類之后，界面控件之間不再發(fā)生直接引用，而是將請求先轉(zhuǎn)發(fā)給中間類，再由中間類來完成對其他控件的調(diào)用。當(dāng)需要增加或刪除新的控件時(shí)，只需修改中間類即可，無須修改新增控件或已有控件的源代碼，重構(gòu)后結(jié)構(gòu)如右圖所示： 重構(gòu)后的結(jié)構(gòu)圖 如何遵守設(shè)計(jì)原則v 設(shè)計(jì)原則不是死記硬背，而是要靈活運(yùn)用v 一些成熟的設(shè)計(jì)模式可以幫助我們解決實(shí)際問題，并且符合設(shè)計(jì)原則軟件設(shè)計(jì)模式v GRASP對象職責(zé)分配模式? GRASP（ General Responsibility Assignment Software Pattern）是一組通用的基本原則和慣用的設(shè)計(jì)方案，用來指導(dǎo)對象職責(zé)的分配和交互圖的創(chuàng)建。OOAD經(jīng)典著作 《 UML和模式應(yīng)用 》 進(jìn)行了總結(jié)和應(yīng)用。 v GoF23種設(shè)計(jì)模式? 由四人組的專著 《 設(shè)計(jì)模式 》 一書總結(jié)了廣為應(yīng)用的 23種設(shè)計(jì)模式，每種模式解決了一個(gè)特定問題，包括一組合適的對象和對象接口，以及對象間協(xié)作的方式。GoF設(shè)計(jì)模式GangofFour，簡稱 GoF，他們是：v ErichGammav RichardHelmv RalphJohnsonv JohnVlissides（ 2022年底去世）著作 《 設(shè)計(jì)模式 》面向?qū)ο笙到y(tǒng)分析與設(shè)計(jì)概覽謝謝使用謝