[Small talk design mode] object-oriented design principles

Labels: OCP Java design mode Object-Oriented Design

1. Single Responsibility Principle

The core idea of a single responsibility principle is: every object in the system should have only one independent responsibility, and all objects are concerned with the completion of their own responsibilities. SRP single Responsibility Principle

Single Responsibility Principle-"High Cohesion and low coupling", each class should have only one responsibility, and only one function can be provided, and there should be only one reason for class changes. All design patterns follow this principle.

Advantages:

Can reduce the complexity of the class;

Improve readability and maintainability of the system;

Reduces risks caused by changes.

2. Lee's replacement principle

The core idea of the Rys replacement principle is that it can be replaced by its subclass wherever any parent class appears. LSP liskov substitution principle

Lishi replacement principle-objects in the same inheritance system should have common behavior characteristics.

In the Rys replacement principle, all references to the base class must be transparent to use its subclass objects. That is, as long as the parent class appears, the subclass can appear, and replacing it with the subclass will not produce any errors or exceptions. In turn, replacing the Child class with the parent class may cause problems.

It has four meanings:

(1) subclass can implement abstract methods of the parent class, but cannot overwrite non-abstract methods of the parent class.

(2) subclass can have its own characteristics. That is to say, other methods or attributes can be defined on the subclass of the class.

(3) When overwriting or implementing the parent class method, the input parameter can be enlarged; otherwise, it cannot.

(4) When the subclass method implements the abstract method of the parent class, the post-condition (that is, the return value of the method) of the method is stricter than that of the parent class.

Subclass can extend the features of the parent class, but cannot change the original features of the parent class.

3. Dependency injection principles

The core idea of the dependency injection principle is: to rely on abstraction, not specific implementation. Dip dependence inversion principle (dependency inversion principle ).

Dependency injection principle-in applications, all classes should depend on the abstract classes of these other classes if they are used or dependent on other classes, instead of the specific implementation classes of these other classes. Abstract layers should not depend on specific implementation details, so as to ensure the reusability and maintainability of the system. To implement this principle, developers are required to program interfaces while programming, rather than implementing programming.

The dependency injection principles are described as follows:

1. The high-level module should not depend on the underlying module, both of which should depend on abstract (abstract class or interface)

2. abstraction (abstract classes or interfaces) should not depend on details (specific implementation classes ).

3. Details (specific implementation classes) should depend on abstraction.

The nature of the dependency injection principle is that each class or module is independent of each other through abstraction (abstract classes or interfaces) without affecting each other, so as to achieve loose coupling between modules. This principle is the most difficult to implement among the six principles. If this principle is not implemented, it means that the principle of open and closed (open to expansion and closed to modification) cannot be implemented.

The dependency injection principle is implemented in the following three methods.

(1) passing dependent objects through Constructors

For example, the parameters to be passed in the constructor are implemented using abstract classes or interfaces.

(2) Pass the dependent object through the setter method.

That is to say, the parameter in the setxxx method we set is an abstract class or interface to implement the transfer of dependency objects.

(3) interface declaration implementation dependency object

4. Interface separation principle

The core idea of the interface separation principle is: Customers should not be forced to rely on methods they do not need to use.

ISP, which is short for interface segregation principle.

Interface separation principle-an interface does not need to provide too many behaviors. An interface should only provide one external function and should not encapsulate all operations in one interface.

There are two types of interfaces:

(1) object interface

A class declared in Java is an instance generated by the new keyword. It is a description of a type of transaction, which is also an interface.

(2) Class Interface

This interface is defined by the keyword interface.

The interface separation principle requires that a module only depends on the interfaces it requires to ensure the purity of the interfaces. In addition, make sure that the interface should be as small as possible, that is, make the interface as detailed as possible when designing the interface, and do not define too bloated interfaces.

A single responsibility principle requires a single responsibility for classes and interfaces, focusing on duties and division of business logic. The interface separation principle requires as few interface methods as possible and as useful as possible for a module.

Specifications of the interface separation principle:

(1) The interface should be as small as possible: it is mainly used to ensure that an interface serves only one submodule or business logic.

(2) High interface cohesion: High interface cohesion is highly dependent on the internal environment and is isolated as much as possible. That is, the methods declared in an interface are related to a submodule and are required by this submodule.

(3) the interface design is limited: If the interface separation principle is fully followed, there will be a problem, that is, the interface design is getting smaller and smaller, which leads to a sharp increase in interface data, the complexity of the system increases at once, and this is not required by real projects. Therefore, when using this principle, You must judge based on experience or attempt in a specific project, but there is no fixed standard.

5. dumit principles

Demeter Principle.

The core idea of the dimit principle is that an object should understand as little as possible about other objects. This means to reduce the coupling between objects and improve the maintainability of the system. The dimit rule is also called the least aware principle. The module should communicate only through interfaces, regardless of the internal working principle of the module. It can minimize the Coupling Degree of each module and promote software reuse.

The core concept of the Demeter principle is inter-class decoupling and weak coupling. Class reusability can be improved only after weak coupling.

Note the following when applying the Demeter rule:

1. In terms of Class division, we should create classes with weak coupling.

2. In the structure design of classes, each class should minimize the access permissions of members.

3. In the design of classes, as long as possible, a class should be designed as a constant class.

4. When referencing other classes, a reference to an object to other objects should be minimized.

5. Minimize class access permissions.

6. Use serialization with caution.

7. Do not expose class members, but provide the corresponding accessors (attributes)

6. Open and Close principles

OCP open for extension, closed for Modification

The core idea of the open/closed principle is that an object is open to extension and closed to modification.

The open and closed principle means that the changes to the class are made by adding code, rather than modifying the existing code. That is to say, once a software developer writes the code that can be run, we should not change it, but ensure that it can continue to run. How can we achieve it? Abstract and polymorphism are required to abstract the content that may change, so that the abstract part is relatively stable, while the specific implementation layer can be changed and expanded.

According to the open/closed principle, software changes should be implemented by means of expansion, rather than by modifying the original code.

The principle of opening/closing is an abstract summary of the first five principles. The first five are some specific implementations of the principle.