GoF Design Patterns
This repository contains examples of all the design patterns listed in the
"Design patterns - Elements of Reusable Object-oriented Software" book
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
popularly known as Gang of Four (GoF).
Table of contents
- What is a design pattern
- Why you should learn design patterns
- How to approach
- Creational design patterns (5)
- Structural design patterns (7)
- Behavioral design patterns (11)
- Chain of Responsibility
- Command
- Interpreter
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Template method
- Visitor
What is a design pattern?
From Wiki:-
- A general reusable solution to a commonly occurring problem within a given context in software design.
- Not a finished design that can be transformed directly into source or machine code.
- Rather, it is a description or template for how to solve a problem that can be used in many different situations.
- Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.
Why you should learn design patterns?
- Easy to communicate a proble among fellow developers
- It provides a common vocabulary to explain about problem
- It is an abstract topic
- Revisit materails about patterns will alway give you an new perspective everytime.
How to approach?
For each pattern you will see below points covered:
- Overview of the pattern
- Concepts involved
- Design considerations
- Demo / Live example from an API / Steps to create
- Drawbacks (Pitfalls)
- Contrast to another patterns
- Summary
Creational design patterns (5)
Sr. no | Pattern name | GoF book description |
---|---|---|
1 | Singleton | Ensure a class only has one instance, and provide a global point of access to it |
2 | Builder | Saperate the construction of complex object from its representation so that the same construction process can create different representations |
3 | Prototype | Specify the kinds of objects to create using a protypical instance, and create new objects by copying this prototype |
4 | Factory Method | Define an interface for creating an object, but let sub-classess decide which class to instantiate. Factory method lets a class defer instantiation to subclasses |
5 | Abstract Factory | Provide an interface for creating families of related or dependent objects without specifying their concrete classes. |
Structural design patterns (7)
Sr. no | Pattern name | GoF book description |
---|---|---|
1 | Adapter | Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. |
2 | Bridge | Decouple an abstraction from its implementation so that the two can vary independently |
3 | Composite | Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. |
4 | Decorator | Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. |
5 | Facade | Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. |
6 | Flyweight | Use sharing to support large numbers of fine-grained objects efficiently. |
7 | Proxy | Provide a surrogate or placeholder for another object to control access to it. |
Behavioral design patterns (11)
Sr. no | Pattern name | GoF book description |
---|---|---|
1 | Chain of Responsibility | Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. |
2 | Command | Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. |
3 | Interpreter | Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sentences in the language. |
4 | Iterator | Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. |
5 | Mediator | Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. |
6 | [Memento] | Without violating encapsulation, capture and externali ze an object's internal state so that the object can be restored to this st ate later. |
7 | [Observer] | Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. |
8 | [State] | Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. |
9 | [Strategy] | Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. |
10 | [Template method] | Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. |
11 | [Visitor] | Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. |