mirror of
https://github.com/iandinwoodie/cpp-design-patterns-for-humans.git
synced 2025-12-17 20:44:40 +03:00
220 lines
4.9 KiB
Markdown
220 lines
4.9 KiB
Markdown
|
|
|
|
---
|
|
|
|
<p align="center">
|
|
🎉 Ultra-simplified explanation to design patterns! 🎉
|
|
</p>
|
|
<p align="center">
|
|
A topic that can easily make anyone's mind wobble. Here I try to make them stick
|
|
in to your mind (and maybe mine) by explaining them in the <i>simplest</i> way
|
|
possible.
|
|
</p>
|
|
<p align="center">
|
|
This work, "C++ Design Patterns for Humans", is a derivative of
|
|
<a href="https://github.com/kamranahmedse/design-patterns-for-humans">
|
|
"Design Patterns for Humans"</a> by <a href="https://github.com/kamranahmedse">
|
|
"kamranahmedse"</a>, used under
|
|
<a href=https://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>.
|
|
</p>
|
|
|
|
---
|
|
|
|
## Introduction
|
|
|
|
Design patterns are solutions to recurring problems; **guidelines for how to
|
|
tackle certain problems**. They are not classes, packages, or libraries that
|
|
you can plug into your application and wait for the magic to happen. These are,
|
|
rather, guidelines on how to tackle certain problems in certain situations.
|
|
|
|
> Design patterns are solutions to recurring problems; guidelines for how to
|
|
tackle certain problems.
|
|
|
|
Wikipedia describes design patterns as:
|
|
|
|
> [...] a general reusable solution to a commonly occurring problem within a
|
|
given context in software design. It is not a finished design that can be
|
|
transformed directly into source or machine code. It is a description or
|
|
template for how to solve a problem that can be used in many different
|
|
situations.
|
|
|
|
### ⚠️ Be Careful
|
|
|
|
- Design patterns are not a silver bullet to all your problems.
|
|
- Do not try to force them; bad things are supposed to happen, if done so.
|
|
- Keep in mind that design patterns are solutions **to** problems, not solutions
|
|
**finding** problems; so don't overthink.
|
|
- If used in a correct place in a correct manner, they can prove to be a savior;
|
|
or else they can result in a horrible mess of a code.
|
|
|
|
## Types of Design Patterns
|
|
|
|
* [Creational](#creational-design-patterns)
|
|
* [Structural](#structural-design-patterns)
|
|
* [Behavioral](#behavioral-design-patterns)
|
|
|
|
## Creational Design Patterns
|
|
|
|
In plain words:
|
|
|
|
> Creational patterns are focused towards how to instantiate an object or group
|
|
of related objects.
|
|
|
|
Wikipedia says:
|
|
|
|
> In software engineering, creational design patterns are design patterns that
|
|
deal with object creation mechanisms, trying to create objects in a manner
|
|
suitable to the situation. The basic form of object creation could result in
|
|
design problems or added complexity to the design. Creational design patterns
|
|
solve this problem by somehow controlling this object creation.
|
|
|
|
* [Simple Factory](#-simple-factory)
|
|
* [Factory Method](#-factory-method)
|
|
* [Abstract Factory](#-abstract-factory)
|
|
* [Builder](#-builder)
|
|
* [Prototype](#-prototype)
|
|
* [Singleton](#-singleton)
|
|
|
|
### 🏠 Simple Factory
|
|
|
|
TODO
|
|
|
|
### 🏭 Factory Method
|
|
|
|
TODO
|
|
|
|
### 🔨 Abstract Factory
|
|
|
|
TODO
|
|
|
|
### 👷 Builder
|
|
|
|
TODO
|
|
|
|
### 🐑 Prototype
|
|
|
|
TODO
|
|
|
|
### 💍 Singleton
|
|
|
|
TODO
|
|
|
|
## Structural Design Patterns
|
|
|
|
In plain words:
|
|
|
|
> Structural patterns are mostly concerned with object composition or in other
|
|
words how the entities can use each other. Or yet another explanation would be,
|
|
they help in answering "How to build a software component?"
|
|
|
|
Wikipedia says:
|
|
|
|
> In software engineering, structural design patterns are design patterns that
|
|
ease the design by identifying a simple way to realize relationships between
|
|
entities.
|
|
|
|
* [Adapter](#-adapter)
|
|
* [Bridge](#-bridge)
|
|
* [Composite](#-composite)
|
|
* [Decorator](#-decorator)
|
|
* [Facade](#-facade)
|
|
* [Flyweight](#-flyweight)
|
|
* [Proxy](#-proxy)
|
|
|
|
### 🔌 Adapter
|
|
|
|
TODO
|
|
|
|
### 🚡 Bridge
|
|
|
|
TODO
|
|
|
|
### 🌿 Composite
|
|
|
|
TODO
|
|
|
|
### ☕ Decorator
|
|
|
|
TODO
|
|
|
|
### 📦 Facade
|
|
|
|
TODO
|
|
|
|
### 🍃 Flyweight
|
|
|
|
TODO
|
|
|
|
### 🎱 Proxy
|
|
|
|
TODO
|
|
|
|
## Behavioral Design Patterns
|
|
|
|
In plain words:
|
|
|
|
> It is concerned with assignment of responsibilities between the objects. What
|
|
makes them different from structural patterns is they don't just specify the
|
|
structure but also outline the patterns for message passing/communication
|
|
between them. Or in other words, they assist in answering "How to run a behavior
|
|
in software component?"
|
|
|
|
Wikipedia says:
|
|
|
|
> In software engineering, behavioral design patterns are design patterns that
|
|
identify common communication patterns between objects and realize these
|
|
patterns. By doing so, these patterns increase flexibility in carrying out this
|
|
communication.
|
|
|
|
* [Chain of Responsibility](#-chain-of-responsibility)
|
|
* [Command](#-command)
|
|
* [Iterator](#-iterator)
|
|
* [Mediator](#-mediator)
|
|
* [Memento](#-memento)
|
|
* [Observer](#-observer)
|
|
* [Visitor](#-visitor)
|
|
* [Strategy](#-strategy)
|
|
* [State](#-state)
|
|
* [Template Method](#-template-method)
|
|
|
|
### 🔗 Chain of Responsibility
|
|
|
|
TODO
|
|
|
|
### 👮 Command
|
|
|
|
TODO
|
|
|
|
### ➿ Iterator
|
|
|
|
TODO
|
|
|
|
### 👽 Mediator
|
|
|
|
TODO
|
|
|
|
### 💾 Memento
|
|
|
|
TODO
|
|
|
|
### 😎 Observer
|
|
|
|
TODO
|
|
|
|
### 🏃 Visitor
|
|
|
|
TODO
|
|
|
|
### 💡 Strategy
|
|
|
|
TODO
|
|
|
|
### 💢 State
|
|
|
|
TODO
|
|
|
|
### 📒 Template Method
|
|
|
|
TODO
|
|
|