敏捷式軟體開發 (Agile Software Development)——開放—封閉原則（OCP）

標籤：敏捷式軟體開發 (Agile Software Development)

由來：

怎麼樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第一版本以後不斷推出新的版本呢？bertrand meyer 在1988年提出的著名的開發—封閉原則（the open-closed princle)為我們提供了指引。

遵循開放—封閉原則設計出的模組具有兩個主要特徵：

1. “對於擴張是開放的”（open for extension)

     這以為著模組的行為是可以擴充的。當應用的需求改變時，我們可以對模組進行擴充，使其具有滿足那些改變的行為。也就是說，我們可以改變模組的功能。

2. “對於更改是封閉的”（closed for modification）

    對模組行為進行擴充時，不必改動模組的原始碼或者二進位代碼。模組的二進位可執行版本，無論是可連結的庫、dll都無需改動。

這兩個特徵看似矛盾，怎麼可能在不改模組原始碼的情況下去更改它的行為呢？怎樣才能無需對模組進行改動的情況先就改變它的功能呢？

關鍵是抽象

在c++中，可以建立出固定卻能夠描述一組任意個可能行為的抽象體。這個抽象體就是抽象基類，而這一組人一個可以能的行為則表現為可能的衍生類別。

這個基類就是不需要修改的，裡面的成員方法（介面）聲明為純虛函數，具體的實現可以在衍生類別去實現、更改、擴充。

應用OCP，可以把一個功能通用的部分和實現細節部分清晰的分離開。

在實際應用中，設計人員必須對於他設計的模組應該對哪種變化封閉做出判斷。他必須猜測出最有可能發生變化的一些行為，然後構造抽象來隔離這些變化。

這需要設計人員具備一些從經驗中獲得預測的能力， 需要設計人員對應用領域很瞭解，能夠以此來判斷各種變化的可能性。然後，他才能設計出合理的OCP。

事實上，很難在第設計一次中就能預測出所有可能的變化，

所以，我們怎麼隔離變化呢？

1、只受一次愚弄

有句諺語：“愚弄我一次，應該感到羞愧的是你。再次愚弄到我，應該感到羞愧的是我。”這也是一種有效對待軟體設計的態度，我們會允許自己被愚弄一次。這以為著在我們最初編寫代碼時，假設不會發生變化。但變化發生時，我們就建立抽象來隔離以後發生同類的變化。簡而言之，我們願意被第一顆子彈擊中，然後我們會確保自己不會再被同一隻槍發射的其他子彈擊中。

2、刺激變化

如果我們決定接受第一顆子彈，那麼子彈到來的越早越好，我們就會越早的發現問題，解決問題。我們希望在開發工作展開不就就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要建立正確的抽象就越困難。正所謂早發現早解決

因此，我們需要去刺激變化：

    *編寫測試

    *使用很短的迭代周期進行開發

    *儘早地、經常性地發布軟體。儘可能頻繁地把軟體展示給客戶和使用人員，得到他們的反饋。

總結：

在許多方面，OCP都是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處（靈活性、可重用性以及可維護性）。然而，並不是說只要使用一種物件導向語音 就是 遵循了這個原則，對於應用程式中每個部分都肆意的進行抽象同樣不是一個好注意。正確的做法是，開發人員應該僅僅對程式中呈現出 頻繁變化的那些部分做出抽象。拒絕不成熟的抽象和抽象本身一樣重要。

敏捷式軟體開發 (Agile Software Development)——開放—封閉原則（OCP）