The learning effect is better with the Java design pattern of Silicon Valley! Video connection

Importance of design patterns

1. In software engineering, design pattern is a solution to various common (recurring) problems in software design. This term was introduced from the field of architectural design to computer science by Erich Gamma and others in the 1990s

2. Building VS Simple house
   The construction of a building needs various feasibility studies, structural planning, and the participation of many designers in design and research.
   The simple house can be built successfully without so many steps, but the corresponding height and stability will lag far behind the building.

3. Take the actual work experience as an example. After a project is developed, what if the customer proposes to add new functions?

4. If the original programmer leaves after the project is developed, what will you do if you take over the maintenance of the project? (maintainability [readability, normalization])

5. At present, the threshold for programmers is getting higher and higher. Front line IT companies (large factories) will ask you what design patterns you have used in actual projects, how to use them, and what problems have been solved.

6. Where are design patterns in software? Object oriented (OO) = > function module [design pattern + algorithm (data structure)] = > framework [using multiple design patterns] = > Architecture [server cluster]

7. If you want to be a qualified software engineer, it is necessary to spend time studying design patterns

Purpose of design pattern

In the process of writing software, programmers are faced with challenges from coupling, cohesion, maintainability, scalability, reusability, flexibility and so on. The design pattern is to make the program (software) have better performance

1. Code reusability (i.e. code with the same function does not need to be written multiple times)
2. Readability (i.e. programming is normative and easy for other programmers to read and understand)
3. Scalability (i.e. when new functions need to be added, it is very convenient, called maintainability)
4. Reliability (i.e. when we add new functions, it has no impact on the original functions)
5. Make the program show the characteristics of high cohesion and low coupling,

Sharing the golden sentence: design patterns contain the essence of object-oriented. "If you understand design patterns, you will understand the essence of object-oriented analysis and design (OOA/D)"
Scott Mayers once said in his masterpiece Effective C + +: the difference between C + + veterans and C + + novices is that the former has many scars on the back of his hand

Seven principles of design mode

The principle of design pattern is actually the principle that programmers should abide by when programming. It is also the basis of various design patterns (i.e. the basis for why design patterns are designed like this). The seven commonly used principles of design patterns

1. Single responsibility principle
2. Interface isolation principle
3. Dependency inversion (inversion) principle
4. Richter substitution principle
5. Opening and closing principle
6. Dimitt's law
7. Synthetic Reuse Principle

Single responsibility principle

For classes, that is, a class should be responsible for only one responsibility. (it can be understood as Dao class. For example, UserDao is only responsible for adding, deleting, modifying and querying User tables, that is, a Dao is only responsible for one table)
If class A is responsible for two different responsibilities: Responsibility 1 and responsibility 2. When class A is changed due to the change of responsibility 1 requirements, the implementation error of responsibility 2 may be caused, so the granularity of class a needs to be decomposed into A1 and A2; That is, A1 is responsible for responsibility 1 and A2 is responsible for responsibility 2.

Option 1

public class SingleResponsibility1 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("automobile");
        vehicle.run("ship");
        vehicle.run("aircraft");
    }
}
Vehicles
 Analysis: in this way, the principle of single responsibility is violated, and the vehicles on the road manage the river and the sky
 Solution: according to different means of transportation, it can be divided into different classes, with a single responsibility => Option 2

class Vehicle{
    public void run(String vehicleName){
        System.out.println(vehicleName + " Running on the road");
    }
}

Option 2

public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("automobile");
        
        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("aircraft");
        WaterVehicle waterVehicle = new WaterVehicle();
        waterVehicle.run("ship");
    }
}
Strictly abide by the principle of single responsibility
 However, this has changed a lot. To decompose the class, you need to modify the client
 Improvement: direct modification Vehicle Class, the code will be changed less => Option 3
class RoadVehicle{
    public void run(String roadVehicle){
        System.out.println(roadVehicle + " Running on the road");
    }
}
// Flying in the sky
class AirVehicle{
    public void run(String roadVehicle){
        System.out.println(roadVehicle + " Flying in the sky");
    }
}
// Swimming in the water
class WaterVehicle{
    public void run(String roadVehicle){
        System.out.println(roadVehicle + " Swim in the river");
    }
}

Option 3

public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle = new Vehicle2();
        vehicle.runRoad("automobile");
        vehicle.runWater("yacht");
        vehicle.runAir("aircraft");
    }
}
Analysis of scheme 3
1. This modification method does not greatly modify the original class, but adds methods
2. Although the principle of single responsibility is not observed at the class level, it is still observed at the method level
3. Remember, a method only deals with one business, that is, a method has only one complete business logic. Do not use it if-else，Coupling is too high
class Vehicle2{
    public void runRoad(String vehicleName){
        System.out.println(vehicleName + " Running on the road");
    }
    public void runAir(String vehicleName){
        System.out.println(vehicleName + " Flying in the sky");
    }
    public void runWater(String vehicleName){
        System.out.println(vehicleName + " Swim in the river");
    }
}

Single responsibility principle considerations and details:

1. Reduce the complexity of classes. A class is responsible for only one responsibility.
2. Improve the readability and maintainability of classes
3. Reduce the risk caused by the change (modify the class running on the ground and the class flying in the sky)
4. Generally, we should abide by the principle of single responsibility. Only when the logic is simple enough can we violate the principle of single responsibility at the code level; Only when the number of methods in the class is small enough and the function of the class is simple enough can the principle of single responsibility be maintained at the method level

##Interface isolation principle