The article is from Sausure’s Brief book
I thought I knew a lot about design patterns, but when the interviewer asked me, I was so nervous that I only remembered singleton patterns… Oops, So there’s this article
1. Strategy
Define a policy interface, different implementation classes provide different specific policy algorithms, and they can be replaced with each other.
The IStrategy interface defines strategy methods. Strategy1 and Strategy2 provide different strategies by implementing IStrategy, while User combines IStrategy. User objects can obtain different strategies by setting different concrete implementation classes
PNG Policy mode
2. Simple Factory mode
Define a factory for creating objects that generate different objects according to different conditions
Note that the simple factory pattern is different from the policy pattern, in that the factory pattern returns the corresponding object based on a given condition, whereas the policy pattern passes different policy objects to the consumer to implement different policies. (Ok, I almost lost it.) The detailed difference analysis can be found here
Simple Factory model.png
3. Factory Mode
Provide a factory class for each product, creating different product instances from different factory instances
The difference with the simple factory pattern is that it provides a factory class for each product. Different factory classes implement the same factory interface and return different products. Detailed analysis can be found here
Factory model.png
4. Abstract Factory Pattern
Should be born out of the concept of product family
In contrast to the factory pattern, the abstract factory pattern deals with product families
Abstract factory schema.PNG
5. Decorator pattern
Add extra functionality to an object dynamically
The IComponent interface is implemented for ComponentImpl and Decorator classes. A Decorator is a concrete implementation of ComponentImpl that assembles ComponentImpl and then does some processing (decoration) in its implementation method, operation(), before calling ComponentImpl
Decorator pattern.PNG
6. Proxy Mode
Encapsulates the proxied object and restricts access to it
Be careful to distinguish the decorator pattern from the proxy pattern. In the Proxy mode, ComponentImpl and Proxy class have realized IComponent interface, although the Proxy object also maintains a ComponentImpl object, but in general, it is initialized by the Proxy class. Unlike decorator mode, which is entered through set and restricts access to proxy objects in the interface method operation(), decorator mode is where decorators add additional behavior to decorators
Proxy mode.PNG
7. Template method Pattern
Define the algorithmic skeleton of an operation and defer some steps to subclasses
The AbsTemplate abstract class defines a series of methods in which the only operation() method that can be called by the outside world is final (i.e., not overridden). First (), second(), and third() methods are called in this method. Subclasses override different methods by inheriting abstract classes to add their own behavior
Template method pattern.png
8. Facade
Provides a unified interface for the system to the outside world
Fracade provides a unified interface for ComponentA, ComponentB and ComponentC, namely ClientA and ClientB
PNG appearance mode
9. Adapter Mode
Translate the interface of a class into another interface that the customer wants
For example, after the project introduces a third party class library, it should be encapsulated and converted into its own interface before use to prevent future changes in the class library. AdapterA encapsulates the LibraryClass and calls the methods of the LibraryClass object in the operation() method provided by AdapterA. If the library is changed in the future, just change the AdapterA class or create a new Adapter implementation class
Adapter mode.PNG
10. Bridge mode (Bridge)
Separate the abstract parts from the implementation parts so that they can be changed independently
By abstracting the upper and lower layers that are supposed to be coupled, the upper and lower layers are connected in a combinatorial manner, and then the upper and lower abstractions can be subclassed in many different directions. AbsShape encapsulates the IDrawProgram interface so that subclasses of the AbsShape can switch from DPA to DPB or anything else by simply setting it in.
Bridge mode.PNG
Note: The relationship between adapter, bridge and appearance modes
11. Builder mode
Separate the construction of a complex object from its representation.
As the internal class of Product, Builder unifies the whole process of Product construction, and can produce different effects due to the different order of set values in the process of build
Builder model.png
12. Observer Model
Defines a one-to-many dependency that allows multiple observer objects to listen on a topic object at the same time and notify all observers when its state changes.
First register the Observer with an Observable, so that all observables will be notified when the status of an Observable changes. By the way, it is better to use WeakReference as the generic type of mList in an Observable to prevent memory leakage
Observer mode.PNG
13. Singleton
Ensure that a class has only one instance and provide a global point of control to access it.
The SingleHolder class is statically private. The SingleHolder class holds a static constant sHolder. If the Client obtains the Singleton object using getSingleInstance, it returns sHolder of the SingleHolder class directly
Singleton mode.PNG
14. Command mode
Encapsulate a request into an object that allows the client to be parameterized with different requests
Action encapsulates specific behavior, Command encapsulates Action and provides an empty execute() method. Subclasses of this method can encapsulate commands by overriding this method to call mAction behavior within the method. Finally, the Client encapsulates a series of Command objects and can call the execute() method of the Command objects one by one through notify() to communicate the Command to the Action
PNG command mode
The last
The first time to share the article, it is hard to avoid a little excited, there is a small mistake, please help point out, thank you first ha. At the same time, if there are other commonly used design patterns I haven’t covered, please let me know, and I will make up for them!!
Thanks, by the way ProcessOn Solution!!!!! It feels better than StarUML
An analysis of the 12 most common design patterns for open source projects