Java設(shè)計(jì)模式GOF之6大設(shè)計(jì)原則原則

1、開閉原則（Open Close Principle）

　　一個(gè)軟件實(shí)體如類、模塊和函數(shù)應(yīng)該對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。

　　開閉原則是面向?qū)ο蟮目蓮?fù)用設(shè)計(jì)的第一塊基石，它是最重要的面向?qū)ο笤O(shè)計(jì)原則。

　　開閉原則由Bertrand? Meyer于1988年提出

　　一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉。即軟件實(shí)體應(yīng)盡量在不修改原有代碼的情況下進(jìn)行擴(kuò)展。

2、里氏代換原則（Liskov Substitution Principle）

　　所有引用基類的地方必須能透明地使用其子類的對(duì)象。

　　里氏代換原則由2008年圖靈獎(jiǎng)得主、美國第一位計(jì)算機(jī)科學(xué)女博士Barbara Liskov教授和卡內(nèi)基·梅隆大學(xué)Jeannette Wing教授于1994年提出

　　里氏代換原則(Liskov Substitution Principle LSP)面向?qū)ο笤O(shè)計(jì)的基本原則之一。

　　里氏代換原則是實(shí)現(xiàn)開閉原則的重要方式之一。

　　里氏代換原則是實(shí)現(xiàn)開閉原則的重要方式之一，由于使用基類對(duì)象的地方都可以使用子類對(duì)象，因此在程序中盡量使用基類類型來對(duì)對(duì)象進(jìn)行定義，而在運(yùn)行時(shí)再確定其子類類型，用子類對(duì)象來替換父類對(duì)象。

　　在使用里氏代換原則時(shí)需要注意如下幾個(gè)問題：

????? (1)子類的所有方法必須在父類中聲明，或子類必須實(shí)現(xiàn)父類中聲明的所有方法。根據(jù)里氏代換原則，為了保證系統(tǒng)的擴(kuò)展性，在程序中通常使用父類來進(jìn)行定義，如果一個(gè)方法只存在子類中，在父類中不提供相應(yīng)的聲明，則無法在以父類定義的對(duì)象中使用該方法。

????? (2) 我們?cè)谶\(yùn)用里氏代換原則時(shí)，盡量把父類設(shè)計(jì)為抽象類或者接口，讓子類繼承父類或?qū)崿F(xiàn)父接口，并實(shí)現(xiàn)在父類中聲明的方法，運(yùn)行時(shí)，子類實(shí)例替換父類實(shí)例，我們可以很方便地?cái)U(kuò)展系統(tǒng)的功能，同時(shí)無須修改原有子類的代碼，增加新的功能可以通過增加一個(gè)新的子類來實(shí)現(xiàn)。里氏代換原則是開閉原則的具體實(shí)現(xiàn)手段之一。

????? (3) Java語言中，在編譯階段，Java編譯器會(huì)檢查一個(gè)程序是否符合里氏代換原則，這是一個(gè)與實(shí)現(xiàn)無關(guān)的、純語法意義上的檢查，但Java編譯器的檢查是有局限的。

3、依賴倒轉(zhuǎn)原則（Dependence Inversion Principle）

　　高層模塊不應(yīng)該依賴低層模塊，二者都應(yīng)該依賴其抽象；抽象不應(yīng)該依賴細(xì)節(jié)；細(xì)節(jié)應(yīng)該依賴抽象。

　　 ?抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)當(dāng)依賴于抽象。換言之，要針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程。

　　如果說開閉原則是面向?qū)ο笤O(shè)計(jì)的目標(biāo)的話，那么依賴倒轉(zhuǎn)原則就是面向?qū)ο笤O(shè)計(jì)的主要實(shí)現(xiàn)機(jī)制之一，它是系統(tǒng)抽象化的具體實(shí)現(xiàn)。　　

　　依賴倒轉(zhuǎn)原則是Robert C. Martin在1996年為“C++Reporter”所寫的專欄Engineering Notebook的第三篇。

　　在實(shí)現(xiàn)依賴倒轉(zhuǎn)原則時(shí)，我們需要針對(duì)抽象層編程，而將具體類的對(duì)象通過依賴注入(DependencyInjection, DI)的方式注入到其他對(duì)象中，依賴注入是指當(dāng)一個(gè)對(duì)象要與其他對(duì)象發(fā)生依賴關(guān)系時(shí)，通過抽象來注入所依賴的對(duì)象。

　　常用的注入方式有三種，分別是：構(gòu)造注入，設(shè)值注入（Setter注入）和接口注入。構(gòu)造注入是指通過構(gòu)造函數(shù)來傳入具體類的對(duì)象，設(shè)值注入是指通過Setter方法來傳入具體類的對(duì)象，而接口注入是指通過在接口中聲明的業(yè)務(wù)方法來傳入具體類的對(duì)象。這些方法在定義時(shí)使用的是抽象類型，在運(yùn)行時(shí)再傳入具體類型的對(duì)象，由子類對(duì)象來覆蓋父類對(duì)象。

4、接口隔離原則（Interface Segregation Principle）

　　客戶端不應(yīng)該依賴它不需要的接口；一個(gè)類對(duì)另一個(gè)類的依賴應(yīng)該建立在最小的接口上。

　　使用多個(gè)專門的接口，而不使用單一的總接口，即客戶端不應(yīng)該依賴那些它不需要的接口。

　　根據(jù)接口隔離原則，當(dāng)一個(gè)接口太大時(shí)，我們需要將它分割成一些更細(xì)小的接口，使用該接口的客戶端僅需知道與之相關(guān)的方法即可。

　　每一個(gè)接口應(yīng)該承擔(dān)一種相對(duì)獨(dú)立的角色，不干不該干的事，該干的事都要干。

　　這里的“接口”往往有兩種不同的含義：一種是指一個(gè)類型所具有的方法特征的集合，僅僅是一種邏輯上的抽象；另外一種是指某種語言具體的“接口”定義，有嚴(yán)格的定義和結(jié)構(gòu)，比如Java語言中的interface。

　　對(duì)于這兩種不同的含義，ISP的表達(dá)方式以及含義都有所不同：

????? (1) 當(dāng)把“接口”理解成一個(gè)類型所提供的所有方法特征的集合的時(shí)候，這就是一種邏輯上的概念，接口的劃分將直接帶來類型的劃分。可以把接口理解成角色，一個(gè)接口只能代表一個(gè)角色，每個(gè)角色都有它特定的一個(gè)接口，此時(shí)，這個(gè)原則可以叫做“角色隔離原則”。

????? (2) 如果把“接口”理解成狹義的特定語言的接口，那么ISP表達(dá)的意思是指接口僅僅提供客戶端需要的行為，客戶端不需要的行為則隱藏起來，應(yīng)當(dāng)為客戶端提供盡可能小的單獨(dú)的接口，而不要提供大的總接口。在面向?qū)ο缶幊陶Z言中，實(shí)現(xiàn)一個(gè)接口就需要實(shí)現(xiàn)該接口中定義的所有方法，因此大的總接口使用起來不一定很方便，為了使接口的職責(zé)單一，需要將大接口中的方法根據(jù)其職責(zé)不同分別放在不同的小接口中，以確保每個(gè)接口使用起來都較為方便，并都承擔(dān)某一單一角色。接口應(yīng)該盡量細(xì)化，同時(shí)接口中的方法應(yīng)該盡量少，每個(gè)接口中只包含一個(gè)客戶端（如子模塊或業(yè)務(wù)邏輯類）所需的方法即可，這種機(jī)制也稱為“定制服務(wù)”，即為不同的客戶端提供寬窄不同的接口。

　　在使用接口隔離原則時(shí)，我們需要注意控制接口的粒度，接口不能太小，如果太小會(huì)導(dǎo)致系統(tǒng)中接口泛濫，不利于維護(hù)；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。一般而言，接口中僅包含為某一類用戶定制的方法即可，不應(yīng)該強(qiáng)迫客戶依賴于那些它們不用的方法。

5、迪米特法則（最少知道原則）（Demeter Principle）

　　一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象保持最少的了解。

?　　如果一個(gè)系統(tǒng)符合迪米特法則，那么當(dāng)其中某一個(gè)模塊發(fā)生修改時(shí)，就會(huì)盡量少地影響其他模塊，擴(kuò)展會(huì)相對(duì)容易，這是對(duì)軟件實(shí)體之間通信的限制，迪米特法則要求限制軟件實(shí)體之間通信的寬度和深度。

　　迪米特法則可降低系統(tǒng)的耦合度，使類與類之間保持松散的耦合關(guān)系。

????? 迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通信等，在迪米特法則中，對(duì)于一個(gè)對(duì)象，其朋友包括以下幾類：

??? ? (1) 當(dāng)前對(duì)象本身(this)；

　　(2) 以參數(shù)形式傳入到當(dāng)前對(duì)象方法中的對(duì)象；

????? (3) 當(dāng)前對(duì)象的成員對(duì)象；

????? (4) 如果當(dāng)前對(duì)象的成員對(duì)象是一個(gè)集合，那么集合中的元素也都是朋友；

????? (5) 當(dāng)前對(duì)象所創(chuàng)建的對(duì)象。

????? 任何一個(gè)對(duì)象，如果滿足上面的條件之一，就是當(dāng)前對(duì)象的“朋友”，否則就是“陌生人”。在應(yīng)用迪米特法則時(shí)，一個(gè)對(duì)象只能與直接朋友發(fā)生交互，不要與“陌生人”發(fā)生直接交互，這樣做可以降低系統(tǒng)的耦合度，一個(gè)對(duì)象的改變不會(huì)給太多其他對(duì)象帶來影響。

????? 迪米特法則要求我們?cè)谠O(shè)計(jì)系統(tǒng)時(shí)，應(yīng)該盡量減少對(duì)象之間的交互，如果兩個(gè)對(duì)象之間不必彼此直接通信，那么這兩個(gè)對(duì)象就不應(yīng)當(dāng)發(fā)生任何直接的相互作用，如果其中的一個(gè)對(duì)象需要調(diào)用另一個(gè)對(duì)象的某一個(gè)方法的話，可以通過第三者轉(zhuǎn)發(fā)這個(gè)調(diào)用。簡(jiǎn)言之，就是通過引入一個(gè)合理的第三者來降低現(xiàn)有對(duì)象之間的耦合度。

????? 在將迪米特法則運(yùn)用到系統(tǒng)設(shè)計(jì)中時(shí)，要注意下面的幾點(diǎn)：在類的劃分上，應(yīng)當(dāng)盡量創(chuàng)建松耦合的類，類之間的耦合度越低，就越有利于復(fù)用，一個(gè)處在松耦合中的類一旦被修改，不會(huì)對(duì)關(guān)聯(lián)的類造成太大波及；在類的結(jié)構(gòu)設(shè)計(jì)上，每一個(gè)類都應(yīng)當(dāng)盡量降低其成員變量和成員函數(shù)的訪問權(quán)限；在類的設(shè)計(jì)上，只要有可能，一個(gè)類型應(yīng)當(dāng)設(shè)計(jì)成不變類；在對(duì)其他類的引用上，一個(gè)對(duì)象對(duì)其他對(duì)象的引用應(yīng)當(dāng)降到最低。

6、單一職責(zé)原則(Single Responsibility Principle, SRP)

　　不要存在多于一個(gè)導(dǎo)致類變更的原因。通俗的說，即一個(gè)類只負(fù)責(zé)一項(xiàng)職責(zé)。

　　一個(gè)類只負(fù)責(zé)一個(gè)功能領(lǐng)域中的相應(yīng)職責(zé)，或者可以定義為：就一個(gè)類而言，應(yīng)該只有一個(gè)引起它變化的原因。

　　單一職責(zé)原則告訴我們：一個(gè)類不能太“累”！在軟件系統(tǒng)中，一個(gè)類（大到模塊，小到方法）承擔(dān)的職責(zé)越多，它被復(fù)用的可能性就越小，而且一個(gè)類承擔(dān)的職責(zé)過多，就相當(dāng)于將這些職責(zé)耦合在一起，當(dāng)其中一個(gè)職責(zé)變化時(shí)，可能會(huì)影響其他職責(zé)的運(yùn)作，因此要將這些職責(zé)進(jìn)行分離，將不同的職責(zé)封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個(gè)職責(zé)總是同時(shí)發(fā)生改變則可將它們封裝在同一類中。

??????單一職責(zé)原則是實(shí)現(xiàn)高內(nèi)聚、低耦合的指導(dǎo)方針，它是最簡(jiǎn)單但又最難運(yùn)用的原則，需要設(shè)計(jì)人員發(fā)現(xiàn)類的不同職責(zé)并將其分離，而發(fā)現(xiàn)類的多重職責(zé)需要設(shè)計(jì)人員具有較強(qiáng)的分析設(shè)計(jì)能力和相關(guān)實(shí)踐經(jīng)驗(yàn)。

轉(zhuǎn)載于:https://www.cnblogs.com/zfc-java/p/6670142.html

總結(jié)

以上是生活随笔為你收集整理的Java设计模式GOF之6大设计原则的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。