Introduction to Design Patterns
Design patterns (Design pattern) represent the best practices, typically adopted by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers face during software development. These solutions are the result of considerable trial and error by numerous software developers over a long period.
Design patterns are a set of reusable, well-known, categorized, and cataloged code design experiences. Using design patterns is intended to reuse code, make code easier to understand for others, and ensure code reliability. Undoubtedly, design patterns are a win-win for oneself, others, and the system. Design patterns make code development truly engineering, serving as the cornerstone of software engineering, much like bricks in a building. Properly applying design patterns in a project can perfectly solve many problems. Each pattern has a corresponding principle in reality, describes a problem that repeatedly occurs around us, and provides the core solution to that problem, which is why design patterns are widely used.
What is GOF (Gang of Four)?
In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides co-authored a book titled Design Patterns - Elements of Reusable Object-Oriented Software (Chinese translation: Design Patterns - Elements of Reusable Object-Oriented Software), which first introduced the concept of design patterns in software development.
These four authors are collectively known as GOF (Gang of Four). The design patterns they proposed are mainly based on the following object-oriented design principles:
- Program to an interface, not an implementation.
- Favor object composition over inheritance.
Uses of Design Patterns
Design patterns have two main uses in software development.
Common Platform for Developers
Design patterns provide a standard terminology system, specific to particular scenarios. For example, the Singleton design pattern means using a single object, so all developers familiar with the Singleton design pattern can use a single object and communicate this through the pattern.
Best Practices
Design patterns have been developed over a long period and provide the best solutions to general problems faced during software development. Learning these patterns helps inexperienced developers learn software design in a simple and quick way.
Types of Design Patterns
According to the reference book Design Patterns - Elements of Reusable Object-Oriented Software, there are a total of 23 design patterns. These patterns can be divided into three categories: Creational Patterns, Structural Patterns, and Behavioral Patterns. Additionally, we will discuss another category of design patterns: J2EE Design Patterns.
| No. | Pattern & Description | Includes |
|---|---|---|
| 1 | Creational Patterns<br>These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using the new operator. This makes the program more flexible in determining which objects need to be created for a given instance. | Factory Pattern<br>Abstract Factory Pattern<br>Singleton Pattern<br>Builder Pattern<br>Prototype Pattern |
| 2 | Structural Patterns<br>These design patterns concern class and object composition. The concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. | Adapter Pattern<br>Bridge Pattern<br>Filter Pattern<br>Composite Pattern<br>Decorator Pattern<br>Facade Pattern<br>Flyweight Pattern<br>Proxy Pattern |
| 3 | Behavioral Patterns<br>These design patterns are specifically concerned with communication between objects. | Chain of Responsibility Pattern<br>Command Pattern<br>Interpreter Pattern<br>Iterator Pattern<br>Mediator Pattern<br>Memento Pattern<br>Observer Pattern<br>State Pattern<br>Null Object Pattern<br>Strategy Pattern<br>Template Pattern<br>Visitor Pattern |
| 4 | J2EE Patterns<br>These design patterns are specifically concerned with the presentation layer. These patterns are identified by the Sun Java Center. | MVC Pattern<br>Business Delegate Pattern<br>Composite Entity Pattern<br>Data Access Object Pattern<br>Front Controller Pattern<br>Intercepting Filter Pattern<br>Service Locator Pattern<br>Transfer Object Pattern |
Below is an image to describe the relationship between design patterns:
Six Principles of Design Patterns
The Open-Closed Principle means: Open for extension, closed for modification. When the program needs to be expanded, you should not modify the existing code to achieve a plug-and-play effect. In short, it is to make the program extensible and easy to maintain and upgrade. To achieve this effect, we need to use interfaces and abstract classes, which we will mention in specific designs.
The Liskov Substitution Principle is one of the basic principles of object-oriented design. The Liskov Substitution Principle states that any base class that can appear, a subclass must be able to appear. LSP is the cornerstone of inheritance reuse. Only when the derived class can replace the base class without affecting the functionality of the software unit can the base class be truly reused, and the derived class can also add new behavior on the basis of the base class. The Liskov Substitution Principle is a supplement to the Open-Closed Principle. The key step to achieving the Open-Closed Principle is abstraction, and the inheritance relationship between the base class and the subclass is the concrete implementation of abstraction, so the Liskov Substitution Principle is a specification of the concrete steps to achieve abstraction.
This principle is the basis of the Open-Closed Principle, with the specific content: program to an interface, rely on abstraction rather than concrete.
This principle means: using multiple isolated interfaces is better than using a single interface. It also has another meaning: to reduce the coupling between classes. It can be seen that design patterns are software design ideas that facilitate upgrade and maintenance from the perspective of large-scale software architecture, emphasizing reduced dependency and coupling.
The Least Knowledge Principle states that a entity should interact as little as possible with other entities, making the system's functional modules relatively independent.
The Composite Reuse Principle states that one should prefer composition/aggregation over inheritance.