物件導向設計原則概述
單一職責原則
開閉原則
黎克特制代換原則
依賴倒轉原則
介面隔離原則
合成復用原則
迪公尺特法則
物件導向設計原則概述
軟體的復用(reuse)或重用擁有眾多優點，比如可以提高軟體的開發效率，提高軟體質量，節約開發成本，恰當的復用還可以改善系統的可維護性。物件導向設計復用的目標在於實現支援可維護性的復用。
在物件導向的設計裡面，可維護性復用都是以物件導向設計原則為基礎的，這些設計原則首先都是復用的原則，遵循這些設計原則可以有效地提高系統的復用性，同時提高系統的可維護性。
物件導向設計原則和設計模式也是對系統進行合理重構的指南針，***重構(refactoring)***是在不改變軟體現有功能的基礎上，通過調整程式**改善軟體的質量、效能，使其程式的設計模式和架構更趨合理，提高軟體的擴充套件性和維護性。
常用的物件導向設計原則包括7個，這些原則並不是孤立存在的，它們相互依賴，相互補充。
設計原則名稱
設計原則簡介
重要性單一職責原則(single responsibility principle, srp)
類的職責要單一，不能將太多的職責放在乙個類中
★★★★☆
開閉原則(open-closed principle, ocp)
軟體實體對擴充套件是開放的，但對修改是關閉的，即在不修改乙個軟體實體的基礎上去擴充套件其功能
★★★★★
黎克特制代換原則(liskov substitution principle, lsp)
在軟體系統中，乙個可以接受基類物件的地方必然可以接受乙個子類物件
★★★★☆
依賴倒轉原則(dependency inversion principle, dip)
要針對抽象層程式設計，而不要針對具體類程式設計
★★★★★
介面隔離原則(inte***ce segregation principle, isp)
使用多個專門的介面來取代乙個統一的介面
★★☆☆☆
合成復用原則(composite reuse principle, crp)
在系統中應該盡量多使用組合和聚合關聯關係，盡量少使用甚至不使用繼承關係
★★★★☆
迪公尺特法則(law of demeter, lod)
乙個軟體實體對其他實體的引用越少越好，或者說如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用，而是通過引入乙個第三者發生間接互動
★★★☆☆
下面詳細地介紹這7個原則。
單一職責原則
類的職責主要包括兩個方面：資料職責和行為職責，資料職責通過其屬性來體現，而行為職責通過其方法來體現。
單一職責原則是實現高內聚、低耦合的指導方針，在很多**重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。
開閉原則
一般可以通過建立抽象層（黎克特制代換原則）、從配置檔案中讀取具體引數、反射機制來達成開閉原則。
黎克特制代換原則
依賴倒轉原則
依賴倒轉原則的常用實現方式之一是在**中使用抽象類，而將具體類放在配置檔案中。
「put abstractions in code, details in metadata」（將抽象放進**，將細節放進元資料）—— 《程式設計師修煉之道：從小工到專家》依賴注入（如何將具體子類注入到使用抽象基類的方法或類中去）：
①構造注入(constructor injection)：通過建構函式注入例項變數。
②設值注入(setter injection)：通過setter方法注入例項變數。
③介面注入(inte***ce injection)：通過介面方法注入例項變數。
介面隔離原則
合成復用原則
繼承復用和組合復用的比較：
迪公尺特法則迪公尺特法則的主要用途在於控制資訊的過載：
7個常用的物件導向設計原則
乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。軟體實體應當對擴充套件開放，對修改關閉。所有引用基類的地方必須能透明地使用其子類的物件。客戶端不應該依賴那些它不需要的介面。高層模組不應該依賴低層模組，它們都應該依賴抽象。抽象不應該依賴於細節，細節應該依賴於抽象。優先使用物件組合，而不...
物件導向7大設計原則（六） 開閉原則
定義 乙個軟體實體如類 模組和函式應該對擴充套件開放，對修改關閉。問題由來 在軟體的生命週期內，因為變化 公升級和維護等原因需要對軟體原有 進行修改時，可能會給舊 中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有 經過重新測試。解決方案 當軟體需要變化時，盡量通過擴充套件軟體實體的行...
物件導向設計原則
oo原則 封裝變化 多用組合，少用繼承 針對介面程式設計，不針對實現程式設計 為互動物件之間的松耦合而努力 類應該對擴充套件開放，對修改關閉 依賴抽象，不要依賴具體類 只和朋友交談 別找我，我會找你 類應該只有乙個改變的理由 從設計原則到設計模式 針對介面程式設計，而不是針對實現程式設計 客戶無需知...