Writing in the front
Hello, I’m Grey Ape! A super bug writing program ape!
In my last article, I introduced 21 design patterns that are common in software development. I gave her the design Pattern Guide!”
To learn design patterns well, it is not enough to understand concepts two days a day, it needs you to constantly explore the true meaning of existence in practice! So today I’m going to talk to you about six design principles that design patterns should follow,
The six principles of design patterns can be divided into:
- Single responsibility principle, the implementation of the class should be single responsibility;
- Richter’s substitution, don’t break the inheritance system;
- Depend on inversion principle, should be oriented to interface programming;
- Interface isolation principle, in the design of interface should be simple;
- Demeter principle, reduce coupling;
- On/off principle: open for extension, closed for modification.
One, single responsibility principle
The single responsibility principle defines that a class is responsible for only a corresponding responsibility in a functional area, or that there should be only one reason for a class to change.
The single responsibility principle tells us that a class can’t be too “tired”! In software systems, a class (big to the module, small to method) to assume the responsibility of, the more it is reuse the possibility of the smaller, and a class to assume the responsibility of too much, is equivalent to the duty coupled together, when one of the responsibilities change, may affect the operation of other duties, so these responsibilities, Encapsulate different responsibilities in different classes, that is, encapsulate different reasons for change in different classes, or encapsulate multiple responsibilities in the same class if they always change at the same time.
The single responsibility principle is the guideline to achieve high cohesion and low coupling. It is the simplest but most difficult principle to use, requiring designers to discover different responsibilities of classes and separate them, while discovering multiple responsibilities of classes requires designers to have strong analysis and design ability and relevant practical experience.
2. Richter’s substitution principle
Liskov Substitution Principle (LSP) means that if a software entity uses a base class, it must apply to its subclasses, and the software system cannot tell the difference between the base and subclass objects.
That is, in a software system, the behavior of the program does not change if the base class is replaced by its subclasses. However, it should be noted that the Richter substitution principle only indicates that the object of the subclass is used to replace the object of the base class, and the reverse substitution is not tenable.
For example, if a software module uses a subclass object, using a superclass object to replace a subclass object may cause an error.
In a simple sentence: Wherever a base object can appear, a subclass object can replace a base object.
3. Reliance inversion principle
Dependence Inversion Principle (DIP) is to rely on abstractions, not implementations, or to program for interfaces, not implementations.
The design and implementation of the system should use interfaces and abstract classes for variable type declaration, parameter type declaration, method return type description, and data type conversion, and do not use concrete classes for the above operations. To ensure this, a concrete class should implement only the methods declared in the interface and abstract class, and not give out redundant methods. The traditional design method of procedural system tends to make the high-level module depend on the low-level module and the abstract level depend on the concrete level.
The principle of dependency reversal is to reverse the bad dependency. An important principle of object-oriented design is to create a level of abstraction and to derive from that level of abstraction concrete levels that give different implementations.
Inheritance relation is a kind of derivation from abstraction to concretization. The abstraction level should contain the business logic of the application system and the macro, strategic decisions that are important to the system as a whole, while the concrete level contains some secondary implementation-related algorithms and logic, as well as tactical decisions with a certain degree of contingency choice. From the perspective of reuse, high-level abstract module should be reused, and is the focus of reuse, because it contains the most important macro business logic of an application system, is a relatively stable part. In traditional procedural design, reuse focuses on module reuse at specific level.
The dependency reversal principle recommends not relying on concrete classes, that is, all dependencies in a program should terminate in an abstract class or interface. Do as much as possible: no variable should hold a pointer or reference to a concrete class; No class should be derived from a concrete class; No method should override methods already implemented in any of its base classes.
four , interface isolation principle
The interface isolation principle defines the use of multiple specialized interfaces rather than a single master interface, that is, clients should not rely on interfaces that they do not need.
According to the interface isolation principle, when an interface is too large, we need to divide it into smaller interfaces, and the clients using the interface need only know the methods associated with it. Each interface should assume a relatively independent role, not doing what should not be done, do what should be done. The term “interface” is often used in two different ways: one refers to the collection of method characteristics of a type, which is merely a logical abstraction; The other is the specific “interface” definition of a language, with a strict definition and structure,
five Demeter’s rule
Demeter Principle Definition: Law of Demeter (LoD) : A software entity should interact with as few other entities as possible.
That is: if two software entities do not have to communicate directly, then direct calls to each other should not occur and can be forwarded by a third party. Its purpose is to reduce the degree of coupling between classes and improve the relative independence of modules.
Six, open – close principle
The open-closed Principle is the cornerstone of Object Oriented Design (00D). The open-closed principle states that a software entity should be open for extension and closed for modification, that is, a module should be designed so that it can be extended without modification.
The system that meets the open-closed principle can extend the existing software system to provide new capabilities and behaviors to meet the new requirements of software and make the software system have certain adaptability and flexibility.
Because the existing software module, especially the most important abstract layer module can not be modified, this makes the changing software system has a certain stability and continuity;
The system satisfying the open – close principle has better reusability and maintainability. In object-oriented programming, through abstract classes and interfaces, the characteristics of concrete classes are defined as the abstraction layer, which is relatively stable, so as to meet the requirement of “close to modification”. Concrete classes derived from abstract classes can change the behavior of the system to meet the requirements of being open to extension.
These six design principles are the basis for development using 21 design patterns, and each design pattern should be used as closely as possible to follow these six principles.
Think useful remember to like attention!
Grey ape accompany you to progress together!
