Six principles and design patterns confluence

Design patterns are divided into three categories:

Six principles of design patterns:

  • General principle - the principle of opening and closing
    • Open for extension, closed for modification. When the program needs to expand, not to modify the original code, but to expand the existing code to achieve the effect of a hot-swappable. So summarized in one sentence: In order to make the program better scalability, ease of maintenance and upgrades.
  • 1. Single Responsibility Principle
    • Do not type more than one cause of change, which means that each class should implement a single responsibility, otherwise it should split the class.
  • 2, Richter substitution principle (Liskov Substitution Principle)
    • Place any base class can appear, sub-class will be able to appear. Substitution principle Richter inherited cornerstone multiplexed only when the derived class can replace the base class, the software unit of functionality is not affected, the base class can really be reused, derived class can add new on the basis of the base class on the behavior of.
    • Richter substitution principle is - to add "on-off" principle. Achieve "on-off" principle is a key step in abstraction. The inheritance relationship with a base class is a subclass of the abstract concrete realization, so Richter substitution principle is the specification for concrete steps to achieve the abstract. Richter replaced in principle, sub-categories and try not to override the parent class method overloading. Because the parent class represents a well-defined structure, through this interface specifications to interact with the outside world, the subclass should not just destroy it.
  • 3, Dependency Inversion principle (Dependence Inversion Principle): abstract should not rely on the details, the details should depend on the abstract. - Popular talk is, an interface for programming, not to implement programming.
  • 4, the interface segregation principle (Interface Segregation Principle): The client should not rely on it does not interface; a dependency on another class of the class should be based on the smallest interface.
    • Interface as small as possible, but there's a limit. To refine the programming interface flexibility is an indisputable fact that can be improved, but if it is too small, it will cause excessive number of interfaces, complicating the design. So be sure to moderate.
    • Customized services to dependent interface, only expose the class to call the method requires it, and it does not require the method is hidden. Only focus on providing customized services for a module in order to establish the minimum dependencies.
    • Improve cohesion and reduce the external interaction. The interfaces with the least method to accomplish most things.
  • 5, the Law of Demeter (the least known principle) (Demeter Principle)
    • A class of their dependent classes know better. No matter how complex the dependent classes, the logic should be encapsulated within the method, it is supplied to the outside through the public methods. So that when a change is dependent class, with minimal impact to the class.
    • Another expression of the least known principle is: only direct communication with friends. As long as there is coupling relationship called friendship between classes. Coupling into dependency, association, aggregation, and the like combinations. We call appears as a member variable, method arguments, method return values ​​directly in the class friends. Local variables, temporary variables are not direct friends. We ask strangers class do not appear as a local variable in the class.
  • 6, the synthesis of multiplexing principles (Composite Reuse Principle): First of all possible ways to use synthetic polymeric / instead of inheritance.
Published 75 original articles · won praise 48 · Views 350,000 +

Guess you like

Origin blog.csdn.net/KingJin_CSDN_/article/details/89000102