OCP – Open Closed Principle

軟體實體(如類別、模組、函式等等)對擴充應保持開放性,而對修改應維持封閉性

如果OCP運用得宜,未來程式中單一的變更是以增添新程式碼的方式達成,而不是修改已經運作正常的舊有程式碼

  1. Open for extension
    表示模組的行為可以加以擴充。當應用程式的需求改變時,我們可以擴充模組,使它具有能夠滿足這些變更的新行為。
  2. Closed for modification
    擴充模組的行為並不會對模組的source code或binary code造成變更,模組的binary可執行版本會聯結的.jar檔都不會變動

利用抽象化獲得明確的封閉性

Note:Strategy與Templete Method是滿足OCP最常見的手法

不論是哪一種模組,都不可能完全封閉,因此設計者必須選定他的設計要對哪一類的變更「封閉」,他必須猜測(運用經驗與對該產業使用者、需求的了解)最有可能的變更類型,並建構出抽象關念來保護自己免於變更的干擾

遵循OCP的代價是昂貴的,要花費很多時間心力來創造抽象概念,這些概念會增加軟體的複雜度,且開發人員對抽象概念的承擔力是有極限的。因此,我們希望把OCP應用在有可能發生的變更上。

為了使軟體免於不必要的複雜度,我們可以允許被愚弄一次,這表示我們最初設計時並不預期它會改變,當改變發生,我們就能實作出能使我們免於受這類未來變更所影響的抽象概念。

在繼續開發下去之前,我們想知道有可能發生哪些變更類型,找出可能發生變更的等待時間越久,就越難創造出適當的抽象概念,因此,我們可用以下方法讓改變快點發生:

  1. 優先編寫測試
  2. 極短開發週期,幾天而非幾週
  3. 先開發功能而後開發基礎建設,並經常向專案關係人展示這些功能
  4. 先開發最重要的功能
  5. 及早且經常發佈軟體,儘快經常的向客戶與使用者展現

遵循OCP會帶來物件導向宣稱最大的益處(彈性,可重用性與可維護性),但要符合此原則並非只用OOPL就能達到,做過多的抽象化也並非好主意,抗拒草率的抽象化跟抽象化本身一樣重要

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

w

連結到 %s