面向對象原則綜述 七大原則總脈絡圖： 註：1，2，3，4，5顯示的重要等級 常用的面向對象設計原則包括7個，這些原則並不是孤立存在的，它們相互依賴，相互補充。 下麵就是面向對象七個原則的一一解析 一、開閉原則 1. 開閉原則定義 ：一個軟體實體應當對擴展開放，對修改關閉。也就是說在設計一個模塊的時候
面向對象原則綜述
七大原則總脈絡圖： 
註：1，2，3，4，5顯示的重要等級
常用的面向對象設計原則包括7個，這些原則並不是孤立存在的，它們相互依賴，相互補充。
下麵就是面向對象七個原則的一一解析
一、開閉原則
1. 開閉原則定義 ：一個軟體實體應當對擴展開放，對修改關閉。也就是說在設計一個模塊的時候，應當使這個模塊可以在不被修改的前提下被擴展，即實現在不修改源代碼的情況下改變這個模塊的行為。
2. 開閉原則分析：
（1）開閉原則由Bertrand Meyer於1988年提出，它是面向對象設計中最重要的原則之一。
（2）在開閉原則的定義中，軟體實體可以指一個軟體模塊、一個由多個類組成的局部結構或一個獨立的類。
（3）抽象化是開閉原則的關鍵。
（4）開閉原則還可以通過一個更加具體的“對可變性封裝原則”來描述，對可變性封裝原則(Principle of Encapsulation of Variation,EVP)要求找到系統的可變因素並將其封裝起來。
3. 開閉原則實例：
某圖形界面系統提供了各種不同形狀的按鈕，客戶端代碼可針對這些按鈕進行編程，用戶可能會改變需求要求使用不同的按鈕，原始設計方案如圖所示：
圖（1）
現對該系統進行重構，使之滿足開閉原則的要求。
圖（2）
對比分析
圖（1）：客戶端的一個方法直接調用加法類，但是我想添加一個減法類，你就會發現添加減法類就得改變加法類中代碼（用switch語句實現），這就違背了“開閉原則”，於是我們就應該重新重構。
如圖（2）在這個圖中我們添加了一個運算類的父類，這樣我們再添加減法類的時候就不用修改客戶端類。
開閉原則總結：面對需求，對程式的改動是通過增加新代碼進行的，而不是改變原來的代碼。
1. 依賴倒轉原則實例
某系統提供一個數據轉換模塊，可以將來自不同數據源的數據轉換成多種格式，如可以轉換來自資料庫的數據(DatabaseSource)、也可以轉換來自文本文件的數據(TextSource)，轉換後的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer
圖（一）
圖（二）
圖（一）和圖（二）分析：
圖（一）為什麼要到圖（二）哪？因為該系統可能需要增加新的數據源或者新的文件格式，每增加一個新的類型的數據源或者新的類型的文件格式，客戶類MainClass都需要修改源代碼，以便使用新的類，但違背了開閉原則。現使用依賴倒轉原則對其進行重構。
總結：高層模塊不應該依賴底層模塊，兩個都應該依賴與抽象；抽象不應該依賴於細節，細節應該依賴於抽象。
1. 實例
某系統需要實現對重要數據（如用戶密碼）的加密處理，在數據操作類(DataOperator)中需要調用加密類中定義的加密演算法，系統提供了兩個不同的加密類，CipherA和CipherB，它們實現不同的加密方法，在DataOperator中可以選擇其中的一個實現加密操作。如圖所示：
圖（一）
圖（二）
圖（一）和圖（二）分析：
圖（一）為什到圖（二）哪？因為如果需要更換一個加密演算法類或者增加並使用一個新的加密演算法類，如將CipherA改為CipherB，則需要修改客戶類Client和數據操作類DataOperator的源代碼，違背了開閉原則。現使用里氏代換原則對其進行重構，使得系統可以靈活擴展，符合開閉原則。
總結：子類型必須能夠替換掉它們的父類型。
四、單一職責原則
1. 定義
i. 一個對象應該只包含單一的職責，並且該職責被完整地封裝在一個類中。
ii. 就一個類而言，應該僅有一個引起它變化的原因。
2. 分析
i. 一個類（或者大到模塊，小到方法）承擔的職責越多，它被覆用的可能性越小，而且如果一個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作。
ii.類的職責主要包括兩個方面：數據職責和行為職責，數據職責通過其屬性來體現，而行為職責通過其方法來體現。
iii.單一職責原則是實現高內聚、低耦合的指導方針，在很多代碼重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。
3. 實例
i. 某基於Java的C/S系統的“登錄功能”通過如下登錄類(Login)實現：
圖（一）
圖（二）
圖一和圖二有什麼區別哪？
圖（一）功能太過於集成，嚴重違反類的單一原則。
總結：就一個類而言，應該僅有一個引起它變化的原因。
五、介面隔離原則
1. 定義
i. 客戶端不應該依賴那些它不需要的介面。
ii. 一旦一個介面太大，則需要將它分割成一些更細小的介面，使用該介面的客戶端僅需知道與之相關的方法即可。
2.分析
i. 介面隔離原則是指使用多個專門的介面，而不使用單一的總介面。每一個介面應該承擔一種相對獨立的角色，不多不少，不幹不該乾的事，該乾的事都要乾。
ii. 使用介面隔離原則拆分介面時，首先必須滿足單一職責原則，將一組相關的操作定義在一個介面中，且在滿足高內聚的前提下，介面中的方法越少越好。
iii. 可以在進行系統設計時採用定製服務的方式，即為不同的客戶端提供寬窄不同的介面，只提供用戶需要的行為，而隱藏用戶不需要的行為
3.實例
i. 下圖展示了一個擁有多個客戶類的系統，在系統中定義了一個巨大的介面（胖介面）AbstractService來服務所有的客戶類。如圖所示：
圖（一）
圖（二）
圖（一）和圖（二）分析：
圖（一）為什麼到圖（二）哪？因為這樣做既滿足了介面隔離原則，又滿足了單一原則，何樂而不為呢，但是也帶來了很多的不便，類增多了。
總結：類應該完全依賴相應的專門的介面
六、合成復用原則
1.定義
i. 儘量使用對象組合，而不是繼承來達到復用的目的。
2.分析
i. 合成復用原則就是指在一個新的對象里通過關聯關係（包括組合關係和聚合關係）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調用已有對象的方法達到復用其已有功能的目的。簡言之：要儘量使用組合/聚合關係，少用繼承。
ii. 在面向對象設計中，可以通過兩種基本方法在不同的環境中復用已有的設計和實現，即通過組合/聚合關係或通過繼承。
a) 繼承復用：實現簡單，易於擴展。破壞系統的封裝性；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性；只能在有限的環境中使用。（“白箱”復用 ）
b) 組合/聚合復用：耦合度相對較低，選擇性地調用成員對象的操作；可以在運行時動態進行。（“黑箱”復用 ）
iii. 組合/聚合可以使系統更加靈活，類與類之間的耦合度降低，一個類的變化對其他類造成的影響相對較少，因此一般首選使用組合/聚合來實現復用；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助於對問題的理解，降低複雜度，而濫用繼承反而會增加系統構建和維護的難度以及系統的複雜度，因此需要慎重使用繼承復用。
3. 實例
i. 某教學管理系統部分資料庫訪問類設計如圖所示：
圖（一）
圖（二）
圖（一）和圖（二）分析：
圖（一）為什麼到圖（二）哪？因為如果需要更換資料庫連接方式，如原來採用JDBC連接資料庫，現在採用資料庫連接池連接，則需要修改DBUtil類源代碼。如果StudentDAO採用JDBC連接，但是TeacherDAO採用連接池連接，則需要增加一個新的DBUtil類，並修改StudentDAO或TeacherDAO的源代碼，使之繼承新的資料庫連接類，這將違背開閉原則，系統擴展性較差。
總結：類中應用，儘量使用對象組合而不是用繼承來達到復用的目的。
七、迪米特法則
1. 定義
i. 每一個軟體單位對其他的單位都只有最少的知識，而且局限於那些與本單位密切相關的軟體單位。
2. 分析
i.迪米特法則就是指一個軟體實體應當儘可能少的與其他實體發生相互作用。這樣，當一個模塊修改時，就會儘量少的影響其他的模塊，擴展會相對容易，這是對軟體實體之間通信的限制，它要求限制軟體實體之間通信的寬度和深度。
ii. 狹義的迪米特法則：可以降低類之間的耦合，但是會在系統中增加大量的小方法並散落在系統的各個角落，它可以使一個系統的局部設計簡化，因為每一個局部都不會和遠距離的對象有直接的關聯，但是也會造成系統的不同模塊之間的通信效率降低，使得系統的不同模塊之間不容易協調。
iii. 廣義的迪米特法則：指對對象之間的信息流量、流向以及信息的影響的控制，主要是對信息隱藏的控制。信息的隱藏可以使各個子系統之間脫耦，從而允許它們獨立地被開發、優化、使用和修改，同時可以促進軟體的復用，由於每一個模塊都不依賴於其他模塊而存在，因此每一個模塊都可以獨立地在其他的地方使用。一個系統的規模越大，信息的隱藏就越重要，而信息隱藏的重要性也就越明顯。
iv. 迪米特法則的主要用途在於控制信息的過載。
1.在類的劃分上，應當儘量創建松耦合的類，類之間的耦合度越低，就越有利於復用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及
2.在類的結構設計上，每一個類都應當儘量降低其成員變數和成員函數的訪問許可權
3.在類的設計上，只要有可能，一個類型應當設計成不變類
4.在對其他類的引用上，一個對象對其他對象的引用應當降到最低。
3. 實例
i.某系統界面類(如Form1、Form2等類)與數據訪問類(如DAO1、DAO2等類)之間的調用關係較為複雜。如圖所示：
圖（一）
圖（二）
圖（一）和圖（二）分析：
圖（一）為什麼到圖（二）哪？因為這樣就可以降低類的耦合性，是類中功能更加單一，相當於外觀模式。
總結：一個軟體實體應當儘可能少的與其他實體發生相互作用
這就是程式員必備的七大面向對象設計原則，很喜歡這樣的分享，希望你們參與進來，走近博客園、知識將源源不斷、、
