Design patterns are typical solutions to commonly occurring problems in software design.
They are like pre-made blueprints that you can customize to solve a recurring design problem in your code.
The most basic and low-level patterns are often called idioms.
They usually apply only to a single programming language.
The most universal and high-level patterns are architectural patterns.
Developers can implement these patterns in virtually any language.
Unlike other patterns, they can be used to design the architecture of an entire application.
- Creational patterns provide object creation mechanisms that increase flexibility and reuse of existing code.
- Structural patterns explain how to assemble objects and classes into larger structures, while keeping these structures flexible and efficient.
- Behavioral patterns are concerned with algorithms and the assignment of responsibilities between objects.
Lets us construct complex objects step by step.
The pattern allows us to produce different types and representations of an object using the same construction code.
Lets us ensure that a class has only one instance, while providing a global access point to this instance.
Lets us split a large class or a set of closely related classes into 2 separate hierarchies — abstraction and implementation —
which can be developed independently of each other.
Lets us compose objects into tree structures and then work with these structures as if they were individual objects.
Lets us attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.
Lets us fit more objects into the available amount of RAM by sharing common parts of state between multiple objects instead of keeping all of the data in each object.
Lets us provide a substitute or placeholder for another object. A proxy controls access to the original object, allowing us to perform something either before or after the request gets through to the original object.
Lets us pass requests along a chain of handlers.
Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
Turns a request into a stand-alone object that contains all information about the request.
This transformation lets us pass requests as a method arguments, delay or queue a request’s execution, and support undoable operations.
Lets us traverse elements of a collection without exposing its underlying representation (list, stack, tree).
Lets us reduce chaotic dependencies between objects.
The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object.
Lets us save and restore the previous state of an object without revealing the details of its implementation.
Lets us define a subscription mechanism to notify multiple objects about any events that happen to the object they’re observing.
Lets an object alter its behavior when its internal state changes. It appears as if the object changed its class.
Lets us define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.
Defines the skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure.
