前言：閱讀本章，ocp原則是第一章單一職責原則的基礎上的延伸。對於構建乙個實用的穩定的類十分重要，無論使用何種設計模式，ocp原則都是我們劃分抽象類的基礎。「模組可以操作乙個抽象體。由於模組依賴於乙個固定的抽象體。所以它對於更改可以是關閉的。同時，通過從這個抽象體派生，可以擴充套件此模組的行為。」是核心思想。
「任何系統在其生命週期中都會發生變化。如果我們期望開發出的系統不會在第一版否就必須牢牢地記住這一點」那麼怎樣的設計才能面對需求的改變卻可以保持相對穩定,從而使得系統可以在第一版以後不斷推出新的版本呢?開放一封閉原則為我們提供了指引。
軟體實體(類、模組、函式)應該是厲以擴充套件的,但是不可修改的.
如果程式巾的一處改動就會產生連鎖反應,導致一系列相關模組的改動,那公設計就具有僵化性的臭味.ocp建議我們應該對系統進行重構,這樣以後對系統再進行那檉的改動時,就不會導致更多的修改,
遵循開放-封閉原則設計出的模組具有兩個主要的特徵。他們是：
1.對於擴充套件是開放的
這意味這模組行為是可以擴充套件的。當應用的需求改變時，我們可以對模組進行擴充套件，使其具有滿足那些改變的新行為。換而言之，我們可以改變模組的功能。
2.對於更改是封閉的
對模組行為進行擴充套件時，不必改動模組的源**。模組的二進位制編譯碼不必修改。
這兩個特性好像是相互矛盾的。擴充套件模組行為的通常方式就是修改該模組的源**。不允許修改的模組常常都是被認為是具有固定模式的行為。
怎樣可能在不改動模組源**的情況下去更改它的行為呢？怎樣才能在無需對模組進行改動的情況下就改變它的功能呢？
在所有oopl語言中，可以建立出固定卻能夠描述一組任意個可能行為的抽象體。這個抽象體就是抽象基類。而這一組任意個可能的行為則表現為可能的派生類。
模組可以操作乙個抽象體。由於模組依賴於乙個固定的抽象體。所以它對於更改可以是關閉的。同時，通過從這個抽象體派生，可以擴充套件此模組的行為。
下圖展示了乙個簡單的不遵循ocp原則的設計。
client類和server類都是具體的類，client類使用server類。如果我們希望client類物件使用另乙個不同的伺服器物件，那麼必須要把client類中使用server類的地方更改為新的伺服器類。（這樣就模組了我們之前的原則，設計的臭味不言而喻）
注意下圖：
上圖展示了乙個針對上述問題遵循ocp的設計。在這個設計中，clientinte***ce類是乙個擁有抽象成員函式的抽象類。client類使用這個抽象類；然而client類的物件卻是用server類的派生類物件。如果我們希望client物件使用乙個不同的伺服器物件，那麼只要從clientinte***ce類派生實現乙個新的類，不用修改client類。稍後我們會舉乙個實際的例子來表現如何進行這一抽象與分離。
也許你想知道我為何把抽象介面命名為clientinte***ce。為何不把它命名為abstractserver呢？因為（後面將會看到）抽象類和他們的客戶的關係要比和實現他們的類的關係更為密切一些。
上圖展示了另乙個可選的結構。policy類具有一組實現了某種策略的共有函式。這些策略函式使用了一些抽象介面描述了一些要完成的功能。不同的是，在這個結構中，這些抽象介面是policy類本身的一部分。這些函式在policy的子類中實現。這樣，可以通過從policy類派生出新類的方式，對policy中指定的行為進行擴充套件或者更改。（這中方式其實就是利用繼承的特性）
這兩種模式（一種是介面一種是繼承派生）是滿足ocp的最常用的方法。應用他們，可以把乙個功能的通用部分和實現細節部分清晰的分離開來。
開放 封閉原則
開放 封閉原則 the open closed principle，簡稱ocp 或者叫開 閉原則，意思是說軟體實體 類 模組 函式等等 應該可以擴充套件，但是不可修改。即對於擴充套件時開放的 open for extension 對於更改是關閉的 closed for modification 這樣...
開放封閉原則
開放封閉原則 開放封閉原則 就是軟體實體 類 模組 函式等等 應該可以擴充套件，但是不可修改。這個原則有兩個特徵，乙個是說對於擴充套件是開放的，另乙個是說對於更改時封閉的。軟實體包括 1 專案或軟體產品中按照一定的邏輯規則劃分的模組。2 抽象和類。3 方法。無論模組是多麼的封閉，都會存在一些無法對之...
開放封閉原則
開放封閉原則對於擴充套件是開放的，對於修改是封閉的。所謂開放封閉原則就是軟體實體應該對外擴充套件開發，而對修改封閉。開放封閉原則是所有物件導向原則的核心，軟體設計本身所追求的目標就是封裝變化，降低耦合，而開放封閉原則正是對這一目標最直接的體現。例如之前部落格的計算程式中，起初如果我們想要乙個加法的程...