第2節物件導向設計原則

變化是復用的天敵，oop設計的最大優勢在於抵禦變化！

理解隔離化：巨集觀來講，oop方式能夠將變化所帶來的影響減為最小;

各司其職：微觀上看，oop更強調各個類的職責，由於需求的變化導致新增型別不改變原來的實現

物件是什麼：

1.1  高層模組(穩定)應該應依賴底層實現(變化)，二者都應該依賴於抽象;
1.2  抽象不應該依賴細節實現的變化，實現細節應該依賴於抽象;

2.1 對擴充套件開發，對更改封閉

2.2 類模組應該是可擴充套件的，但是不可修改;

3.1 乙個類應該僅有乙個引起變化的原因;

3.2 變化的方向隱含著類的責任; *** 單個類不能太臃腫，這就隱含著多責

4.1 子類必須能夠替代他們的基類：父類能做的，子類都可實現

4.2 繼承表達型別抽象：如果父類有很多方法子類沒用，說明是組合關係而非繼承關係

5.1 不應該強迫使用者依賴不用的方法;

5.2 介面應該小而完備：子類用則protected，只自己用則private，必要時才使用public

6.1 類繼承通常為"白箱復用"，物件組合為"黑箱復用"; 6.2 繼承在某種程度上破壞了封裝性，子類父類耦合度增加;

6.3 物件組合則要求物件具有良好的介面，耦合度低;

7.1  使用封裝來建立物件的分階層，設計者可以在分階層一次進行修改，而不影響另一次

8.1 不將型別變數宣告為具體類，而是某個介面; 8.2 客戶程式無需獲知物件的具體型別，而需知道物件介面;

8.3 減少系統中部分依賴關係，實現"高內聚、低耦合"的型別設計方案;

設計模式：主要描述類與相互通訊物件之間的組織關係，包括他們的角色、職責、寫作方式等方面；

架構模式：描述系統中與基本結構組織關係密切的高層模式，包括子系統劃分、職責，一級如何組織他們之間的關係規則;

#include
intmain()

oo原則封裝變化多用組合，少用繼承針對介面程式設計，不針對實現程式設計為互動物件之間的松耦合而努力類應該對擴充套件開放，對修改關閉依賴抽象，不要依賴具體類只和朋友交談別找我，我會找你類應該只有乙個改變的理由從設計原則到設計模式針對介面程式設計，而不是針對實現程式設計客戶無需知...

物件設計原則物件導向設計原則物件導向設計的基石是開閉原則。開一閉原則講的是乙個軟體實體應當對擴充套件開放，對修改關閉。這個規則說的是，在設計乙個模組的時候，應當使這個模組可以在不被修改的前提下被擴充套件。從另外乙個角度講，就是所謂的對可變性封裝原則對可變性封裝原則意味著兩點 1 ...

第2節 物件導向設計原則