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

法則3：開放－封閉法則（OCP）

軟件組成實體應該是可擴展的，但是不可修改的。

[ Software Entities Should Be Open For Extension, Yet Closed For Modification
]

• 
  
• 
  

  開放－封閉法則

  
  

  
  

  
  
  1.開放-封閉法則認爲我們應該試圖去設計出永遠也不需要改變的模塊。
  
  2我們可以添加新代碼來擴展系統的行爲。我們不能對已有的代碼進行修改。
  
  3.符合OCP的模塊需滿足兩個標準：
  
  4.可擴展，即"對擴展是開放的"（Open For Extension）－模塊的行爲可以被擴展，以需要滿足新的需求。
  
  5.不可更改，即"對更改是封閉的"（Closed for Modification）－模塊的源代碼是不允許進行改動的。
  
  6.我們能如何去做呢？
  
  a.抽象（Abstraction）
  
  b.多態（Polymorphism）
  
  c.繼承（Inheritance）
  
  d.接口（Interface）

  
  

  7. 一個軟件系統的所有模塊不可能都滿足OCP，但是我們應該努力最小化這些不滿足OCP的模塊數量。
  
  8.開放－封閉法則是OO設計的真正核心。
  
  9.符合該法則便意味着最高等級的複用性（reusability）和可維護性（maintainability）。
  
  

  
  

  
  
  
• 
  

  OCP示例
  
  

  
  

  
  

  1. 考慮下面某類的方法：

  
  

  
  
  

  
  

  2.以上函數的工作是在制訂的部件數組中計算各個部件價格的總和。
  
  3.若Part是一個基類或接口且使用了多態，則該類可很容易地來適應新類型的部件，而不必對其進行修改。
  
  4.其將符合OCP

  
  

  5. 但是在計算總價格時，若財務部頒佈主板和內存應使用額外費用，則將如何去做。
  
  6.下列的代碼是如何來做的呢？

  
  

  
  
  

  
  

  7.這符合OCP嗎？
  
  8.當每次財務部提出新的計價策略，我們都不得不要修改totalPrice()方法！這並非"對更改是封閉的"。顯然，策略的變更便意味着我們不得不要在一些地方修改代碼的，因此我們該如何去做呢？
  
  9.爲了使用我們第一個版本的totalPrice()，我們可以將計價策略合併到Part的getPrice()方法中。

  
  

  10.這裏是Part和ConcretePart類的示例：
  
  

  
  

  
  

  11. 但是現在每當計價策略發生改變，我們就必須修改Part的每個子類！
  
  12.一個更好的思路是採用一個PricePolicy類，通過對其進行繼承以提供不同的計價策略：
  
  

  
  

  
  

  
  

  13.看起來我們所做的就是將問題推遲到另一個類中。但是使用該解決方案，我們可通過改變Part對象，在運行期間動態地來設定計價的策略。
  
  14.另一個解決方案是使每個ConcretePart從數據庫或屬性文件中獲取其當前的價格。
  
  

  
  

  
  
  
• 
  

  單選法則
  
  

  
  

  
  

  單選法則（the Single Choice Principle）是OCP的一個推論。
  
  無論在什麼時候，一個軟件系統必須支持一組備選項，理想情況下，在系統中只能有一個類能夠知道整個的備選項集合。