Design Patterns
Design patterns are general solutions to commonly occurring problems in software design.
Patterns are not algorithms; they are high-level solutions with
flexible implementation.
Analogy: Blueprints or templates that are reusable & customizable.
Creational Patterns
First category of patterns.
Creational patterns provide mechanisms to create objects based on a required criterion and in a
controlled way.
5 creational patterns: Abstract Factory, Builder, Factory Method,
Prototype, and Singleton.
Structural Patterns
Second category of patterns.
Structural patterns address how to assemble classes and objects to form larger structures and
provide new functionality.
7 structural patterns: Adapter, Bridge, Composite, Decorator, Facade,
Flyweight, and Proxy.
Behavioral Patterns
Third category of patterns.
Behavioral patterns identify and address communication and responsibilities between objects.
11 behavioral patterns:
Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer,
State, Strategy, Template Method, and Visitor.
Abstract Factory
In object-oriented programming, a factory is an object that creates
other objects.
An Abstract Factory has abstracted out a theme, and it produces
families of related or dependent objects without specifying their concrete classes.
Builder
Builder lets you construct complex objects step by step.
The Builder pattern separates the construction of an object from its
representation.
Builder allows the same construction process to create various representations.
Factory Method
Factory Method (also known as Virtual Constructor) is used to replace class constructors.
Factory Method defines an interface for creating an object, but based on data or events, it lets
subclasses decide which class to instantiate.
Prototype
Prototype (also known as Clone) allows you to clone existing objects without making your code
dependent on their classes.
New objects are created from an existing prototypical instance, thus
boosting performance and minimizing memory footprints.
Singleton
Singleton restricts a class to only
one single instance.
Singleton provides a global point of access to this instance.
Singleton is useful when exactly one object is needed to coordinate actions across the
system.
Adapter
Adapter (also known as Wrapper or Translator) allows classes with incompatible interfaces to
collaborate.
Without modifying the source code, the adapter wraps and converts the
interface of an existing class to match the interface of another class.
Bridge
The Bridge pattern decouples, or splits, an abstraction from its
implementation, so that the two can develop independently.
Bridge can use encapsulation, aggregation, or inheritance to separate responsibilities into
different classes.
Composite
Composite (also known as Object Tree) creates a composition of objects in a tree structure to
represent part-whole hierarchies. Each object may be a simple or
composite object.
Composite allows you to treat individual objects and compositions uniformly.
Decorator
The Decorator pattern (also known as Wrapper) extends (or decorates) an object’s behavior
dynamically, without making a new subclass.
Multiple decorators can add or override behaviors in an existing method of an object by
"wrapping" around the object.
Facade
The Facade pattern provides a simplified interface to a library, a
framework, or any other complex system.
By masking interaction with more complex components in the larger system, the facade improves
readability and usability for the client.
Flyweight
The Flyweight pattern (also known as Cache) reduces the cost of creating and manipulating a
large number of similar objects.
Flyweight minimizes memory usage by
sharing common parts of state between multiple objects instead of
keeping all of the data in each object.
Proxy
The Proxy pattern provides a placeholder for another object to control
access, reduce cost, and reduce complexity.
A proxy controls access to the original object, allowing actions to be performed
before or after the request
to the original object.
Chain of Responsibility
Chain of Responsibility (also known as Chain of Command) lets you pass requests along
a chain of handlers. Each handler decides to process or to pass the
request to the next handler in the chain.
The pattern is essentially a linear search for an object that can
handle a particular request.
Command
The Command pattern (also known as Action or Transaction)
encapsulates actions as objects
that contain all parameters.
This transformation lets you pass requests as method arguments, delay or queue a request’s
execution, and support undoable operations.
Interpreter
The Interpreter pattern defines a grammatical representation for a language and provides an
interpreter to process grammar.
Interpreter maps:
• a domain to a language,
• the language to a grammar,
• the grammar to a hierarchical object-oriented design.
Iterator
The Iterator pattern lets you sequentially traverse elements of a
collection or container without exposing its underlying representation (data structures like
lists, stacks, trees, etc.).
For traversal to occur, the iterator decouples algorithms from containers.
Mediator
The Mediator pattern (also known as Intermediary or Controller)
reduces chaotic dependencies between objects.
The pattern restricts direct interaction between objects and facilitates communication and
collaboration via a mediator object.
Memento
The Memento pattern (also known as Snapshot) provides the ability to save and restore an object
to its
previous state (undo via rollback).
The memento object (the unique snapshot of state) is an
opaque object (the object that no one can or should change).
Observer
The Observer pattern (also known as Event-Subscriber or Listener) offers a
subscription mechanism to notify objects when events or changes in
state occur.
The observer pattern promotes loose coupling between the subject and
the observers.
State
The State design pattern allows an object to alter its behavior when
its internal state changes. It appears as if the object changed its
class.
State is a cleaner way for an object to change its behavior at runtime without resorting to
conditional statements.
Strategy
The Strategy pattern (also known as Policy) lets you define a family of algorithms, place each
into separate classes (strategies), and make them interchangeable.
The pattern enables fast switching between algorithms, meaning algorithms can be selected
on-the-fly at runtime.
Template Method
The Template Method defines the skeleton of an algorithm as an abstract
class, but allows subclasses to provide concrete behavior.
The subclasses can redefine certain steps of an algorithm without changing the algorithm's
structure.
Visitor
The Visitor pattern is a way of separating algorithms from objects by
moving the hierarchy of methods into one object.
With the creation of a visitor class, you can add new operations and
functions to existing object structures without modifying the structures.
History of Design Patterns
Software design patterns were first described in the 1994 book,
Design Patterns: Elements of Reusable Object-Oriented Software.
The authors are Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They are known as
the
"Gang of Four" (GoF).
