Home  >  Article  >  Backend Development  >  Detailed explanations of common design principles with examples

Detailed explanations of common design principles with examples

零下一度
零下一度Original
2017-06-23 14:28:331618browse

Design principles form the foundation upon which design patterns are built. By following proven design principles, your code will become more flexible, more resilient to change, and more maintainable.

Common Design Principles

  • Simplicity Principle (KISS)
    The goal of the KISS principle is to keep the code simple but not too simple, so as to avoid introducing any unnecessary but the complexity.

  • Don't repeat yourself (DRY)
    BRY principle but the purpose is to avoid duplicating any part of the system by extracting the common but parts and putting them in a separate place. Of course, it's not just code that's being avoided, but also business logic.

  • Tell, Don't Ask (Tell, Don't Ask)
    This principle requires that you should tell objects what actions you want them to perform, rather than asking questions about the object's state and then you Decide for yourself what actions you want to perform. This helps match responsibilities and avoid tight coupling between classes.

  • You don’t need it (YAGNI)
    This principle refers to only including the functionality that your application must have, without trying to add any other functionality that you think you might need. .

  • Separation of Concerns (SoC)
    SoC is the process of decomposing software into distinct functions, each of which encapsulates unique behavior and data that can be used by other classes. . Typically, a concern represents a feature or behavior of a class. Dividing a program into independent responsibilities significantly improves code reuse, maintainability, and testability.

S.O.L.I.D Design Principles

  • Single Responsibility Principle (SRP)
    SRP is highly consistent with the separation of concerns principle. It requires that each object should have and only one responsibility focus, that is, there is only one reason for class changes.

  • Open Closed Principle (OCP)
    This principle requires that the class should be open for extension and closed for modification, so that it should be possible to change the internals of the class without changing it. Add new functionality to the class without affecting the behavior, and prevent the class from being destroyed, causing unnecessary errors or bugs.

  • Liskov Substitution Principle (LSP)
    Any parent class should be replaceable by a subclass while maintaining its behavior. The change principle is consistent with the OCP principle to ensure that the inherited class does not affect the behavior of the parent class.

  • Interface Separation Principle (ISP)
    The ISP principle focuses on dividing interface methods into several groups according to responsibilities, and assigning different interfaces to these groups. Avoid the client from implementing a huge and unused interface.

  • Dependency Inversion Principle (DIP)
    The purpose of the DIP principle is to isolate the classes you write from the specific implementation, so that these classes depend on abstractions or interfaces. It promotes interface-oriented programming, which ensures that the code is not tightly coupled to a certain implementation, thereby increasing the flexibility of the evil system.

  • Dependency Injection (DI) and Inversion of Control (SoC) principles
    DI, SoC and DIP are closely connected. DI provides lower-level or subordinate classes through constructors, methods or properties. Coupled with the use of DI principles, these subordinate classes can be inverted into interfaces or abstract classes, thus forming a low-coupling system with high testability and easy modification.

ASP.NET Design Patterns:

The above is the detailed content of Detailed explanations of common design principles with examples. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn