The open closed principle

The open closed principle, the ancestor of all principles, is closed to modification and open to expansion.

Richter’s substitution principle

When two classes have an inheritance relationship, a subclass cannot modify methods and variables of its parent class. Substitution in Richter substitution means that where there is a superclass, the superclass can be replaced with a subclass without affecting the program, which follows the Richter substitution principle. When the substitution of subclass has an impact on the program, it means that the subclass has changed the method of the parent class, so it does not follow the Substitution principle;

Principle of dependence inversion

The inverted dependence principle is a realization of the open and closed principle, which is open to expansion and closed to modification. The core idea is to program to interfaces, not implementations.

From C Chinese language

This is a UML diagram that adheres to the dependency inversion principle. Originally, when a customer purchases a product, the shopping method is passed into the corresponding online store, and when the store is changed, the shopping method in Cusromer class is modified. Now, just define a Shop interface. All stores implement this interface method. The shopping method of the customer class is simply passed in to the Shop interface class. Then when the concrete implementation, where to buy, you can pass in which shop, without modifying the Cusromer class method;

// The code comes from 'C Chinese language'.

public class DIPtest

{

    public static void main(String[] args)

    
{

        Customer wang=new Customer();

        System.out.println("Customers purchase the following items:"); 

        wang.shopping(new ShaoguanShop()); 

        wang.shopping(new WuyuanShop());

    }

}

/ / store

interface Shop

{

    public String sell(a)/ / sell

}

// Shaoguan online store

class ShaoguanShop implements Shop

{

    public String sell(a)

    
{

        return "Shaoguan local products: mushroom, agaric......"

    } 

}

// Wuyuan Online shop

class WuyuanShop implements Shop

{

    public String sell(a)

    
{

        return "Wuyuan local products: green tea, fermented fish..."

    }



/ / the customer

class Customer

{

    public void shopping(Shop shop)

    
{

        / / shopping

        System.out.println(shop.sell()); 

    }

}



/ / output

Customers purchase the following items:

Shaoguan local products: mushroom, agaric......

Wuyuan local products: green tea, fish with distiller's grains...

Copy the code

Single responsibility

Single responsibility requires that a class be responsible for only one responsibility; This sounds simple, but in practice it can be very difficult to master. Because this is a very abstract concept in China, and China is a country with a very rich cultural heritage, as the example in the book “Zen of Design Patterns” says: For example, Chinese chopsticks can be used as a knife to cut up food, or as a fork to get food. In foreign countries, fork is fork, used to get food, and knife is used to cut up food. So this single responsibility requires a lot of practical experience on the part of the software developer. Otherwise it is difficult to grasp;

Demeter’s law

Demeter’s law, also known as the least known principle, says that the less a class exposes, the better.

  1. From the dependency’s point of view, rely only on what you should depend on.
  2. From the dependent’s point of view, expose only the methods that should be exposed.

Personal understanding: When A class needs to call A class B of the three methods to achieve function, class B can be one of the three methods, encapsulation, and then exposed to encapsulate this method to A, only such A it only need to call the encapsulation method B is ok, when B of the three methods of modification, just modify the foreign encapsulation method B, However, the caller of A does not need to change, because A only knows that the function can be realized by calling this method, but does not need to know how to implement it inside B, which reduces the coupling degree of the program.

Interface isolation Rule

It’s a little bit like a single responsibility, but it’s different.

  • The single responsibility principle focuses on responsibilities, while the interface isolation principle focuses on isolation of interface dependencies.
  • The single responsibility principle is mainly the constraint class, which is aimed at the implementation and details in the program; The interface isolation principle mainly restricts the interface, and mainly aims at the abstraction and the construction of the overall framework of the program.

Official definition: Requires programmers to break up bulky interfaces into smaller, more specific ones that contain only methods of interest to the client, reducing coupling.

This law should also be applied according to the actual business scenario, if the granularity control is too small, it will lead to a sharp increase in the class, obviously a function as long as three or four classes, if the granularity is small, it will become a dozen, or even dozens, although this program coupling degree is low, more flexible, but difficult to maintain ah. If the granularity is large, the coupling degree will be high and the program will not be flexible. So this principle requires the technical person to have enough practice, experience and understanding;

Principle of composite reuse

It requires that in software reuse, we should first use the association relationship such as composition or aggregation, and then consider the inheritance relationship. If inheritance is to be used, the Richter substitution principle must be strictly followed. The synthetic reuse principle and the Richter substitution principle complement each other, both of which are the concrete implementation specifications of the open – closed principle.

If you don’t know what is combination and aggregation, you can see this article << combination, aggregation and inheritance of love and Hatred >>, it is good

conclusion

Try to follow the seven principles of OOP in your programming. But as the saying goes, rules are dead, people are alive. Sometimes there are business scenarios that are difficult to maintain if they follow these principles, so everything needs to be practical. The same goes for the 23 design patterns. Don’t follow the rules.