This is the 15th day of my participation in Gwen Challenge

Introduction to Design Patterns

• Design Patterns:
  • A set of used, most known, cataloged, code design summaries
  • Design patterns are used to make code reusable, easier to understand, and reliable
• Rational use of design patterns in projects can perfectly solve many problems, and each pattern has its corresponding principle.
• Each pattern describes a recurring problem around us and the core solution to that problem

Classification of design patterns

• In general, design patterns fall into three broad categories:
  • Create mode (5 types):
    • Factory method pattern
    • Abstract Factory pattern
    • The singleton pattern
    • Builder model
    • The prototype pattern
  • Structural mode (7 kinds):
    • Adapter mode
    • Decorator mode
    • The proxy pattern
    • The appearance model
    • The bridge model
    • Portfolio model
    • The flyweight pattern
  • Behavioral patterns (11):
    • The strategy pattern
    • Template method pattern
    • Observer model
    • Iterative subpattern
    • Chain of Responsibility model
    • Command mode
    • Memo mode
    • The state pattern
    • Visitor pattern
    • The mediator pattern
    • Interpreter mode
• The remaining two types of modes:
  • Parallel hairstyle pattern
  • Thread pool mode

  

There are six principles of design patterns

Single Responsibility Principle (Single Responsibility Principle) – The Principle of design pattern here, mainly discusses the design Principle of Java object-oriented programming design, Single Responsibility Principle because of its universality, I think it is not included in the six principles

• Single responsibility principle: a class is responsible for one responsibility
• There cannot be more than one cause for a class change
• The single responsibility principle is consistent with the idea of “high cohesion, low coupling”
• The single responsibility principle is not only unique to object-oriented programming, but also applies to modular programming

Open Close Principle

• Open closed principle: Open for extensions, closed for modifications
• When the program is extended, it cannot modify the original code to achieve a hot-plug effect
• To make programs scalable and easy to maintain and upgrade, you need interfaces and abstract classes

Liskov Substitution Principle

• Richter’s substitution rule: Wherever a base class can appear, a subclass must appear
• LSP is the cornerstone of inheritance reuse. The base class can be reused only when the derived class can replace the base class and the function of the software unit is not affected. The derived class can also add new behaviors on the base class
• The Richter’s principle of substitution is a specification of specific steps to achieve abstraction:
  • Richter’s substitution principle is a complement to the open – close principle
  • The key step in implementing the open close principle is abstraction
  • The inheritance relationship between a base class and a subclass is a concrete implementation of abstraction

Dependence Inversion Principle

• Dependency inversion principle: Programming for interfaces that rely on abstractions rather than concrete ones
• The dependence reversal principle is the basis of the open closed principle

Interface Segregation Principle

• Interface isolation principle: Use multiple isolated interfaces, rather than a single interface, to reduce coupling between classes
• From the principle of interface isolation, we can see that design pattern is the design idea of a software
• Starting with large software architectures, for ease of upgrade and maintenance: less dependency, less coupling

The Demeter Principle

• Demeter’s Law: The least known principle is that an entity should interact with as few other entities as possible so that functional modules are independent of each other

Composite Reuse Principle

• Rule of composite reuse: use composition or aggregation rather than inheritance whenever possible