設計模式的六大原則：1、單一職責原則，其核心就是控制類別的粒度大小、將物件解耦、提高其內聚性；2、開閉原則，可以透過「抽象約束、封裝變化」來實現(xiàn)；3、里氏替換原則，主要闡述了有關繼承的一些原則；4、依賴倒置原則，降低了客戶與實現(xiàn)模組之間的耦合；5、接口隔離原則，是為了約束接口、降低類別對介面的依賴性；6、迪米特法則，要求限制軟體實體之間通訊的寬度和深度。

本教學操作環(huán)境：windows7系統(tǒng)、java8版、DELL G3電腦。

對於設計模式，自己很早之前就看了好多本設計模式書籍，其中一些還看了好幾遍，也一直希望自己能在編碼的時候把這些設計模式用上去?？墒?，在日常的打碼中，用的做多的就是單例，其次是觀察者和建造者模式 ( builder ) 用得比較多，其他的基本很少用到。

用不到的原因是還是不能夠理解設計模式的思想，無法將這些設計模式和編碼遇到的問題連結起來，從而用不到設計模式。

其實設計模式的提出都是為了解決一個常見的問題而總結出來的辦法。所以當你思考採用何種設計模式的時候，你應該先問自己當前問題的是什麼？根據(jù)問題去選取合適的設計模式。

等你熟悉了設計模式的以後，你會發(fā)現(xiàn)部分設計模式之間存在包含關係，甚至很相像，但是不同的設計模式解決的問題是不一樣的。

當我們在設計一個模組的時候可以從以下幾個角度去考慮：

• 這個模組與其他模組的關係是什麼樣的？

• 模組中哪些部分是不變的，哪些部分是在不斷變化的，又是如何變化的？

• 類別與類別之間的關係是怎麼樣的，為什麼需要依賴，怎麼可以不依賴？

• 要不要加上一個介面？介面的存在是為了解決什麼問題？

當然，本文並不是教你如何使用設計模式。而是講解設計模式的設計原則。設計模式在被設計出來的時候，也是遵循一些規(guī)則的。

設計模式六大原則，具體如下：

• 單一職責原則（類別與方法，介面）

• 開閉原則（擴展開放，修改關閉）

• #里氏替換原則（基底類別和子類別之間的關係)

• 依賴倒置原則（依賴抽象接口，而不是具體物件）

• 介面隔離原則（介面依功能細分）

• 迪米特法則（類別與類別之間的親疏關係）

##每個設計原則旁邊都有個括號，是用來解釋，或是描述應用範圍的。以下將詳細介紹每一個原則。

單一職責原則的定義（類別、方法、介面）

#單一職責原則（Single Responsibility Principle，SRP）又稱為單一功能原則。這裡的職責是指類別變化的原因，單一職責原則規(guī)定一個類別應該有且僅有一個引起它變化的原因，否則類別應該被拆分（There should never be more than one reason for a class to change）。

該原則提出物件不應該承擔太多職責，如果一個物件承擔了太多的職責，至少存在以下兩個缺點：

• 一個職責的變化可能會削弱或抑制這個類別實現(xiàn)其他職責的能力；

• 當客戶端需要該物件的某一個職責時，不得不將其他不需要的職責全都包含進來，造成冗餘程式碼或程式碼的浪費。

單一職責原則的優(yōu)點

#單一職責原則的核心就是控制類別的粒度大小、將物件解耦、提高其內聚性。如果遵循單一職責原則將有以下優(yōu)點。

• 降低類別的複雜度。一個類別只負責一項職責，其邏輯肯定比負責多項職責簡單得多。

• 提高類別的可讀性。複雜性降低，自然其可讀性會提高。

• 提高系統(tǒng)的可維護性。可讀性提高，那自然更容易維護了。

• 變更引起的風險降低。變更是必然的，如果單一職責原則遵守得好，當修改一個功能時，可以顯著降低對其他功能的影響。

單一職責原則的實現(xiàn)方法

單一職責原則是最簡單但又最難運用的原則，需要設計人員發(fā)現(xiàn)類的不同職責并將其分離，再封裝到不同的類或模塊中。而發(fā)現(xiàn)類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。

示例

public interface UserService {
    
    public void login(String username, String password);
    public void register(String email, String username, String password);
    public void logError(String msg);
    public void sendEmail(String email);
    
}

這段代碼很顯然存在很大的問題，UserService 既要負責用戶的注冊和登錄，還要負責日志的記錄和郵件的發(fā)送，并且后者的行為明顯區(qū)別于前者。<br/>

假設我要修改發(fā)送郵件的邏輯就得修改這個類，這時候 qa 還得回歸登錄注冊邏輯，這樣明顯不合理。

因此我們需要進行拆分，根據(jù)具體的職能可將其具體拆分如下：

UserService：只負責登錄注冊

public interface UserService {

    public void login(String username, String password);
    public void register(String email, String username, String password);

}

LogService?：只負責日志<br/>

public interface LogService {
    public void logError(String msg);

}

EmailService：?只負責發(fā)送郵件

public interface EmailService {
    public void sendEmail(String email);

}

這時候，咱們再去回顧前面提到的優(yōu)點，就能深深體會了。

這里只是講了接口，其實對類也一樣，甚至方法也是一樣的。

對于類來說，根據(jù)類名，確保里面提供的方法都是屬于這個類的。

對于方法，不要把不相關的對象實例作為參數(shù)傳進來。如果你發(fā)現(xiàn)某個方法依賴某個不相關的對象，那么這個方法的實現(xiàn)可能就存在問題。

比如 android 中圖片下載后顯示到 imageView 中，我提供如下的方法：

loadImage(String url, ImageView view) {
// 下載圖片，展示圖片
}

對于?loadImage 這個方法，參數(shù) url 是ok 的，但是參數(shù) ImageView 卻是不合理的。因為這里做了兩個操作，下載圖片，展示圖片。應該將這個方法在進行拆分：

// 下載圖片 
loadImage(String url) {

}
// 顯示圖片
displayImage(String url, ImageView view) {

// 調用 getBitmap (url)  獲取圖片
// 獲取圖片后將其設置到 view 中。

}

// 根據(jù) url 獲取圖片， 
getBitmap(String url) {

}

這樣整個邏輯就很清晰。后續(xù)需要修改下載邏輯，也不會影響到展示邏輯。當然其實還有個問題是，這兩個方法要不要放在一個類里面？

開閉原則

開閉原則的實現(xiàn)方法：可以通過“抽象約束、封裝變化”來實現(xiàn)開閉原則，即通過接口或者抽象類為軟件實體定義一個相對穩(wěn)定的抽象層，而將相同的可變因素封裝在相同的具體實現(xiàn)類中。

因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟件架構的穩(wěn)定。而軟件中易變的細節(jié)可以從抽象派生來的實現(xiàn)類來進行擴展，當軟件需要發(fā)生變化時，只需要根據(jù)需求重新派生一個實現(xiàn)類來擴展就可以了。

示例

// 矩形
public class Rectangle {

    public double getWidth() {
        return width;
    }
    
    public double getHeight() {
        return height;
    }

}

需要計算矩形的面積

// 面積計算器
public class AreaCalculator {

    public double area(Rectangle shape){
        return shape.getWidth() * shape.getHeight();
    }
}

假設這時候，又多了一個圓形類

// 圓形
public class Circular {

    public double getRadius(){
        return radius;
    }
}

同樣也需要計算他的面積，這時候就會變成下面這樣子：

public class AreaCalculator {

    public double area(Object shape){
        if(shape instanceof Rectangle) {
            Rectangle rectangle = (Rectangle) shape;
            return rectangle.getWidth() * rectangle.getHeight();
        } else if (shape instanceof Circular) {
            Circular circular = (Circular) shape;
            return circular.getRadius() * circular.getRadius() * Math.PI;
        } else {
            throw new RuntimeException("There is no such type.");
        }
    }
}

這么更改完成，完全沒有問題。但是在真實的生產環(huán)境中，情況更為復雜，更改涉及的部分較多，那樣就可能導致牽一發(fā)動全身。并且，以前編寫的經過測試的一些功能需要重新測試，甚至導致某些功能不可用。

改進版，把計算面積這個公有邏輯變成一個接口：

public interface Shape {

    public double getArea();

}
 
public class Rectangle implements Shape{

    public double getWidth() {
        return width;
    }

    public double getHeight() {
        return height;
    }

    public double getArea() {
        return getWidth() * getHeight();
    }
    
}

這樣，當需求變更，需要計算圓形面積的時候，我們只需創(chuàng)建一個圓形的類，并實現(xiàn) Shape 接口即可:<br/>

public class Circular implements Shape {

    public double getRadius(){
        return radius;
    }

    public double getArea() {
        return getRadius() * getRadius() * Math.PI;
    }
}

計算三角形面積、四邊形面積... 的時候，我們只需讓它們去實作 Shape 介面即可，無需修改原始程式碼。

里氏替換原則

里氏替換原則主要闡述了有關繼承的一些原則，也就是什麼時候應該使用繼承，什麼時候不應該使用繼承，以及其中蘊含的原理。里氏替換原是繼承復用的基礎，它反映了基底類別與子類別之間的關係，是對開閉原則的補充，是實現(xiàn)抽象化的具體步驟的規(guī)範。

里氏替換原則的作用

#里氏替換原則的主要作用如下。

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

• 它克服了繼承中重寫父類別造成的可重複使用性變差的缺點。

• 它是動作正確性的保證。即類別的擴充不會為現(xiàn)有的系統(tǒng)引入新的錯誤，降低了程式碼出錯的可能性。

• 加強程式的健壯性，同時變更時可以做到非常好的相容性，提高程式的維護性、可擴充性，降低需求變更時引入的風險。

里氏替換原則的實作方法（繼承）

里氏替換原則通俗來講就是：子類別可以擴充父類別的功能，但不能改變父類別原有的功能。也就是說：子類別繼承父類別時，除新增新的方法完成新增功能外，盡量不要重寫父類別的方法。

根據(jù)上述理解，對里氏替換原則的定義可以總結如下：

• #子類別可以實作父類別的抽象方法，但不能覆寫父類別的非抽象方法

• 子類別中可以增加自己特有的方法

• 當子類別的方法重載父類別的方法時，方法的前置條件（即方法的輸入參數(shù)）要比父類別的方法更寬鬆

• #當子類別的方法實作父類別的方法（重寫/重載或實作抽象方法），方法的後置條件（即方法的的輸出/傳??回值）要比父類別的方法更嚴格或相等

透過重寫父類別的方法來完成新的功能寫起來雖然簡單，但是整個繼承體系的可重複使用性會比較差，特別是運用多型別比較頻繁時，程式運行出錯的機率會非常大。

如果程式違反了里氏替換原則，則繼承類別的物件在基底類別出現(xiàn)的地方會出現(xiàn)運行錯誤。

這時其修正方法是：取消原來的繼承關係，重新設計它們之間的關係。

關於里氏替換原則的例子，最有名的是「正方形不是長方形」。當然，生活中也有很多類似的例子，例如，企鵝、鴕鳥和幾維鳥從生物學的角度來劃分，它們屬於鳥類；但從類的繼承關係來看，由於它們不能繼承“鳥”會飛的功能，所以它們不能定義成「鳥」的子類。同樣，由於「氣球魚」不會游泳，所以不能定義成「魚」的子類；「玩具炮」炸不了敵人，所以不能定義成「砲」的子類等。

對於正方形和長方形最好的做法是再增加一個父類，他們同時繼承自這個父類。

依賴倒置（抽線細節(jié)）

依賴倒置原則是實現(xiàn)開閉原則的重要途徑之一，它降低了客戶與實作模組之間的耦合。

由於在軟體設計中，細節(jié)具有多變性，而抽象層則相對穩(wěn)定，因此以抽象為基礎搭建起來的架構要比以細節(jié)為基礎搭建起來的架構要穩(wěn)定得多。這裡的抽象指的是介面或抽象類別，而細節(jié)是指具體的實作類別。

使用介面或抽象類別的目的是製定好規(guī)範和契約，而不去涉及任何具體的操作，把展現(xiàn)細節(jié)的任務交給它們的實作類別去完成。

依賴、倒置原則的作用

依賴倒置原則的主要作用如下。

• 依賴倒置原則可以降低類別間的耦合性。

• 依賴倒置原則可以提高系統(tǒng)的穩(wěn)定性。

• 依賴倒置原則可以減少並行開發(fā)所引起的風險。

• 依賴倒置原則可以提高程式碼的可讀性和可維護性。

依賴倒置原則的實現(xiàn)方法

依賴倒置原則的目的是通過要面向接口的編程來降低類間的耦合性，所以我們在實際編程中只要遵循以下4點，就能在項目中滿足這個規(guī)則。

• 每個類盡量提供接口或抽象類，或者兩者都具備。

• 變量的聲明類型盡量是接口或者是抽象類。

• 任何類都不應該從具體類派生。

• 使用繼承時盡量遵循里氏替換原則。

依賴倒置原則在“顧客購物程序”中的應用。

分析：本程序反映了 “顧客類”與“商店類”的關系。商店類中有 sell() 方法，顧客類通過該方法購物以下代碼定義了顧客類通過韶關網店 ShaoguanShop 購物

class Customer {
    public void shopping(ShaoguanShop shop) {
        //購物
        System.out.println（shop.sell());
    }
}

但是，這種設計存在缺點，如果該顧客想從另外一家商店（如婺源網店 WuyuanShop）購物，就要將該顧客的代碼修改如下：

class Customer {
    public void shopping(WuyuanShop shop) {
        //購物
        System.out.println(shop.sell());
    }
}

顧客每更換一家商店，都要修改一次代碼，這明顯違背了開閉原則。

存在以上缺點的原因是：顧客類設計時同具體的商店類綁定了，這違背了依賴倒置原則。

解決方法是：定義“婺源網店”和“韶關網店”的共同接口 Shop，顧客類面向該接口編程，其代碼修改如下：

class Customer {
    public void shopping(Shop shop) {
        //購物
        System.out.println(shop.sell());
    }
}

class Customer {
    public void shopping(Shop shop) {
        //購物
        System.out.println(shop.sell());
    }
}

這樣，不管顧客類 Customer 訪問什么商店，或者增加新的商店，都不需要修改原有代碼了，其類如下圖所示：



程序代碼如下：

package principle;
public class DIPtest
{
    public static void main(String[] args)
    {
        Customer wang=new Customer();
        System.out.println("顧客購買以下商品："); 
        wang.shopping(new ShaoguanShop()); 
        wang.shopping(new WuyuanShop());
    }
}
//商店
interface Shop
{
    public String sell(); //賣
}
//韶關網店
class ShaoguanShop implements Shop
{
    public String sell()
    {
        return "韶關土特產：香菇、木耳……"; 
    } 
}
//婺源網店
class WuyuanShop implements Shop
{
    public String sell()
    {
        return "婺源土特產：綠茶、酒糟魚……"; 
    }
} 
//顧客
class Customer
{
    public void shopping(Shop shop)
    {
        //購物
        System.out.println(shop.sell()); 
    }
}

程序的運行結果如下：

顧客購買以下商品：
韶關土特產：香菇、木耳……
婺源土特產：綠茶、酒糟魚……

介面隔離原則（介面）

介面隔離原則（Interface Segregation Principle，ISP）要求程式設計師盡量將臃腫龐大的介面拆分成更小的和更具體的接口，讓接口中只包含客戶感興趣的方法。

2002 年羅伯特·C.馬丁給「介面隔離原則」的定義是：客戶端不應該被迫依賴它不使用的方法（Clients should not be forced to depend on methods they do not use）。這個原則還有另一個定義：一個類別對另一個類別的依賴應該是建立在最小的介面上（The dependency of one class to another one should depend on the smallest possible interface）。

以上兩個定義的意思是：要為各個類別建立它們需要的專用接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類別去調用。

介面隔離原則和單一職責都是為了提高類別的內聚性、降低它們之間的耦合性，體現(xiàn)了封裝的思想，但兩者是不同的：

• #單一職責原則注重的是職責，而介面隔離原則注重的是對介面依賴的隔離。

• 單一職責原則主要是約束類，它針對的是程式中的實作和細節(jié)；接口隔離原則主要約束接口，主要針對抽象和程式整體框架的建構。

介面隔離原則的優(yōu)點

#介面隔離原則是為了約束介面、降低類別對介面的依賴性，遵循介面隔離原則有以下5 個優(yōu)點。

• 將臃腫龐大的介面分解為多個粒度小的接口，可以預防外來變更的擴散，提高系統(tǒng)的靈活性和可維護性。

• 介面隔離提高了系統(tǒng)的內聚性，減少了對外交互，並降低了系統(tǒng)的耦合性。

• 如果介面的粒度大小定義合理，能夠保證系統(tǒng)的穩(wěn)定性；但是，如果定義太小，則會造成介面數(shù)量過多，使設計複雜化；如果定義太大，靈活性降低，無法提供客製化服務，為整體專案帶來無法預料的風險。

• 使用多個專門的介面也能夠體現(xiàn)物件的層次，因為可以透過介面的繼承，實現(xiàn)對總介面的定義。

• 能減少專案工程中的程式碼冗餘。過大的大介面裡面通常放置許多不用的方法，實現(xiàn)這個介面的時候，就被迫設計冗餘的程式碼。

介面隔離原則的實作方法

在特定應用介面隔離原則時，應該依照下列幾個規(guī)則來衡量。

• 介面盡量小，但是要有極限。一個介面只服務於一個子模組或業(yè)務邏輯。

• 為依賴介面的類別客製化服務。只提供呼叫者需要的方法，屏蔽不需要的方法。

• 了解環(huán)境，拒絕盲從。每個項目或產品都有選定的環(huán)境因素，環(huán)境不同，介面拆分的標準就不同深入了解業(yè)務邏輯。

• 提高內聚，減少對外互動。使介面用最少的方法去完成最多的事情。

對於介面隔離，大家還是可以參考單一職責提到的範例：

public interface UserService {
    
    public void login(String username, String password);
    public void register(String email, String username, String password);
    public void logError(String msg);
    public void sendEmail(String email);
    
}

這時候，應該就能理解拆分的好處了。

迪米特法則 (類與類之間的關系)

迪米特法則（Law of Demeter，LoD）又叫作最少知識原則（Least Knowledge Principle，LKP)，產生于 1987 年美國東北大學（Northeastern University）的一個名為迪米特（Demeter）的研究項目，由伊恩·荷蘭（Ian Holland）提出，被 UML 創(chuàng)始者之一的布奇（Booch）普及，后來又因為在經典著作《程序員修煉之道》（The Pragmatic Programmer）提及而廣為人知。

迪米特法則的定義是：只與你的直接朋友交談，不跟“陌生人”說話（Talk only to your immediate friends and not to strangers）。其含義是：如果兩個軟件實體無須直接通信，那么就不應當發(fā)生直接的相互調用，可以通過第三方轉發(fā)該調用。其目的是降低類之間的耦合度，提高模塊的相對獨立性。

迪米特法則中的“朋友”是指：當前對象本身、當前對象的成員對象、當前對象所創(chuàng)建的對象、當前對象的方法參數(shù)等，這些對象同當前對象存在關聯(lián)、聚合或組合關系，可以直接訪問這些對象的方法。

迪米特法則的優(yōu)點

迪米特法則要求限制軟件實體之間通信的寬度和深度，正確使用迪米特法則將有以下兩個優(yōu)點。

• 降低了類之間的耦合度，提高了模塊的相對獨立性。

• 由于親合度降低，從而提高了類的可復用率和系統(tǒng)的擴展性。

但是，過度使用迪米特法則會使系統(tǒng)產生大量的中介類，從而增加系統(tǒng)的復雜性，使模塊之間的通信效率降低。所以，在釆用迪米特法則時需要反復權衡，確保高內聚和低耦合的同時，保證系統(tǒng)的結構清晰。

迪米特法則的實現(xiàn)方法

從迪米特法則的定義和特點可知，它強調以下兩點：

• 從依賴者的角度來說，只依賴應該依賴的對象。

• 從被依賴者的角度說，只暴露應該暴露的方法。

所以，在運用迪米特法則時要注意以下 6 點。

• 在類的劃分上，應該創(chuàng)建弱耦合的類。類與類之間的耦合越弱，就越有利于實現(xiàn)可復用的目標。

• 在類的結構設計上，盡量降低類成員的訪問權限。

• 在類的設計上，優(yōu)先考慮將一個類設置成不變類。

• 在對其他類的引用上，將引用其他對象的次數(shù)降到最低。

• 不暴露類的屬性成員，而應該提供相應的訪問器（set 和 get 方法）。

• 謹慎使用序列化（Serializable）功能

明星與經紀人的關系實例。

分析：明星由于全身心投入藝術，所以許多日常事務由經紀人負責處理，如與粉絲的見面會，與媒體公司的業(yè)務洽淡等。這里的經紀人是明星的朋友，而粉絲和媒體公司是陌生人，所以適合使用迪米特法則，其類圖如下圖所示。



代碼如下：

package principle;
public class LoDtest
{
    public static void main(String[] args)
    {
        Agent agent=new Agent();
        agent.setStar(new Star("林心如"));
        agent.setFans(new Fans("粉絲韓丞"));
        agent.setCompany(new Company("中國傳媒有限公司"));
        agent.meeting();
        agent.business();
    }
}
//經紀人
class Agent
{
    private Star myStar;
    private Fans myFans;
    private Company myCompany;
    public void setStar(Star myStar)
    {
        this.myStar=myStar;
    }
    public void setFans(Fans myFans)
    {
        this.myFans=myFans;
    }
    public void setCompany(Company myCompany)
    {
        this.myCompany=myCompany;
    }
    public void meeting()
    {
        System.out.println(myFans.getName()+"與明星"+myStar.getName()+"見面了。");
    }
    public void business()
    {
        System.out.println(myCompany.getName()+"與明星"+myStar.getName()+"洽淡業(yè)務。");
    }
}
//明星
class Star
{
    private String name;
    Star(String name)
    {
        this.name=name;
    }
    public String getName()
    {
        return name;
    }
}
//粉絲
class Fans
{
    private String name;
    Fans(String name)
    {
        this.name=name;
    }
    public String getName()
    {
        return name;
    }
}
//媒體公司
class Company
{
    private String name;
    Company(String name)
    {
        this.name=name;
    }
    public String getName()
    {
        return name;
    }
}

程序的運行結果如下：

粉絲韓丞與明星林心如見面了。
中國傳媒有限公司與明星林心如洽淡業(yè)務。

?到此，設計模式的六大原則就講完了。

更多編程相關知識，請訪問：編程教學！！

以上是設計模式的六大原則是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！