hello，你好呀，我是灰小猿，一個超會寫bug的程式猿，

一聽到面向物件這個詞，大家肯定都不會陌生，并且我們平常在進行的開發大多數也都是以面向物件為基礎的，但是在進行面向物件程式設計和開發的時候，你真的有按照面向物件的設計原則來開發嗎？

面向物件設計有七大原則，分別是：單一職責原則，開放封閉原則，李氏替換原則，依賴倒置原則，介面隔離原則，組合重用原則和迪米特原則，

下面我們簡單分析介紹一下這些原則，看看你在平常的開發中有哪些方法是不平常不會注意到的呢？

(1)單一職責原則(SRP)

就一個類來說，應該僅有一個引起它變化的原因，也就是說，一個類應該只有一個職責，如果有多個職責，那么就相當于把這些指責耦合在起，一個職責的變化就可能削榷訓抑制了這個類完成其他職責的能力，引起類的變化的原因就會有多個，所以在構造一個類時，將類的不同職責分離至兩個或多個類中(或者介面中)，確保引起該類變化的原因只有一個，

(2)開閉原則(OCP)

軟體組成物體應該是可擴展的，但是不可修改，開放-封閉原則認為應該試圖設計永遠也不需要改變的模塊，可以添加新代碼來打展系統的行為，不能對已有的代碼進行修改，這個原則很好的實作了面向物件的封裝性和可重用性，

(3)替換原則(LSP)

子類應當可以替換父類并出現在父類能夠出現的任何地方，這個原則是Liskov于1987年提出的設計原則，它同樣可以從Bertrand Meyer 的DBC(Design by Contract)的概念推出，以圓和橢圓為例，圓是橢圓的一一個特殊子類，因此任何出現橢圓的地方，圓均可以出現，

但反過來就可能行不通，運用替換原則時，盡量把類B設計為抽象類或者介面，讓C類繼承類B (介面B)并實作操作A和操作B,運行時，類C實體替換B,這樣即可進行新類的擴展(繼承類B或介面B)，同時無須對類A進行修改，

(4)依賴倒置原則(DIP)

在進行業務設計時，與特定業務有關的依賴關系應該盡量依賴介面和抽象類，而不是依賴于具體類，具體類只負責相關業務的實作，修改具體類不影響與特定業務有關的依賴關系，在結構化設計中，可以看到底層的模塊是對高層抽象模塊的實作，這說明，抽象的模塊要依賴具體實作相關的模塊，底層模塊的具體實作發生變動時將會嚴重影響高層抽象的模塊，顯然這是結構化方法的一個“硬傷”，

但面向物件方法的依賴關系剛好相反，具體實作類依賴于抽象類和介面，為此，在進行業務設計時，應盡量在介面或抽象類中定義業務方法的原型，并通過具體的實作類(子類)來實作該業務方法，業務方法內容的修改將不會影響到運行時業務方法的呼叫，

(5)介面分離原則(ISP)

采用多個與特定客戶類有關的介面比采用一個通用的涵蓋多個業務方法的介面要好，ISP 原則是另外一個支持諸如COM等組件化的使能技術，缺少ISP組件類的可用性和移植性將大打折扣，這個原則的本質相當簡單，如果擁有一個針對多個客戶的類，為每一個客戶創建特定業務介面，然后使該客戶類繼承多個特定業務介面將比直接加載客戶所需所有方法有效，