開閉原則是這七大設計原則中最常見、最基本的
開閉原則定義：軟體實體對擴充是開放的，但對修改是關閉的。意思就是說在不修改軟體實體的基礎上去擴充其他功能。
開閉原則執行個體：
比如實作一個繪制圖線的功能
設計方案如下圖所示
使用者類中直接調用畫直線類，但是如果有一個新需求，要求我們畫斜線或者曲線的話，這時就需要修改畫直線類中的代碼（使用switch，else if），這樣就違背了開閉原則，于是我需要在不修改實體的基礎上去擴充畫斜線和曲線功能
重構後的代碼設計方案如下圖所示
這樣我們在沒有改動代碼的情況下，而是添加代碼的情況下完成功能擴充
如果一個類具有多個職責，應該把這多個職責分離出去，再分别建立一些類去一一完成這些職責
換句話說就是一個類的職責要單一，不能将太多的職責放在一個類中
單一職責核心：高内聚、低耦合
如下圖是一個類畫線的實作：
但是功能太過集中，嚴重違背了單一職責原則，重構後如下圖所示
是繼承複用的基石，說白了就是繼承與派生的規則
裡氏替換原則核心：在軟體系統中，一個可以接受父類對象的地方必然可以接受子類對象
裡氏替換原則執行個體：某系統需要實作畫直線功能，現在有DrawLineA和DrawLineB兩種畫圖方式，在操作類中提供了這兩種畫圖方法選擇畫直線
現在我需要改變或添加一種畫直線方式來畫直線，比如原先使用DrawLineA方式進行畫直線現在更換為DrawLineB方式來畫直線，如果直接修改操作類的代碼就違背了開閉原則。現在使用裡氏替換原則重構代碼，既可以友善了系統擴充，又遵循了開閉原則
重構後的方案圖如下圖所示
是以說裡氏替換原則是實作開閉原則的重要方法之一
依賴倒置也叫依賴注入、依賴倒轉
要針對抽象層程式設計，不要針對具體類程式設計
依賴倒置原則核心：要依賴于抽象，不要依賴于具體的實作。
分開來說：（注：抽象:接口或抽象類;細節:具體實作;如果把子產品層次關系比作基礎關系的話:高層子產品和底層子產品對應于父類和子類）
一、高層子產品不應該依賴底層子產品，這兩者應該依賴與其抽象
二、抽想不應該依賴細節
三、細節應依賴抽象
依賴倒置執行個體：
比如某系統可以從本地擷取和伺服器擷取資料，後将資料可以為轉化配置成XML檔案和XLS檔案
假設我們增加了資料源或者有新的轉化格式，需要修改操作類裡面的源代碼，這樣就違背了開閉原則
現在使用依賴倒置原則對其進行重構
重構方案圖如下圖所示
執行個體解析OOP程式設計七大設計原則(二)
使用多個專門接口來取代一個統一的接口，
一個接口不需要提供太多的行為，一個接口應該隻提供一種對外的功能，不應該把所有的操作都封裝到一個接口中。
接口隔離原則核心：不應該強迫用戶端程式依賴他們 不需要的使用方法
接口隔離原則執行個體：
比如一個系統中有一個大的接口，這個接口包含了GameobjectA、GameobjecB、GameobjectC三個對象的接口
但是這三個對象中有些接口未必需要實作，現在使用接口隔離原則将接口隔離，這樣又滿足單一職責原則
重新構造的方案如下圖所示
又叫做最少知識原則，一個軟體實體對其他實體的引用越少越好，或者說如果兩個類不必直接通信，那麼這兩個類就不應當發生直接的互相作用，而是通過一個第三者發生間接性的互動。
迪米特原則核心：高内聚，低耦合
低迷特原理執行個體：
比如某一系統有多個系統和多個資料源，他們之間的聯系圖如下：
這樣比較雜亂，耦合性較高，使用迪米特原則後的構造方案如下圖所示：
迪米特原則缺點：
一、降低子產品間的通信效率
二、在系統的各個角落散落大量的小方法
在面向對象設計中，可以通過兩種基本方法在不同的環境中複用已有的設計和實作，即通過組合或通過繼承。
繼承複用：實作簡單，便于擴充。但是破壞系統的封裝性。
組合複用：耦合性相對較低，選擇性的調用成員對象的操作。可以再運作時動态運。.
合成複用核心：盡量使用對象組合而不是繼承達到複用的目的