1. Open Closed Principle (OCP): when the application requirements change, the functions of the module can be extended to meet the new requirements without modifying the source code or binary code of the software entity.

1. Liskov Substitution Principle (LSP): subclasses can extend the functions of the parent class, but cannot change the original functions of the parent class. In other words, when a subclass inherits from the parent class, in addition to adding new methods to complete the new functions, try not to override the methods of the parent class.

1. Dependency Inversion Principle (DIP): high-level modules should not rely on low-level modules, and both should rely on their abstraction; Abstract should not rely on details, details should rely on abstraction. Its core idea is: interface oriented programming, not implementation oriented programming.

Code violating the dependency inversion principle (the customer must modify the code every time he changes a store, which obviously violates the opening and closing principle. The reason for the above shortcomings is that the customer class is bound to the specific store class during design, which violates the dependency inversion principle):

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

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

The modified code conforming to the dependency inversion principle (defines the common interface Shop of "Wuyuan online store" and "Shaoguan online store". The customer class is programmed for this interface, and the code is modified as follows:)

public class DIPtest{
    public static void main(String[] args){
        Customer wang=new Customer();
        System.out.println("Customers buy the following goods:"); 
        wang.shopping(new ShaoguanShop()); 
        wang.shopping(new WuyuanShop());
    }
}
//Shop
interface Shop{
    public String sell(); //sell
}
//Shaoguan online store
class ShaoguanShop implements Shop{
    public String sell(){
        return "Shaoguan local specialties: mushrooms, fungus"; 
    } 
}
//Wuyuan online store
class WuyuanShop implements Shop{
    public String sell(){
        return "Wuyuan local specialties: green tea, lees fish"; 
    }
} 
//customer
class Customer{
    public void shopping(Shop shop){
        //shopping
        System.out.println(shop.sell()); 
    }
}

1. Single Responsibility Principle (SRP): the Single Responsibility Principle stipulates that a class should have and only have one reason for its change, otherwise the class should be split

1. Interface aggregation principle (ISP): you should establish the special interface for each class, instead of trying to establish a huge interface for all classes that depend on it to call.

1. Law of Demeter (LoD), also known as Least Knowledge Principle (LKP): if two software entities do not need to communicate directly, direct mutual calls should not occur, and the calls can be forwarded through a third party. Its purpose is to reduce the coupling between classes and improve the relative independence of modules. The "friend" in the law of Demeter It refers to the current object itself, the member object of the current object, the object created by the current object, the method parameters of the current object, etc. these objects are associated, aggregated or combined with the current object, and the methods of these objects can be accessed directly.

public class LoDtest{
    public static void main(String[] args){
        Agent agent=new Agent();
        agent.setStar(new Star("Lin Xinru"));
        agent.setFans(new Fans("Fan Han Cheng"));
        agent.setCompany(new Company("China Media Co., Ltd"));
        agent.meeting();
        agent.business();
    }
}
//agent
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()+"With stars"+myStar.getName()+"We met.");
    }
    public void business(){
        System.out.println(myCompany.getName()+"With stars"+myStar.getName()+"Negotiate business.");
    }
}
//Star
class Star{
    private String name;
    Star(String name){
        this.name=name;
    }
    public String getName(){
        return name;
    }
}
//fans
class Fans{
    private String name;
    Fans(String name){
        this.name=name;
    }
    public String getName(){
        return name;
    }
}
//Media company
class Company{
    private String name;
    Company(String name){
        this.name=name;
    }
    public String getName(){
        return name;
    }
}

1. Composite Reuse Principle (CRP), also known as Composition/Aggregate Reuse Principle (CARP): it requires that when software reuse is carried out, association relations such as composition or aggregation should be used first, and inheritance relations should be considered second.

The opening and closing principle is the general outline, which tells us to be open to expansion and close to modification; the Richter substitution principle tells us not to destroy the inheritance system; the dependency inversion principle tells us to program towards the interface; the single responsibility principle tells us to implement the class with single responsibility; the interface isolation principle tells us to simplify and single when designing the interface; and the Dimitri law tells us to Reduce the coupling degree; the composite reuse principle tells us to give priority to the reuse of combination or aggregation relations and less inheritance relations.