Java设计模式GOF之6大设计原则
Java設計模式GOF之6大設計原則原則
1、開閉原則（Open Close Principle）
一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
開閉原則是面向對象的可復用設計的第一塊基石，它是最重要的面向對象設計原則。
開閉原則由Bertrand? Meyer于1988年提出
一個軟件實體應當對擴展開放，對修改關閉。即軟件實體應盡量在不修改原有代碼的情況下進行擴展。
2、里氏代換原則（Liskov Substitution Principle）
所有引用基類的地方必須能透明地使用其子類的對象。
里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士Barbara Liskov教授和卡內基·梅隆大學Jeannette Wing教授于1994年提出
里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。
里氏代換原則是實現開閉原則的重要方式之一。
里氏代換原則是實現開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。
在使用里氏代換原則時需要注意如下幾個問題：
????? (1)子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法。根據里氏代換原則，為了保證系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。
????? (2) 我們在運用里氏代換原則時，盡量把父類設計為抽象類或者接口，讓子類繼承父類或實現父接口，并實現在父類中聲明的方法，運行時，子類實例替換父類實例，我們可以很方便地擴展系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現。里氏代換原則是開閉原則的具體實現手段之一。
????? (3) Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現無關的、純語法意義上的檢查，但Java編譯器的檢查是有局限的。
3、依賴倒轉原則（Dependence Inversion Principle）
高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。
?抽象不應該依賴于細節，細節應當依賴于抽象。換言之，要針對接口編程，而不是針對實現編程。
如果說開閉原則是面向對象設計的目標的話，那么依賴倒轉原則就是面向對象設計的主要實現機制之一，它是系統抽象化的具體實現。
依賴倒轉原則是Robert C. Martin在1996年為“C++Reporter”所寫的專欄Engineering Notebook的第三篇。
在實現依賴倒轉原則時，我們需要針對抽象層編程，而將具體類的對象通過依賴注入(DependencyInjection, DI)的方式注入到其他對象中，依賴注入是指當一個對象要與其他對象發生依賴關系時，通過抽象來注入所依賴的對象。
常用的注入方式有三種，分別是：構造注入，設值注入（Setter注入）和接口注入。構造注入是指通過構造函數來傳入具體類的對象，設值注入是指通過Setter方法來傳入具體類的對象，而接口注入是指通過在接口中聲明的業務方法來傳入具體類的對象。這些方法在定義時使用的是抽象類型，在運行時再傳入具體類型的對象，由子類對象來覆蓋父類對象。
4、接口隔離原則（Interface Segregation Principle）
客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。
根據接口隔離原則，當一個接口太大時，我們需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可。
每一個接口應該承擔一種相對獨立的角色，不干不該干的事，該干的事都要干。
這里的“接口”往往有兩種不同的含義：一種是指一個類型所具有的方法特征的集合，僅僅是一種邏輯上的抽象；另外一種是指某種語言具體的“接口”定義，有嚴格的定義和結構，比如Java語言中的interface。
對于這兩種不同的含義，ISP的表達方式以及含義都有所不同：
????? (1) 當把“接口”理解成一個類型所提供的所有方法特征的集合的時候，這就是一種邏輯上的概念，接口的劃分將直接帶來類型的劃分。可以把接口理解成角色，一個接口只能代表一個角色，每個角色都有它特定的一個接口，此時，這個原則可以叫做“角色隔離原則”。
????? (2) 如果把“接口”理解成狹義的特定語言的接口，那么ISP表達的意思是指接口僅僅提供客戶端需要的行為，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的單獨的接口，而不要提供大的總接口。在面向對象編程語言中，實現一個接口就需要實現該接口中定義的所有方法，因此大的總接口使用起來不一定很方便，為了使接口的職責單一，需要將大接口中的方法根據其職責不同分別放在不同的小接口中，以確保每個接口使用起來都較為方便，并都承擔某一單一角色。接口應該盡量細化，同時接口中的方法應該盡量少，每個接口中只包含一個客戶端（如子模塊或業務邏輯類）所需的方法即可，這種機制也稱為“定制服務”，即為不同的客戶端提供寬窄不同的接口。
在使用接口隔離原則時，我們需要注意控制接口的粒度，接口不能太小，如果太小會導致系統中接口泛濫，不利于維護；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。一般而言，接口中僅包含為某一類用戶定制的方法即可，不應該強迫客戶依賴于那些它們不用的方法。
5、迪米特法則（最少知道原則）（Demeter Principle）
一個對象應該對其他對象保持最少的了解。
? 如果一個系統符合迪米特法則，那么當其中某一個模塊發生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。
迪米特法則可降低系統的耦合度，使類與類之間保持松散的耦合關系。
????? 迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通信等，在迪米特法則中，對于一個對象，其朋友包括以下幾類：
??? ? (1) 當前對象本身(this)；
(2) 以參數形式傳入到當前對象方法中的對象；
????? (3) 當前對象的成員對象；
????? (4) 如果當前對象的成員對象是一個集合，那么集合中的元素也都是朋友；
????? (5) 當前對象所創建的對象。
????? 任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個對象只能與直接朋友發生交互，不要與“陌生人”發生直接交互，這樣做可以降低系統的耦合度，一個對象的改變不會給太多其他對象帶來影響。
????? 迪米特法則要求我們在設計系統時，應該盡量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那么這兩個對象就不應當發生任何直接的相互作用，如果其中的一個對象需要調用另一個對象的某一個方法的話，可以通過第三者轉發這個調用。簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度。
????? 在將迪米特法則運用到系統設計中時，要注意下面的幾點：在類的劃分上，應當盡量創建松耦合的類，類之間的耦合度越低，就越有利于復用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當盡量降低其成員變量和成員函數的訪問權限；在類的設計上，只要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。
6、單一職責原則(Single Responsibility Principle, SRP)
不要存在多于一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
一個類只負責一個功能領域中的相應職責，或者可以定義為：就一個類而言，應該只有一個引起它變化的原因。
單一職責原則告訴我們：一個類不能太“累”！在軟件系統中，一個類（大到模塊，小到方法）承擔的職責越多，它被復用的可能性就越小，而且一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發生改變則可將它們封裝在同一類中。
??????單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責并將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。
轉載于:https://www.cnblogs.com/zfc-java/p/6670142.html
總結
以上是生活随笔為你收集整理的Java设计模式GOF之6大设计原则的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 常用的三联动实现
- 下一篇： 2015211230108《Java程序