Detailed examples of common design principles

The design principle forms the basis for the design pattern to be built. By following proven design principles, your code becomes more flexible, adapts to change, and is more maintainable.

Common design principles

• The principle of simplicity (KISS)
  The goal of the kiss principle is to keep the code concise but not too rudimentary to avoid introducing any unnecessary but complex.

• Don't repeat yourself (DRY)
  Bry principle But the goal is to avoid duplicating any part of the system by placing the common but partial pull out in a separate place. Of course, avoiding duplication is more than just code, it also includes business logic.

• Tell without asking (Tell,don ' t ask)
  This principle requires that you tell the object what action you want them to perform, rather than asking questions about the state of the object and then you decide what action you want to perform. This helps to match responsibilities and avoids tight coupling between classes.

• You don't need it (YAGNI)
  This principle refers to the need to include only the functionality that the application must have, rather than trying to add any other functionality that you think might be required.

• Separation point of Interest (SoC)
  The SOC process breaks down software into a number of different functions, each of which encapsulates unique behaviors and data that can be used by other classes. Typically, a concern represents a function or behavior of a class. The practice of dividing programs into separate responsibilities significantly improves the reuse of code in Chengdu, maintainability, and testability.

S.O.L.I.D Design Principles

• Single responsibility principle (SRP)
  The SRP remains highly consistent with the principle of separation of concerns. It requires that each object should have and have only one responsibility focus, that is, there is only one cause of the class change.

• Open closure principle (OCP)
  This principle requires that the class should be open to the extension, and should be closed for modification, so that it should be able to add new functionality to the class without changing the internal behavior of the class, and avoid the class being corrupted, causing unnecessary errors or bugs.

• Richter replacement principle (LSP)
  Any parent class should be able to override the class and keep its behavior intact. The principle of change is consistent with the OCP principle, ensuring that inheriting classes do not affect the behavior of the parent class.

• Interface separation principle (ISP)
  The ISP principle focuses on dividing the interface method into groups by responsibility and assigning different interfaces to those groupings. Avoid the client implementation of a large and a heap of unused interfaces.

• Dependency inversion principle (DIP)
  The purpose of the dip principle is to isolate the classes that you have written from the specific implementation so that these classes rely on abstractions or interfaces. It advocates interface-oriented programming, which ensures that code is not tightly coupled to an implementation, thereby increasing the flexibility of a bad system.

• Dependency Injection (DI) and control inversion (SoC) principles
  The DI, SOC, and dip are closely connected. DI provides a lower class or subordinate class through a constructor, method, or property. With the DI principle, these subordinate classes can be reversed to interfaces or abstract classes, thus forming a low-coupling system with high testability and easy modification.

Asp. NET design pattern: