一些面向對象的設計法則(3)

2019-11-18 11:55:27

字體：大中小

來源：轉載

供稿：網(wǎng)友

　　法則3：開放－封閉法則（OCP）
　　
　　軟件組成實體應該是可擴展的，但是不可修改的。
　　
　　[ Software Entities Should Be Open For Extension, Yet Closed For Modification
　　]
　　
　　
　　
　　
　　
　　
　　
　　
　　開放－封閉法則
　　
　　
　　
　　
　　
　　
　　1.開放-封閉法則認為我們應該試圖去設計出永遠也不需要改變的模塊。
　　
　　2我們可以添加新代碼來擴展系統(tǒng)的行為。我們不能對已有的代碼進行修改。
　　
　　3.符合OCP的模塊需滿足兩個標準：
　　
　　4.可擴展，即"對擴展是開放的"（Open For Extension）－模塊的行為可以被擴展，以需要滿足新的需求。
　　
　　5.不可更改，即"對更改是封閉的"（Closed for Modification）－模塊的源代碼是不答應進行改動的。
　　
　　6.我們能如何去做呢？
　　
　　a.抽象（Abstraction）
　　
　　b.多態(tài)（Polymorphism）
　　
　　c.繼續(xù)（Inheritance）
　　
　　d.接口（Interface）
　　
　　
　　
　　7. 一個軟件系統(tǒng)的所有模塊不可能都滿足OCP，但是我們應該努力最小化這些不滿足OCP的模塊數(shù)量。
　　
　　8.開放－封閉法則是OO設計的真正核心。
　　
　　9.符合該法則便意味著最高等級的復用性（reusability）和可維護性（maintainability）。
　　
　　OCP示例
　　
　　
　　1. 考慮下面某類的方法：
　　
　　　一些面向對象的設計法則(3)（圖一）

　　
　　2.以上函數(shù)的工作是在制訂的部件數(shù)組中計算各個部件價格的總和。
　　
　　3.若Part是一個基類或接口且使用了多態(tài)，則該類可很輕易地來適應新類型的部件，而不必對其進行修改。
　　
　　4.其將符合OCP
　　
　　
　　
　　5. 但是在計算總價格時，若財務部頒布主板和內(nèi)存應使用額外費用，則將如何去做。
　　
　　6.下列的代碼是如何來做的呢？
　　
　　　一些面向對象的設計法則(3)（圖二）

　　7.這符合OCP嗎？
　　
　　8.當每次財務部提出新的計價策略，我們都不得不要修改total　　
　　9.為了使用我們第一個版本的totalPrice()，我們可以將計價策略合并到Part的getPrice()方法中。
　　
　　
　　
　　10.這里是Part和ConcretePart類的示例：
　　
　　　一些面向對象的設計法則(3)（圖三）

　　
　　11. 但是現(xiàn)在每當計價策略發(fā)生改變，我們就必須修改Part的每個子類！
　　
　　12.一個更好的思路是采用一個PricePolicy類，通過對其進行繼續(xù)以提供不同的計價策略：
　　
　　　一些面向對象的設計法則(3)（圖四）

　　13.看起來我們所做的就是將問題推遲到另一個類中。但是使用該解決方案，我們可通過改變Part對象，在運行期間動態(tài)地來設定計價的策略。
　　
　　14.另一個解決方案是使每個ConcretePart從數(shù)據(jù)庫或屬性文件中獲取其當前的價格。
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　單選法則
　　
　　
　　
　　
　　
　　
　　單選法則（the Single Choice Principle）是OCP的一個推論。
　　
　　無論在什么時候，一個軟件系統(tǒng)必須支持一組備選項，理想情況下，在系統(tǒng)中只能有一個類能夠知道整個的備選項集合。

上一篇：一些面向對象的設計法則(1)

下一篇：一些面向對象的設計法則(4)