Overview of Design Patterns

1. Why are there design patterns? In software development, only change is the only truth. Only change is permanent.

2. Design principles:

      1. Find out the possible changes in the application, separate them out, and don't mix them with code that doesn't need to be changed. Simply put, separate changes. Encapsulate the parts that may change so that other parts are not affected.

      2. Strive for loose coupling design between interactive objects.
  
      3. For interface programming, not for implementation programming.

      4. Use combination and inheritance less.

      5. Open for extension and closed for modification. When designing a class, it is not allowed to modify the existing class and provide some extensions.

      6. Dependency inversion principle: rely on abstraction, not on concrete classes.
             a. A variable cannot hold a reference to a specific class.
             b, do not let the class be derived from a concrete class.
             c. Do not override the implemented methods in floating classes.

      7. The principle of least knowledge: Only talk to your close friends. Inside a method we should only call methods belonging to the following scope:
             a. The object itself.
             b. The object that is passed in as the parameter of the method.
             c. Any object created or instantiated by this method.
             d. Any component of the object.

That is to say, an object is the return result of calling other methods, and do not call the method of the object.
example:
  
//don't use this principle
	public float getTemp(){
		return temp.getStation().getTemp();
	}
	//should use this principle
		public float getTemp(){
			return station.getTemp();
		}
		

       
       8. Hollywood principle: don't call us we will call you. Low-level components do not call high-level components. It is up to the high-level components to control when and how to involve the lower-level components. Avoid having circular dependencies between high-level components and low-level components.

       9. A class should have only one reason for change. i.e. a class should only have a single responsibility. If a class has two reasons for change, then as the probability of future change increases, when it does change, both aspects are affected, and the probability of error increases greatly.




Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326757739&siteId=291194637