法則1：優先使用（對象）組合，而非（類）繼承
[ Favor Composition Over Inheritance ]
組合
n （對象）組合是一種通過創建一個組合了其它對象的對象，從而獲得新功能的複用方法。
n 將功能委託給所組合的一個對象，從而獲得新功能。
n 有些時候也稱之爲“聚合”（aggregation）或“包容”（containment），儘管有些作者對這些術語賦予了專門的含義
n 例如：
F 聚合：一個對象擁有另一個對象或對另一個對象負責（即一個對象包含另一個對象或是另一個對象的一部分），並且聚合對象和其所有者具有相同的生命週期。（譯者注：即所謂的“同生共死”關係，可參見GOF的Design Patterns: Elements of Reusable Object-Oriented Software的引言部分。）
F 包容：一種特殊類型的組合，對於其它對象而言，容器中的被包含對象是不可見的，其它對象僅能通過容器對象來訪問被包含對象。（Coad）
n 包含可以通過以下兩種方式實現：
F 根據引用（By reference）
F 根據值（By value）
n C＋＋允許根據值或引用來實現包含。
n 但是在Java中，一切皆爲對象的引用！
組合的優點和缺點
n 優點：
F 容器類僅能通過被包含對象的接口來對其進行訪問。
F “黑盒”複用，因爲被包含對象的內部細節對外是不可見。
F 對裝性好。
F 實現上的相互依賴性比較小。（譯者注：被包含對象與容器對象之間的依賴關係比較少）
F 每一個類只專注於一項任務。
F 通過獲取指向其它的具有相同類型的對象引用，可以在運行期間動態地定義（對象的）組合。
n 缺點：
F 從而導致系統中的對象過多。
F 爲了能將多個不同的對象作爲組合塊（composition block）來使用，必須仔細地對接口進行定義。
繼承
n （類）繼承是一種通過擴展一個已有對象的實現，從而獲得新功能的複用方法。
n 泛化類（超類）可以顯式地捕獲那些公共的屬性和方法。
n 特殊類（子類）則通過附加屬性和方法來進行實現的擴展。
繼承的優點和缺點
n 優點：
F 容易進行新的實現，因爲其大多數可繼承而來。
F 易於修改或擴展那些被複用的實現。
n 缺點：
F 破壞了封裝性，因爲這會將父類的實現細節暴露給子類。
F “白盒”複用，因爲父類的內部細節對於子類而言通常是可見的。
F 當父類的實現更改時，子類也不得不會隨之更改。
F 從父類繼承來的實現將不能在運行期間進行改變。
Coad規則
僅當下列的所有標準被滿足時，方可使用繼承：
n 子類表達了“是一個…的特殊類型”，而非“是一個由…所扮演的角色”。
n 子類的一個實例永遠不需要轉化（transmute）爲其它類的一個對象。
n 子類是對其父類的職責（responsibility）進行擴展，而非重寫或廢除（nullify）。
n 子類沒有對那些僅作爲一個工具類（utility class）的功能進行擴展。
n 對於一個位於實際的問題域（Problem Domain）的類而言，其子類特指一種角色（role），交易（transaction）或設備（device）。
繼承/組合示例1
n “是一個…的特殊類型”，而非“是一個由…所扮演的角色”
F 失敗。乘客是人所扮演的一種角色。代理人亦然。
n 永遠不需要轉化
F 失敗。隨着時間的發展，一個Person的子類實例可能會從Passenger轉變成Agent，再到Agent Passenger。
n 擴展，而非重寫和廢除
F 通過。
n 不要擴展一個工具類
F 通過。
n 在問題域內，特指一種角色，交易或設備
F 失敗。Person不是一種角色，交易或設備。
繼承並非適用於此處！
使用組合進行挽救！
繼承/組合示例2
n “是一個…的特殊類型”，而非“是一個由…所扮演的角色”
F 通過。乘客和代理人都是特殊類型的人所扮演的角色。
n 永遠不需要轉化
F 通過。一個Passenger對象將保持不變；Agent對象亦然。
n 擴展，而非重寫和廢除
F 通過。
n 不要擴展一個工具類
F 通過。
n 在問題域內，特指一種角色，交易或設備
F 通過。PersonRole是一種類型的角色。
繼承適用於此處！
繼承/組合示例3
n “是一個…的特殊類型”，而非“是一個由…所扮演的角色”
F 通過。預訂和購買都是一種特殊類型的交易。
n 永遠不需要轉化
F 通過。一個Reservation對象將保持不變；Purchase對象亦然。
n 擴展，而非重寫和廢除
F 通過。
n 不要擴展一個工具類
F 通過。
n 在問題域內，特指一種角色，交易或設備
F 通過。是一種交易。
繼承適用於此處！
繼承/組合示例4
n “是一個…的特殊類型”，而非“是一個由…所扮演的角色”
F 失敗。預訂不是一種特殊類型的observable。
n 永遠不需要轉化
F 通過。一個Reservation對象將保持不變。
n 擴展，而非重寫和廢除
F 通過。
n 不要擴展一個工具類
F 失敗。Observable就是一個工具類。
n 在問題域內，特指一種角色，交易或設備
F 不適用。Observable是一個工具類，並非一個問題域的類。。
繼承並非適用於此處！
繼承/組合總結
n 組合與繼承都是重要的重用方法
n 在OO開發的早期，繼承被過度地使用
n 隨着時間的發展，我們發現優先使用組合可以獲得重用性與簡單性更佳的設計
n 當然可以通過繼承，以擴充（enlarge）可用的組合類集（the set of composable classes）。
n 因此組合與繼承可以一起工作
n 但是我們的基本法則是：
優先使用對象組合，而非（類）繼承
[ Favor Composition Over Inheritance ]
法則2：針對接口編程，而非（接口的）實現
[ Program To An Interface, Not An Implementation ]
接口
n 接口是一個對象在對其它的對象進行調用時所知道的方法集合。
n 一個對象可以有多個接口（實際上，接口是對象所有方法的一個子集）
n 類型是對象的一個特定的接口。
n 不同的對象可以具有相同的類型，而且一個對象可以具有多個不同的類型。
n 一個對象僅能通過其接口才會被其它對象所瞭解。
n 某種意義上，接口是以一種非常侷限的方式，將“是一種…”表達爲“一種支持該接口的…”。
n 接口是實現插件化（pluggability）的關鍵
實現繼承和接口繼承
n 實現繼承（類繼承）：一個對象的實現是根據另一個對象的實現來定義的。
n 接口繼承（子類型化）：描述了一個對象可在什麼時候被用來替代另一個對象。
n C++的繼承機制既指類繼承，又指接口繼承。
n C++通過繼承純虛類來實現接口繼承。
n Java對接口繼承具有單獨的語言構造方式－Java接口。
n Java接口構造方式更加易於表達和實現那些專注於對象接口的設計。
接口的好處
n 優點：
F Client不必知道其使用對象的具體所屬類。
F 一個對象可以很容易地被（實現了相同接口的）的另一個對象所替換。
F 對象間的連接不必硬綁定（hardwire）到一個具體類的對象上，因此增加了靈活性。
F 鬆散藕合（loosens coupling）。
F 增加了重用的可能性。
F 提高了（對象）組合的機率，因爲被包含對象可以是任何實現了一個指定接口的類。
n 缺點：
F 設計的複雜性略有增加
（譯者注：接口表示“…像…”（LikeA）的關係，繼承表示“…是…”（IsA）的關係，組合表示“…有…”（HasA）的關係。）
接口實例
n 該方法是指其它的一些類可以進行交通工具的駕駛，而不必關心其實際上是（汽車，輪船，潛艇或是其它任何實現了IManeuverabre的對象）。
法則3：開放－封閉法則（OCP）
軟件組成實體應該是可擴展的，但是不可修改的。
[ Software Entities Should Be Open For Extension, Yet Closed For Modification ]
開放－封閉法則
n 開放-封閉法則認爲我們應該試圖去設計出永遠也不需要改變的模塊。
n 我們可以添加新代碼來擴展系統的行爲。我們不能對已有的代碼進行修改。
n 符合OCP的模塊需滿足兩個標準：
F 可擴展，即“對擴展是開放的”（Open For Extension）－模塊的行爲可以被擴展，以需要滿足新的需求。
F 不可更改，即“對更改是封閉的”（Closed for Modification）－模塊的源代碼是不允許進行改動的。
n 我們能如何去做呢？
F 抽象（Abstraction）
F 多態（Polymorphism）
F 繼承（Inheritance）
F 接口（Interface）
n 一個軟件系統的所有模塊不可能都滿足OCP，但是我們應該努力最小化這些不滿足OCP的模塊數量。
n 開放－封閉法則是OO設計的真正核心。
n 符合該法則便意味着最高等級的複用性（reusability）和可維護性（maintainability）。
OCP示例
n 考慮下面某類的方法：
n 以上函數的工作是在制訂的部件數組中計算各個部件價格的總和。
n 若Part是一個基類或接口且使用了多態，則該類可很容易地來適應新類型的部件，而不必對其進行修改。
n 其將符合OCP
n 但是在計算總價格時，若財務部頒佈主板和內存應使用額外費用，則將如何去做。
n 下列的代碼是如何來做的呢？
n 這符合OCP嗎？
n 當每次財務部提出新的計價策略，我們都不得不要修改totalPrice()方法！這並非“對更改是封閉的”。顯然，策略的變更便意味着我們不得不要在一些地方修改代碼的，因此我們該如何去做呢？
n 爲了使用我們第一個版本的totalPrice()，我們可以將計價策略合併到Part的getPrice()方法中。
n 這裏是Part和ConcretePart類的示例：
n 但是現在每當計價策略發生改變，我們就必須修改Part的每個子類！
n 一個更好的思路是採用一個PricePolicy類，通過對其進行繼承以提供不同的計價策略：
n 看起來我們所做的就是將問題推遲到另一個類中。但是使用該解決方案，我們可通過改變Part對象，在運行期間動態地來設定計價的策略。
n 另一個解決方案是使每個ConcretePart從數據庫或屬性文件中獲取其當前的價格。
單選法則
單選法則（the Single Choice Principle）是OCP的一個推論。
單選法則：
無論在什麼時候，一個軟件系統必須支持一組備選項，理想情況下，在系統中只能有一個類能夠知道整個的備選項集合。
法則4：Liskov替換法則（LSP）
使用指向基類（超類）的引用的函數，必須能夠在不知道具體派生類（子類）對象類型的情況下使用它們。
[ Function Thar Use Referennces To Base(Super) Classes Must Be Able To Use Objects Of Derived(Sub) Classes Without Knowing It ]
Liskov替換法則
n 顯而易見，Liskov替換法則（LSP）是根據我所熟知的“多態”而得出的。
n 例如：
n 方法drawShape應該可與Sharp超類的任何子類一起工作（或者，若Sharp爲Java接口，則該方法可與任何實現了Sharp接口的類一起工作）
n 但是當我們在實現子類時必須要謹慎對待，以確保我們不會無意中違背了LSP。
n 若一個函數未能滿足LSP，那麼可能是因爲它顯式地引用了超類的一些或所有子類。這樣的函數也違背了OCP，因爲當我們創建一個新的子類時，會不得不進行代碼的修改。
LSP示例
n 考慮下面Rectangle類：
n 現在，Square類會如何呢？顯然，一個正方形是一個四邊形，因此Square類應該從Rectangle類派生而來，對否？讓我們看一看！
n 觀察可得：
F 正方形不需要將高和寬都作爲屬性，但是總之它將繼承自Rectangle。因此，每一個Square對象會浪費一點內存，但這並不是一個主要問題。
F 繼承而來的setWidth()和setHeight()方法對於Square而言並非真正地適合，因爲一個正方形的高和寬是相同。因此我們將需要重寫setWidth()和setHeight()方法。不得不重寫這些簡單的方法有可能是一種不恰當的繼承使用方式。
n Square類如下：
n 看起來都還不錯。但是讓我們檢驗一下！
n 測試程序輸出：
n 看上去好像我們違背了LSP！
n 這裏的問題出在哪裏呢？編寫testLsp()方法的程序員做了一個合理的假設，即改變Rectangle的寬而保持它的高不變。
n 在將一個Square對象傳遞給這樣一個方法時產生了問題，顯然是違背了LSP
n Square和Rectangle類是相互一致和合法的。儘管程序員對基類作了合理的假設，但其所編寫的方法仍然會導致設計模型的失敗。
n 不能孤立地去看待解決方案，必須根據設計用戶所做的合理假設來看待它們。
n 一個數學意義上的正方形可能是一個四邊形，但是一個Square對象不是一個Rectangle對象，因爲一個Square對象的行爲與一個Rectangle對象的行爲是不一致的！
n 從行爲上來說，一個Square不是一個Rectangle！一個Square對象與一個Rectangle對象之間不具有多態的特徵。
總結
n Liskov替換法則（LSP）清楚地表明瞭ISA關係全部都是與行爲有關的。
n 爲了保持LSP（並與開放－封閉法則一起），所有子類必須符合使用基類的client所期望的行爲。
n 一個子類型不得具有比基類型（base type）更多的限制，可能這對於基類型來說是合法的，但是可能會因爲違背子類型的其中一個額外限制，從而違背了LSP！
n LSP保證一個子類總是能夠被用在其基類可以出現的地方！
