The six principles of design patterns: 1. The single responsibility principle, the core of which is to control the granularity of classes, decouple objects, and improve their cohesion; 2. The opening and closing principle, which can be achieved through "abstract constraints" , encapsulation changes" to achieve; 3. The Liskov substitution principle mainly explains some principles about inheritance; 4. The dependency inversion principle reduces the coupling between clients and implementation modules; 5. The interface isolation principle is to constrain the interface , Reduce the dependence of classes on interfaces; 6. Demeter's law requires limiting the width and depth of communication between software entities.

The operating environment of this tutorial: windows7 system, java8 version, DELL G3 computer.

Regarding design patterns, I have read many design pattern books a long time ago, and I have read some of them several times. I have always hoped that I can use these design patterns when coding. However, in daily coding, the singleton is used most, followed by the observer and builder patterns (builder), which are used more frequently, and the others are rarely used.

The reason why they are not used is that they still cannot understand the idea of ??design patterns and cannot connect these design patterns with the problems encountered in coding, so they cannot use design patterns.

In fact, the design patterns are proposed to solve a common problem. So when you think about which design pattern to adopt, you should first ask yourself what is the current problem? Choose the appropriate design pattern based on the problem.

After you become familiar with design patterns, you will find that there is an inclusive relationship between some design patterns, and they are even very similar, but different design patterns solve different problems.

When we design a module, we can consider it from the following perspectives:

• What is the relationship between this module and other modules?

• # Which parts of the module are unchanged, which parts are constantly changing, and how?

• #What is the relationship between classes? Why do we need to rely on them? How can we not rely on them?

• # Do you want to add an interface? What problem does the interface exist to solve?

Of course, this article does not teach you how to use design patterns. Rather, it explains the design principles of design patterns. Design patterns also follow some rules when they are designed.

The six principles of design patterns are as follows:

• Single responsibility principle (classes, methods, interfaces)

• Opening and closing principle (open for extension, closed for modification)

• Rich substitution principle (relationship between base class and subclass )

• Dependency inversion principle (rely on abstract interfaces, not concrete objects)

• Interface isolation principle (interfaces are subdivided according to functions)

• Dimiter's Law (closeness relationship between classes)

There are brackets next to each design principle to explain or describe the scope of application. Each principle is described in detail below.

Definition of single responsibility principle (class, method, interface)

Single Responsibility Principle (SRP) is also called the single function principle. The responsibility here refers to the reason for the change of the class. The single responsibility principle stipulates that a class should have and only one reason for its change, otherwise the class should be split (There should never be more than one reason for a class to change).

This principle states that objects should not assume too many responsibilities. If an object assumes too many responsibilities, there will be at least the following two disadvantages:

• Changes in one responsibility may weaken or inhibit the ability of this class to implement other responsibilities;

• When the client needs a certain responsibility of the object, it must not Not including all other unnecessary responsibilities leads to redundant code or wasted code.

Advantages of the Single Responsibility Principle

The core of the Single Responsibility Principle is to control the granularity of classes. Decouple objects and improve their cohesion. If you follow the single responsibility principle, you will have the following advantages.

• Reduce the complexity of the class. If a class is responsible for only one responsibility, its logic is definitely much simpler than if it is responsible for multiple responsibilities.

• #Improve the readability of the class. The complexity is reduced, and the readability is naturally improved.

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

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

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

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

示例

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/>

假設(shè)我要修改發(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ù)類名，確保里面提供的方法都是屬于這個類的。

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

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

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

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

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

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

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

}

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

}

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

開閉原則

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

因為抽象靈活性好，適應(yīng)性廣，只要抽象的合理，可以基本保持軟件架構(gòu)的穩(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();
    }
}

假設(shè)這時候，又多了一個圓形類

// 圓形
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.");
        }
    }
}

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

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

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;
    }
}

When calculating the area of ??triangles and quadrilaterals..., we only need to let them implement the Shape interface without modifying the source code.

The Richter Substitution Principle

The Richter Substitution Principle mainly explains some principles about inheritance, that is, when should inheritance be used and what When should not use inheritance, and the principles underlying it. Liskov substitution is originally the basis for inheritance reuse. It reflects the relationship between base classes and subclasses, supplements the opening and closing principle, and regulates the specific steps to achieve abstraction.

The role of Liskov substitution principle

The main functions of Liskov substitution principle are as follows.

• The Liskov substitution principle is one of the important ways to realize the opening and closing principle.

• #It overcomes the shortcomings of poor reusability caused by overriding the parent class in inheritance.

• #It is the guarantee of the correctness of the action. That is, the extension of the class will not introduce new errors into the existing system, reducing the possibility of code errors.

• Enhance the robustness of the program, and achieve very good compatibility when changing, improve the maintainability and scalability of the program, and reduce the time required to change requirements. introduced risks.

How to implement the Liskov substitution principle (inheritance)

In layman terms, the Liskov substitution principle That is: subclasses can extend the functions of the parent class, but they cannot change the original functions of the parent class. In other words: when a subclass inherits a parent class, try not to override the parent class's methods except adding new methods to complete new functions.

Based on the above understanding, the definition of the Liskov substitution principle can be summarized as follows:

• Subclasses can implement the abstract methods of the parent class, but cannot override the parent class. Non-abstract methods of the class

• Subclasses can add their own unique methods

• When a method of a subclass overrides a method of a parent class, the preconditions of the method (i.e., the input parameters of the method) are looser than the method of the parent class

• When a method of a subclass implements a method of a parent class (overwriting/overloading or implementing an abstract method), the postconditions of the method (i.e. the output/return value of the method) are stricter or equal to those of the parent class

Although it is simple to write new functions by overriding the parent class method, the reusability of the entire inheritance system will be relatively poor, especially when polymorphic comparison is used. Frequently, the probability of program running errors will be very high.

If the program violates the Liskov substitution principle, the object of the inherited class will have a runtime error where the base class appears.

The correction method at this time is: cancel the original inheritance relationship and redesign the relationship between them.

Regarding the example of Liskov substitution principle, the most famous one is "a square is not a rectangle". Of course, there are many similar examples in life. For example, penguins, ostriches and kiwis are classified as birds from a biological perspective; but from a class inheritance relationship, because they cannot inherit the "bird" ability to fly function, so they cannot be defined as subclasses of "bird". Similarly, since "balloon fish" cannot swim, it cannot be defined as a subcategory of "fish"; "toy cannon" cannot blow up enemies, so it cannot be defined as a subcategory of "cannon", etc.

The best way for squares and rectangles is to add another parent class, and they inherit from this parent class at the same time.

Dependency Inversion (Wire Drawing Details)

The dependency inversion principle is one of the important ways to realize the opening and closing principle. It reduces the gap between customers and implementation modules. coupling between.

Because in software design, details are changeable, while the abstraction layer is relatively stable, so an architecture built on abstraction is much more stable than an architecture built on details. . The abstract here refers to the interface or abstract class, and the details refer to the specific implementation class.

The purpose of using interfaces or abstract classes is to formulate specifications and contracts without involving any specific operations, and leave the task of showing details to their implementation classes.

The functions of dependence and inversion principles

The main functions of the dependence inversion principle are as follows.

• The dependency inversion principle can reduce the coupling between classes.

• #The dependency inversion principle can improve the stability of the system.

• #The dependency inversion principle can reduce the risks caused by parallel development.

• #The dependency inversion principle can improve the readability and maintainability of code.

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

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

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

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

• 任何類都不應(yīng)該從具體類派生。

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

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

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

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

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

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

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

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

解決方法是：定義“婺源網(wǎng)店”和“韶關(guān)網(wǎng)店”的共同接口 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(); //賣
}
//韶關(guān)網(wǎng)店
class ShaoguanShop implements Shop
{
    public String sell()
    {
        return "韶關(guān)土特產(chǎn)：香菇、木耳……"; 
    } 
}
//婺源網(wǎng)店
class WuyuanShop implements Shop
{
    public String sell()
    {
        return "婺源土特產(chǎn)：綠茶、酒糟魚……"; 
    }
} 
//顧客
class Customer
{
    public void shopping(Shop shop)
    {
        //購物
        System.out.println(shop.sell()); 
    }
}

程序的運行結(jié)果如下：

顧客購買以下商品：
韶關(guān)土特產(chǎn)：香菇、木耳……
婺源土特產(chǎn)：綠茶、酒糟魚……

接口隔離原則（接口）

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

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

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

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

• 單一職責原則注重的是職責，而接口隔離原則注重的是對接口依賴的隔離。

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

接口隔離原則的優(yōu)點

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

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

• 接口隔離提高了系統(tǒng)的內(nèi)聚性，減少了對外交互，降低了系統(tǒng)的耦合性。

• 如果接口的粒度大小定義合理，能夠保證系統(tǒng)的穩(wěn)定性；但是，如果定義過小，則會造成接口數(shù)量過多，使設(shè)計復(fù)雜化；如果定義太大，靈活性降低，無法提供定制服務(wù)，給整體項目帶來無法預(yù)料的風險。

• 使用多個專門的接口還能夠體現(xiàn)對象的層次，因為可以通過接口的繼承，實現(xiàn)對總接口的定義。

• 能減少項目工程中的代碼冗余。過大的大接口里面通常放置許多不用的方法，當實現(xiàn)這個接口的時候，被迫設(shè)計冗余的代碼。

接口隔離原則的實現(xiàn)方法

在具體應(yīng)用接口隔離原則時，應(yīng)該根據(jù)以下幾個規(guī)則來衡量。

• 接口盡量小，但是要有限度。一個接口只服務(wù)于一個子模塊或業(yè)務(wù)邏輯。

• 為依賴接口的類定制服務(wù)。只提供調(diào)用者需要的方法，屏蔽不需要的方法。

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

• 提高內(nèi)聚，減少對外交互。使接口用最少的方法去完成最多的事情。

對于接口隔離，大家還是可以參考單一職責提到的示例：

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);
    
}

這時候，應(yīng)該就能理解拆分的好處了。

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

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

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

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

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

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

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

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

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

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

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

• 從依賴者的角度來說，只依賴應(yīng)該依賴的對象。

• 從被依賴者的角度說，只暴露應(yīng)該暴露的方法。

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

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

• 在類的結(jié)構(gòu)設(shè)計上，盡量降低類成員的訪問權(quán)限。

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

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

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

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

明星與經(jīng)紀人的關(guān)系實例。

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



代碼如下：

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();
    }
}
//經(jīng)紀人
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è)務(wù)。");
    }
}
//明星
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;
    }
}

程序的運行結(jié)果如下：

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

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

更多編程相關(guān)知識，請訪問：編程教學??！

The above is the detailed content of What are the six principles of design patterns?. For more information, please follow other related articles on the PHP Chinese website!