There are seven principles of software architecture design:

1. Open and close principle

2. Dependency inversion principle

3. Principle of single responsibility

4. Interface isolation principle

5. Demeter’s Law (Least Know Principle)

6. Richter’s substitution principle

7. Principle of synthesis/polymerization reuse

The following are specific:

1. Open and close principle: Open for extension, closed for modification

When designing a module, it should be possible to extend it without modifying it.

In other words, it should be possible to change the behavior of the module without modifying the source code, extending the system while maintaining some stability.

For example, the general software function upgrade needs to conform to the open closed principle, that is, do not modify the original code, but to add new functions.

2. Principle of dependency inversion: implementation relies on abstraction as much as possible, not concrete implementation.

This principle has the following three points

  • 1. High-level modules should not depend on low-level modules, both should depend on abstractions,
  • 2. Abstraction should not depend on details, namely concrete implementation classes.
  • 3. Details should depend on abstraction.

The benefits are reduced coupling between classes, improved system stability, improved code readability and maintainability, and reduced risk of program modification.

For example: after we get the requirements in daily development, we are generally oriented to interface programming, design the top-level first, and design the structure of the code in detail. (Architecture based on abstraction is much more stable than architecture based on detail)

3. Single responsibility principle: There should be only one cause for a class to change.

It’s a little hard to conceptually understand, but basically, when we’re programming,

All kinds of functionality can be added to a class. You’ll have to change this class over and over again in the future when these features need to be changed, and it may cause other features to break down, which can be difficult to maintain, difficult to reuse, and coupling.

If we decouple these functions into different classes, later requirement changes and maintenance will not affect each other, which can reduce the complexity of the class and improve the readability. In general, one class, interface, and method can only do one thing

4. Interface isolation principle: a client should not rely on interfaces it does not need, and dependencies between classes should be established on the smallest interface.

This principle guides us to consider a few things when designing interfaces:

  • 1. A class’s dependency on a class should be based on the smallest interface.
  • 2, establish a single interface, do not establish a variety of functions of the general interface.
  • 3, try to refine the interface, the interface method as little as possible (not the less the better, must be moderate).

This principle conforms to the design idea of high cohesion and low coupling, which can make the class have good readability, extensibility and maintainability. We should take the time to design our interfaces, both with the business model in mind and with some anticipation of future changes.

5. Demeter’s Law (least know principle) : An object should know as little about other objects as possible to minimize the coupling between classes.

Because each class minimizes its dependence on the others, it is easy to make the functional modules of the system functionally independent, with no (or few) dependencies on each other. Demeter’s rule does not want direct connections between classes. If there is a real need to establish contact, also hope to communicate through his friends class.

The Demeter principle emphasizes only talking to friends, not strangers. Classes that appear in member variables, input parameters, and output parameters of a method are called member friend classes. Classes that appear inside a method body are not friend classes.

6. Richter’s substitution principle: if a software entity applies to a parent class, it must apply to its subclasses. All references to the parent class must transparently use the objects of the subclass, and the subclass objects can replace the superclass objects without changing the program logic.

That is, wherever a base class can appear, a subclass must appear. Richter’s substitution principle is the cornerstone of inheritance reuse. Only when the derived class can replace the base class and the function of software unit is not affected, the base class can be truly reused, and the derived class can also add new behaviors on the basis of accumulation. Richter’s substitution principle is a supplement to the “open-closed” principle. The key step in implementing the “open – close” principle is abstraction. The inheritance relationship between the base class and the subclass is the concrete implementation of abstraction, so the Richter substitution principle is the specification of the concrete steps to achieve abstraction.

When inheritance is satisfied, there must be non-private members of the parent class, and the subclass must get the non-private members of the parent class (assuming that all members of the parent class are private, then the subclass cannot inherit any members from the parent class, and there is no concept of inheritance). Since a subclass inherits these non-private members from its parent, the superclass object can also call these non-private members from the subclass object. So, subclass objects can replace superclass objects.

Under the Richter band principle, when requirements change, nothing else changes but inheritance. Open and closed is possible because of the Richter substitution principle. This allows subclasses to be extended without modification in their parent class.

The use of Richter substitution principle has the following advantages: 1, constraint inheritance overflow, an embodiment of the open and closed principle. 2, strengthen the robustness of the program, at the same time change can also do very good compatibility, improve the maintenance of the program, expand the ductility. Reduce risks introduced when requirements change

As a developer, it is especially important to have a learning atmosphere and a communication circle. This is my iOS communication circle: no matter you are white or big, welcome to enter!! Topics to be shared include reverse security, algorithms, architecture design, multi-threading, network advancements, also underlying, audio and video, Flutter and more……

According to the network to comb their own development experience summary of learning methods, free to share with you. You can download it yourself if you need to. + skirt: 196800191, or + WX (XiAZHiGardenia) Get interview materials resume templates communicate skills together (Resource Collection)

7. Principle of composite/aggregation reuse: Try to use object combination (HAS-A)/ aggregation (Contanis-A) instead of inheritance relationship to achieve the purpose of software reuse.

In other words, you use some existing objects in a new object, making them part of the new object, and the new object uses these objects to delegate to the purpose of reusing existing functions.

This principle can make the system more flexible and reduce the degree of coupling between classes, so that changes in one class have relatively little impact on other classes.

Conclusion: Learning software design principles must not form obsessive-compulsive disorder. In the case of complex business scenarios, we need to be flexible.

In the actual development process, it is not necessary that all code should follow design principles, we should consider labor, time, cost, quality, not perfection.

Following design principles in the right context is a balancing act that helps us design more elegant code structures