Six basic guidelines for JAVA design patterns to follow

Six basic guidelines for JAVA design patterns to followa single principle of responsibility: (Responsibility pinciple)

　A class is responsible for only one responsibility. When more than one responsibility is required, new classes need to be added to take responsibility for new responsibilities, rather than personality codes in the class.

If a class takes on too many responsibilities, it is highly functional coupling, which is very detrimental to extended functionality. This is a very fragile design. A situation where it is easy to change a place and affect other places.

The advantages of following a single responsibility principle:

1. Reduce the complexity of classes
2. Improve the readability of the class and improve the maintainability of the system
3. Reduced risk due to change

second, the principle of substitution of the Richter scale: (Liskov Substitution Principle, abbreviation LSP) subclasses can extend the functionality of the parent class, but cannot change the original function of the parent class

The Richter substitution principle (Liskov Substitution Principle, LSP): All references to the base class (parent class) must be able to transparently use objects of its subclasses.

The principle of substitution on the Richter scale tells us that in a software system, subclasses should be able to replace any base class where it can appear, and that the code will work properly after being replaced. Subclasses can also add new behavior based on the base class.

For example, there are two classes, one class is BaseClass, the other is the subclass class, and the subclass class is a subclass of the BaseClass class, so if a method can accept a base class object base of BaseClass type, such as: Method1 ( Base), then it is bound to accept a subclass object of type BaseClass sub,method1 (sub) to function properly. Conversely, substitution is not tenable, such as a method Method2 accepts a subclass object of type BaseClass as a parameter: Method2 (sub), then generally there is no method2 (base), unless it is an overloaded method.

The principle of substitution of the Richter scale is one of the important ways to realize the open and closed principle, because the subclass object can be used wherever the base class object is used, so as far as possible the base class type is used in the program to define the object, while at run time the subclass type is determined, and the child class object is substituted for the parent class object.

Contains 4 levels of meaning:

1. Subclasses can implement the abstract methods of the parent class, but cannot override the non-abstract methods of the parent class.
2. Subclasses can add their own unique methods.
3. When a method of a subclass overloads a method of the parent class, the method's preconditions (that is, the parameter of the method) are more lenient than the input parameters of the parent class method.
4. When a method of a subclass implements an abstract method of the parent class, the post condition of the method (that is, the return value of the method) is stricter than the parent class.

The consequence of not following the Richter substitution principle is that the chances of writing code errors are greatly increased.

third, the dependency inversion principle (dependence inversion Principle, referred to as dip)

Definition:1. High-level modules should not rely on the lower layer modules, both should rely on their abstraction; 2. Abstraction should not depend on detail; Details should depend on abstraction.

The problem is that class A is directly dependent on class B, and if you want to change Class A to dependency Class C, you must modify the code of Class A to achieve it. In this scenario, Class A is typically a high-level module that is responsible for complex business logic, and Class B and Class C are low-layer modules that are responsible for basic atomic operations, and if Class A is modified, it poses unnecessary risks to the program.

Solution: Modify Class A to dependent interface I, Class B and Class C each implement interface I, Class A through interface I indirectly with Class B or Class C, it will greatly reduce the chance to modify Class A.

The dependency inversion principle is based on the fact that abstract things are much more stable relative to the variability of details. Structures built on the basis of abstraction are much more stable than structures built on the basis of detail. In Java, abstract refers to an interface or abstract class, the details are specific implementation classes, the use of interfaces or abstract classes to make good specifications and contracts, not to involve any specific operation, the task of presenting details to their implementation class to complete.

Three ways to pass a dependency:

1. Constructors Pass dependent objects
2.Setter Method Passing dependent objects
3. Interface declaration passing dependent objects

In-depth insight: Easy to learn, analysis of dependency inversion (DIP), control inversion (IOC), and Dependency injection (DI)

Iv. Interface Isolation principle (Interface segregation Principle, referred to as ISP)

• Core idea : dependencies between classes should be based on the smallest interfaces
• Generally speaking: to establish a single interface, do not build a huge bloated interface, as far as possible to refine the interface, the interface of the method as little as possible. That is, instead of trying to create a very large interface for all classes that depend on it, we need to create a dedicated interface for each class.

For example, the problem is that class A relies on class B through interface I, Class C relies on the Class D through interface I, and if interface I is not the smallest interface for Class A and Class B, then Class B and Class D must implement methods that they do not need.

For example, the principle of interface isolation:

(Figure 1 design that does not follow the principle of interface isolation)

This figure means that class A relies on Method 1, Method 2, Method 3 in interface I, and Class B is the implementation of Class A dependency. Class C relies on Method 1, Method 4, Method 5 in interface I, and Class D is the implementation of Class C dependency. For Class B and Class D, although they all have methods that are not available (that is, the method of marking the red font in the figure), but because of the implementation of interface I, it is also necessary to implement these methods that are not available.

Solution: Split the bloated interface I into separate interfaces, and Class A and Class C are dependent on the interfaces they need. That is, the principle of interface isolation.

As you can see, if the interface is too bloated, as long as the method appearing in the interface, regardless of the usefulness of the classes that depend on it, the implementation class must implement these methods, which is obviously not a good design. If the design is modified to conform to the interface isolation principle, the interface I must be split. Here we split the original interface I into three interfaces, split the design 2 as shown:

(Figure 2 follows the design of the interface isolation principle)

• Be aware that:
• the interface is as small as possible, but there are limits . The refinement of the interface can improve the programming flexibility, but if it is too small, it will cause too many interfaces and complicate the design. So be sure to moderate
• increased cohesion, low coupling = reduced external interaction . Each module accomplishes its own functions as independently as possible, and does not depend on the code outside the module. cohesion and coupling are closely related, and modules that have high coupling with other modules mean low cohesion, while the high cohesion module implies a low coupling between the module and other modules. In the software design, we should strive to achieve high cohesion, low coupling.
• Customizing services for interfaces-dependent classes . Only exposes the calling class to the method it needs, and the method it does not need is hidden. A minimal dependency can be established only by focusing on providing a customized service for a module.

v. Dimitri rule (Law of Demeter, abbreviated LOD)

The Dimitri Law has many different claims, such as: A class should know the least of the other classes, and the class communicates only with direct friends, and so on. But there is only one final goal, which is to decouple the classes.

Defined

• Dimitri: Law of Demeter,lod.
• Also known as the least knowledge principle, Least knowledge principle,lkp.

This means that an object should keep a minimum of knowledge of other objects. As with the definition of least knowledge principle, a class should know least about the other classes it is coupled with or the classes it calls. The coupling of the class inside anyway complex, how to implement I do not need to know, I only call you public out of these methods, others do not need to know.

　　Reference Document-Dimitri law

Vi. Open Closure principle (open close Principle, OCP)

The so-called open closure principle is that software entities should be open to extensions and closed to modifications. The open closure principle is the core of all object-oriented principles. The goal of software design itself is to package change, reduce coupling, and open closed principle is the most direct embodiment of this goal.

The principle of open closure is mainly embodied in two aspects:

• Opening up to extensions means that existing code can be extended to accommodate new situations when there are new requirements or changes.
• Closing a modification means that once the class is designed, it can work independently of the class, rather than making any modifications to the classes.

　　Why should we use the principle of open closure?

Software requirements are always changing, there is no software in the world is unchanged, so for software designers, must not need to modify the original system, the implementation of flexible system expansion.

　　How do you open to extensions, to modify the closed?

The core idea of open closure is to abstract programming, not specific programming, because the abstraction is relatively stable. Let the class depend on the fixed abstraction, so the modification of (abstract class) is closed, but through object-oriented inheritance and polymorphism mechanism, can realize the inheritance of the abstract body, by covering its methods to change the inherent behavior, to implement a new extension method, so for the extension is open.

Classes that violate this principle must be improved by refactoring. The design patterns commonly used in implementation are the template method mode and the strategy mode. Package change is an important means to realize this principle, and encapsulate the frequently changing state as a class.

Code Reference example: a bank clerk as an example

Summarize:

1. The principle of single responsibility tells us that the realization of class should be a single function;
2. The Richter replacement principle tells us not to break the inheritance system;
3. The dependency inversion principle tells us to interface-oriented programming;
4. The interface isolation principle tells us to simplify the design of the interface;
5. The Dimitri law tells us to reduce coupling. And the open and closed principle is the master, he tells us to be opened on the extension, close to the modification.

Six basic guidelines for JAVA design patterns to follow