Design patterns are typical solutions to common problems in software design. They are like pre-made blueprints that can be tailored to fit specific needs, and they can be used to address recurring design issues in your code.
Unlike methods or libraries, design patterns are not something you can directly plug into your program. A pattern is not a specific piece of code, but rather a general concept for solving a particular problem. You can implement a solution based on the pattern that fits the actual requirements of your program.
An algorithm is more like a recipe: it provides clear steps to achieve a goal. A pattern, on the other hand, is more like a blueprint: you can see the final result and the functionality of the pattern, but you need to determine the implementation steps yourself.
Deal with object creation mechanisms, aiming to create objects in a suitable way for the situation.
-
Singleton: Ensures a class has only one instance and provides a global point of access to it.
-
Factory Method: Defines an interface for creating an object but lets subclasses alter the type of objects created.
-
Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
-
Builder: Separates the construction of a complex object from its representation, allowing the same construction process to create various representations.
-
Prototype: Specifies the kinds of objects to create using a prototypical instance and creates new objects by copying this prototype.
Concerned with class and object composition, focusing on how classes and objects are structured to form larger structures.
-
Adapter: Converts the interface of a class into another interface clients expect, enabling classes to work together that couldn’t otherwise.
-
Bridge: Separates an object’s abstraction from its implementation, allowing the two to vary independently.
-
Composite: Composes objects into tree structures to represent part-whole hierarchies, allowing clients to treat individual objects and compositions uniformly.
-
Decorator: Dynamically adds behavior to an object without affecting the behavior of other objects from the same class.
-
Facade: Provides a simplified interface to a complex subsystem.
-
Flyweight: Reduces the cost of creating and manipulating many similar objects by sharing as much data as possible.
-
Proxy: Provides a surrogate or placeholder for another object to control access to it.
Focus on communication between objects, defining how objects interact and distribute responsibility.
-
Chain of Responsibility: Passes a request along a chain of handlers, where each handler either processes the request or passes it to the next handler.
-
Command: Encapsulates a request as an object, allowing parameterization of clients with queues, requests, and operations.
-
Iterator: Provides a way to access elements of a collection sequentially without exposing its underlying representation.
-
Mediator: Defines an object that encapsulates how a set of objects interact, promoting loose coupling.
-
Memento: Captures and externalizes an object’s internal state without violating encapsulation, allowing the object to be restored later.
-
Observer: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
-
State: Allows an object to alter its behavior when its internal state changes, appearing to change its class.
-
Strategy: Defines a family of algorithms, encapsulates each one, and makes them interchangeable, allowing the algorithm to vary independently from clients.
-
Template Method: Defines the skeleton of an algorithm in a method, deferring some steps to subclasses.
-
Interpreter: Defines a grammatical representation for a language and provides an interpreter to deal with this grammar.
-
Visitor: Represents an operation to be performed on elements of an object structure, allowing new operations to be defined without changing the classes of the elements.
Design patterns in this repository are based on:
