Summary of common design patterns

preface

While reading Head First Design Patterns recently, I noticed that the summary of the main points after each chapter was terrifically short, so THIS blog post is a summary of common design pattern points.

Observer model

Define one-to-many dependencies between objects so that when an object changes state, all dependent objects are notified and updated automatically

• The observer pattern defines a one-to-many relationship between objects

• Topics (observables) update observers with a common pair interface

• The observed does not know the details of the observer, only that the observer implements the observer interface

• With multiple observers, you cannot rely on a specific order of notification

● Abstract Subject roles: Abstract Subject roles store all references to observer objects in an aggregate (such as an ArrayList object), and each Subject can have any number of observers. Abstract themes provide an interface to add and remove observer objects. Abstract theme roles are also called Abstract Observable roles.

● ConcreteSubject Roles: Store states in concrete observer objects; All registered observers are notified when the internal status of a specific topic changes. Concrete subject role is also called Concrete Observable role.

● Abstract Observer roles: Define an interface for all concrete observers to update themselves when notified of a topic. This interface is called the update interface.

● ConcreteObserver role: The state of the ConcreteObserver that stores the topic. The concrete observer role implements the update interface required by the abstract observer role to coordinate its own state with that of the topic. The specific observer role can maintain a reference to a specific subject object if desired.

Decorator pattern

To extend functionality by placing responsibilities on objects dynamically, decorators provide an alternative to inheritance

• The decorator pattern means a collection of decorator classes that wrap concrete components

• Decorator classes are implemented through interfaces or inheritance

• A component can be wrapped with an infinite number of decorators

• Decorators can lead to a lot of small objects in your design, and overuse can complicate your program

The roles in decoration mode are:

● Abstract Component Role: An abstract interface is given to specify objects that are ready to receive additional responsibilities.

● ConcreteComponent Role: Define a class that will receive additional responsibilities.

● Decorator role: Holds an instance of a Component object and defines an interface consistent with the abstract Component interface.

● ConcreteDecorator role: Responsible for “attaching” additional responsibilities to component objects.

The factory pattern

Simple factory: Defines an interface for creating objects, but it is up to subclasses to decide which class to instantiate.

Abstract factory: Provides an interface for creating families of related or dependent objects without explicitly specifying concrete classes

• All factories are used to encapsulate object creation

• Factory methods use inheritance: they delegate object creation to subclasses, which implement factory methods to create objects

• Abstract factories use object composition: object creation is implemented in methods exposed by the factory interface

• Abstract factories create families of related objects without relying on their concrete classes

• The dependency inversion principle relies on abstractions rather than concrete types

The following is a UML diagram of the simple factory pattern

Simple factories focus on products, such as CpuFactory, MainboardFactory in the figure above. When we need to add a new product (for example, memory does not need to modify the original code), but when we need to add a new CPU (for example, HUAWEI CPU) the simple factory needs to change the original code, so we introduce a second abstract factory.

Abstract factories focus on product families, such as IntelFactory and AmdFactory in the figure above. When we need to add a new product family (for example, HuaweiFactory does not need to modify the original code), but when we need to add a new product (for example, memory), the abstraction factory needs to change the original code.

Each of the above two factory models has its advantages and disadvantages.

The singleton pattern

Ensure that a class has only one instance and provides global access points

• The singleton pattern ensures that there is at most one implementation of a class in a program

• The singleton pattern provides visitors with qualified instances of global access points

• Implementing the singleton pattern in Java requires a private constructor, a static method, and a static variable

• You must assume that all programs are multithreaded and consider concurrency

• Using multiple classloaders can cause singleton pattern failures to produce multiple instances

Recommend a best practice for a singleton pattern

publicclassSingleTon{
   privateSingleTon(){}
   
   privatestaticclassInstanceHolder{
       privatefinalstaticSingleTonsingleTon=newSingleTon();
  }
   
   publicSingleTongetSingleTon() {returnInstanceHolder.singleTon; }}Copy the code

Adapter mode/facade mode

Adapter pattern: By converting the interface of one class into the desired interface of another, adapters enable incompatible classes to work together

Facade pattern: A group of interfaces that provide a unified interface for accessing subsystems. The facade defines a high-level interface that makes subsystems easier to use

• Use an adapter when you need to use an existing class whose interface does not meet your needs

• Adapters wrap an object to change its interface, decorators wrap an object to add new behaviors and responsibilities, and facade patterns “wrap” a bunch of objects to simplify their interfaces

• Use facade patterns when you need to simplify and agree on a large interface or a complex set of interfaces

• Facade patterns can be decoupled from a complex subsystem

• Using a facade pattern requires composing subsystems into the facade and then delegating the work to the subsystem

Adapter UML diagram

The roles involved in the pattern are:

● Target roles: This is the desired interface. Note: Since we are talking about the class adapter pattern, the target cannot be a class.

● Source (Adapee) role: Interface that needs to be adapted now.

● Adapter (Adaper) Role: The adapter class is the core of this pattern. The adapter converts the source interface into the target interface. Obviously, this role cannot be an interface, but must be a concrete class

The facade model is relatively simple

The picture above is a small demand I made during my summer internship in Ali. The core component uses the facade mode to expose the domain object of the core component to the front end, so that the front end does not have to pay attention to each specific core item and decouples from a complex subsystem.

The proxy pattern

A surrogate or placeholder to access the object

• The proxy pattern provides representation for another object in order to control customer access to the object

• Agents are similar to decorators in structure but different in purpose

• The decorator pattern adds behavior to objects, while the proxy controls access

Role in proxy mode:

● Abstract object roles: A common interface between the target object and the proxy object is declared so that the proxy object can be used wherever the target object can be used.

● Target object role: Defines the target object represented by the proxy object.

● Proxy object role: The proxy object contains internal reference to the target object, so that the target object can be manipulated at any time; The proxy object provides the same interface as the target object so that it can replace the target object at any time. Proxy objects typically perform an operation before or after a client call is passed to the target object, rather than simply passing the call to the target object.

conclusion

The primary reason for wanting to learn design patterns is how to write more flexible, robust, and compliant code. It is true that I have learned from design patterns that I feel the power of object orientation, but I know that I have to practice.

Reference Documents:

Head First Design Patterns