Design Patterns Cheatsheet
As everyone knows, design patterns are an extremely important discipline for programmers. However, because design patterns cover such a broad scope and involve many abstract concepts, they can be quite difficult to master. The best way to learn design patterns is to combine them with practical experience. Every time you work on a requirement — especially complex ones, or when you detect signs of smelly code — you can flip through the design patterns to see which ones might apply. Therefore, I’ve summarized this article using the most concise language to describe the main design patterns, possibly the key parts of their definitions, typical application scenarios, or just an English term. The goal is to help recall the purpose and application scenarios of each design pattern.
Basic Design Principles
Before discussing design patterns, we must first go over the six fundamental design principles. Simply put, design patterns are a series of best practices distilled from these principles.
Single Responsibility Principle
Open-Closed Principle
Solve problems through extension rather than modifying existing implementations. (When writing code, you can assume changes won’t occur; when changes do arise, abstraction is needed to isolate future similar changes.) As long as modifications don’t break existing unit tests, the Open-Closed Principle is not violated.
Liskov Substitution Principle
Subclasses should be able to substitute for their parent classes.
Dependency Inversion Principle
High-level modules should not depend on low-level modules; both should depend on abstractions rather than implementations.
Interface Segregation Principle
Interfaces should be as small as possible.
Law of Demeter
Decouple classes from each other.
Design Patterns
Factory Method Pattern
Define an interface for creating an object.
Abstract Factory Pattern
Create a family of related or interdependent objects.
Singleton Pattern
A class has only one instance.
Builder Pattern
Build each module of an instance separately.
Prototype Pattern
Copy objects.
Adapter Pattern
Handle interface incompatibility.
Decorator Pattern
Dynamically add additional responsibilities to an object, more flexible than creating subclasses.
Proxy Pattern
Provide a proxy for some objects to restrict access to other objects.
Facade Pattern (facade)
The facade contains some or all methods of several subsystems, combining the subsystems and providing them externally.
Bridge Pattern
Separate the abstraction from the implementation. An abstract class depends on an interface, and both parts can be extended independently.
Composite Pattern
Treat a group of similar objects as a single object.
Flyweight Pattern
Shared objects — database connection pools, thread pools, etc. are all applications of the flyweight pattern.
Strategy Pattern
Dynamically switch between multiple different “strategies” to change an object’s behavior.
Template Method Pattern
The parent class defines the skeleton of the algorithm, with some details implemented by subclasses.
Observer Pattern
For one-to-many dependencies, when an object’s state changes, all objects that depend on it are notified.
Iterator Pattern
Provide objects with an iterator.
Chain of Responsibility Pattern
Multiple objects have the opportunity to handle a request, connected in a chain. The request is passed along the chain until one of the objects handles it.
Command Pattern
Pass client requests into an object, achieving decoupling between the “behavior requester” and the “behavior implementer.”
Memento Pattern
A memento object is an object used to store a snapshot of another object’s internal state.
State Pattern
State machine.
Visitor Pattern
Separate data structures from data operations.
Mediator Pattern
Encapsulate a series of object interactions using a mediator object. The mediator makes objects interact without explicit references to each other.
Interpreter Pattern
Given a language, define a representation of its grammar and define an interpreter that uses this representation to interpret sentences in the language. Typical scenarios include SQL parsing, etc.
