Common design principles in object-oriented design

       I started to look at design patterns today, and then I went to understand the principles of object-oriented design, and said a few widely accepted and common design principles. There are a lot of introductions in this regard on the Internet, here is a brief description of some of the things that I have learned. 

  • Design patterns are proposed for a class of problems, not for a particular problem. In other words, it means that some big-level programmers came up with a better solution after encountering a problem when writing code. On the basis of solving the problem, it also maintains the stability of the system and makes the code have better scalability, so there are design principles and design patterns. Of course, the above is purely personal understanding.
  • The official correct solution is: to solve the same type of problem, using design patterns can make the code structure clearer.
  • An article I saw before mentioned that an essential difference between programmers is design thinking. This is why the difference between programmers can be found in simple small programs during interviews.
  • Single Responsibility Principle: An object should contain only a single responsibility, and the responsibility is fully encapsulated in a class / As far as a class is concerned, there should be only one reason for it to change.

  • Open-Closed Principle: Make a class depend on a fixed abstraction, so modification is closed. Programming to the abstract but not to the concrete [abstract is relatively stable] Add new code in the face of demand without changing the code.
  • Liskov Substitution Principle: Where any base class (parent class) can appear, subclasses must appear. I don't understand this very clearly. . . .
  • Dependency inversion principle: programming depends on abstraction (parent class); programming depends on details (implementation, interface).
  • Interface isolation principle: If the interface is too large [fat interface], use multiple specialized interfaces instead of a single general interface.
  • The principle of least knowledge (law of Demeter): try to avoid calls to the outside world.
  • Less use of inheritance and more use of composition (synthetic reuse): You can declare instances instead of inheritance to achieve the purpose of reuse.
  • The main function of the above principles is to make the software system designed and implemented by yourself more stable, easy to maintain, and consistent.
  • [Extension] Coupling: The higher the dependence on the outside world, the more connections to the outside world, and the higher the coupling; conversely, the lower the coupling. In the same way, the coupling between different classes should be reduced as much as possible, and the reusability and extensibility should be increased.

     

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325647155&siteId=291194637