設計乙個模組時，應當使該模組在不被修改的前提下被擴充套件，即可在不必修改源**的情況下改變該模組的行為。
陳述：
軟體實體（類、模組、函式等）應該是可以擴充套件的，同時還可以是不必修改的，更確切的說，函式實體應該：
（1）對擴充套件是開放的
當應用的需求變化時，我們可以對模組進行擴充套件，使其具有滿足改變的新的行為。即：我們可以改變模組的功能
（2）對更改是封閉的
對模組進行擴充套件時，不必改動模組已有的源**或二進位制**。
分析：
實現ocp的關鍵是抽象：
例1：既不開放也不封閉的client：
問題:
client和server都是具體類，介面與實現沒有實現分離。如果我們想要讓client呼叫乙個新的server類，那麼我們不得不修改client的源**。從而帶來編譯、鏈結、部署等一系列的問題。
class client
void useserver()
};
class server;class client
void useserver()
};
class clientinte***ce;
class server:public clientinte***ce;
其實這裡面蘊含了乙個思想：
——client類中更多的描述了高層的策略，而server類中是對這些策略的一種具體實現。
例2：
emum shapetype;
struct shape;
struct circle;
struct square;
typedef struct shape * shapepointer;
void drawallshapes(shapepointer list, int n)
}}
這個程式不符合ocp，如果需要處理的幾何圖形中再加入「三角形」將引發大量的修改。
增加********會導致shape、square、circle以及drawallshapes的重新編譯和部署
因為存在大量的既難以查詢又難以理解的switch和if語句，修改稍有不慎，程式就會莫明其妙的出錯
想在乙個程式中復用drawallshapes，都必須帶上circle、square，即使那個程式不需要他們
例2 修改後的設計：
class shape;
class square:public shape;
class circle:public shape;
void drawallshapes(vector&
list)
小結：
沒有對所有變化的情況都封閉的模型
既然不可能完全封閉，我們必須有策略的對待此問題——對模型應該封閉那類變化作出選擇，封閉最可能出現的變化
----這需要對領域的了解，豐富的經驗和常識。
--------錯誤的判斷反而不美，因為ocp需要額外的開銷（增加複雜度）
----敏捷的思想——我們**他們，但是直到我們發現他們才行動
ocp----封裝思想的體現
對可變性的封裝原則：
具體的：
相應設計模式：
《設計模式：可復用物件導向軟體的基礎》，erich gamma richard helm ralph johnson john vlissides著作，李英軍 馬曉星 蔡敏 劉建中譯，機械工業出版社，2005.6
《敏捷軟體開發：原則、模式與實踐》，robert c. martin著，鄧輝譯，清華大學出版社，2003.9
《設計模式解析》，alan shalloway等著（徐言聲譯），人民郵電出版社，2006.10
軟體設計原則 開閉原則
對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的 實現乙個熱插拔的效果。簡言之，是為了使程式的擴充套件性好，易於維護和公升級。想要達到這樣的效果，我們需要使用介面和抽象類。因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟體架構的穩定。而軟體中易變的細節可以從抽象派生來...
1 1軟體設計原則 開閉原則
開閉原則 開閉原則，對於擴充套件是開放的，對於修改是關閉。原則 1 通過介面或抽象類約束擴充套件，對擴充套件進行邊界限定 2 引數型別 引用物件盡量使用介面或者抽象類，而不是實現類 3 抽象層盡量保持穩定，一旦確定就不允許修改 4 將相同的變化封裝在乙個介面或抽象類中 5 將不同的變化封裝到不同的介...
設計模式 軟體設計原則 開閉原則
在軟體開發中，為了提高軟體系統的可維護性和可復用性，增加軟體的可擴充套件性和靈活性，程式設計師要盡量根據6條原則來開發程式，從而提高軟體開發效率 節約軟體開發成本和維護成本。對擴充套件開放，對修改關閉。在程式需要進行拓展的時候，不能去修改原有的 實現乙個熱插拔的效果。簡言之，是為了使程式的擴充套件性...