嗯哼？其實對於這7大原則我也一臉懵，設計模式基本上就是在這幾個原則裡面做選擇，一種模式可能很好的滿足了一種原則，但對於其他原則可能就不能很好的滿足。背下來，老師如是說。恩，，感覺在設計類的時候會下意識往這上面想，怎麼設計父類？介面還是抽象類？是包含引用還是依賴關係？還是比較有趣的，在幾種選擇裡面做平衡。
【介個小哥哥是設計模式第一大原則，老師問的時候還一臉懵】
1》內容：
乙個軟體實體應當對擴充套件開放，對修改關閉。
【說人話：面對需求，對程式的改動是通過增加新的**進行的，而不是更改現有**。】
2》關鍵：
1> 合理地抽象、分離出變化與不變化的部分
，為變化的部分預留下可擴充套件的方式。例如：鉤子方法或是動態組合物件等。
ps:【鉤子方法:是對於抽象方法或者介面中定義的方法的乙個空實現】
2> 要完全遵守開閉原則是不可能的，也沒這個必要。適當的抽象可以提高系統的靈活性、使其可擴充套件、可維護；過度抽象，會大大增加系統的複雜程度。
1》內容：
就乙個類而言，應該僅有乙個引起它變化的原因（職責）。
【說人話：乙個類就乙個功能，不承擔太多的責任，到時候哪兒有bug，好改】
2》難點：
如何區分職責、職責的粒度問題。
1》內容：
子型別(subtype)必須能夠替換它們的基（父）型別。（子類可以以父類的身份出現）。
【說人話：父類有的屬性，功能，方法，子類必須都有。即抽象的時候要合理，別把子類沒有的功能弄到他們的父類中去】
2》作用：
使開放封閉成為可能。
【why?要是抽象這一塊做的不好，以後修改**時就不只增加子類，還要修改父類的抽象，又會影響到原來就存在的子類】
1》內容：
要依賴於抽象，不要依賴於具體。
【說人話：程式設計時，要看向父類，跟著父類制定的規則走，跟著介面走，而不是只想著這乙個類的功能實現】
2》常見錯誤：
1> 層次化呼叫的時候，應該是高層呼叫「
底層所擁有的介面」，
這是一典型的誤解。
一般高層包含對業務功能的處理和業務策略選擇，應該被重用，是高層模組去影響底層的具體實現。
底層的介面應該是由高層提出的，然後由底層實現，即底層的介面的所有權在高層模組，是一種所有權的倒置。
3》如何使用：
1>每個類盡量都有介面或抽象類
2>變數的表面型別盡量是介面或者是抽象類
3>任何類都不應該從具體類派生
4>結合黎克特制代換原則使用
1》內容：
要盡量使用合成/聚合，而不是繼承關係達到復用的目的。
【說人話：想擁有乙個類或者乙個介面的所擁有的功能時，盡量不要使用繼承這種耦合度高的方式，盡量使用引用、或者包含乙個例項化的物件】
1》內容：
使用多個專門的介面比使用單一的總介面要好。
換而言之，從乙個客戶類的角度來講：乙個類對另外乙個類的依賴性應當是建立在最小介面上的。
2》實現方法：
使用多重繼承分離介面
1》內容：
最少知識原則。
【如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫】
【乙個軟體實體應當盡可能少的與其他實體發生相互作用】
物件導向設計七大原則
物件導向七大設計原則 1 開閉原則 2 黎克特制替換原則 3 單一職責原則 4 介面隔離原則 5 依賴倒置原則 6 迪公尺特原則 7 組合 聚合復用原則 原則一 srp single responsibility principle 單一職責原則又稱單一功能原則 核心 解耦和增強內聚性 高內聚，低耦...
設計模式 物件導向設計七大原則
單一職責原則 類的職責要單一,不要將太多的職責放在乙個類中 開閉原則 軟體實體對擴充套件是開放的,但對於修改是關閉的,即在不修改乙個軟體實體的基礎上去擴充套件其功能 黎克特制代換原則 在軟體系統中,乙個可以接受基類物件的地方必然可以接受乙個子類物件 依賴倒轉原則 要對抽象層程式設計,不要針對具體類程...
OOP（物件導向程式設計）七大原則
對拓展開放，對修改關閉。也就是在原有的功能上進行拓展，盡量不要修改原有的功能。2.黎克特制替換原則 繼承要確保父類中的性質在子類中仍然使用。要面向介面程式設計，不要面向實現程式設計。抽象不依賴細節，細節不依賴抽象。控制類的粒度大小，將物件解耦 提高內聚性。也就是乙個方法盡可能完成一件事。5.介面隔離...