mirror of
https://github.com/iandinwoodie/cpp-design-patterns-for-humans.git
synced 2025-12-16 20:17:08 +03:00
Standardized markdown formatting with prettier.
Used default prettier settings.
This commit is contained in:
Ian Dinwoodie
477
README.md
477
README.md
@@ -28,52 +28,52 @@ 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.
|
||||
> 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.
|
||||
> 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.
|
||||
- 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.
|
||||
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](#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.
|
||||
> 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.
|
||||
> 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](#-simple-factory)
|
||||
- [Factory Method](#-factory-method)
|
||||
- [Abstract Factory](#-abstract-factory)
|
||||
- [Builder](#-builder)
|
||||
- [Prototype](#-prototype)
|
||||
- [Singleton](#-singleton)
|
||||
|
||||
### 🏠 Simple Factory
|
||||
|
||||
@@ -82,23 +82,23 @@ solve this problem by somehow controlling this object creation.
|
||||
Real world example:
|
||||
|
||||
> Consider, you are building a house and you need doors. You can either put on
|
||||
your carpenter clothes, bring some wood, glue, nails and all the tools required
|
||||
to build the door and start building it in your house or you can simply call the
|
||||
factory and get the built door delivered to you so that you don't need to learn
|
||||
anything about the door making or to deal with the mess that comes with making
|
||||
it.
|
||||
> your carpenter clothes, bring some wood, glue, nails and all the tools required
|
||||
> to build the door and start building it in your house or you can simply call the
|
||||
> factory and get the built door delivered to you so that you don't need to learn
|
||||
> anything about the door making or to deal with the mess that comes with making
|
||||
> it.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Simple factory simply generates an instance for client without exposing any
|
||||
instantiation logic to the client.
|
||||
> instantiation logic to the client.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In object-oriented programming (OOP), a factory is an object for creating
|
||||
other objects – formally a factory is a function or method that returns objects
|
||||
of a varying prototype or class from some method call, which is assumed to be
|
||||
"new".
|
||||
> other objects – formally a factory is a function or method that returns objects
|
||||
> of a varying prototype or class from some method call, which is assumed to be
|
||||
> "new".
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -171,7 +171,7 @@ std::cout << "height = " << door2->getHeight() << std::endl;
|
||||
|
||||
#### When To Use
|
||||
|
||||
When creating an object is not just a few assignments and involves some logic,
|
||||
When creating an object is not just a few assignments and involves some logic,
|
||||
it makes sense to put it in a dedicated factory instead of repeating the same
|
||||
code everywhere.
|
||||
|
||||
@@ -181,9 +181,9 @@ code everywhere.
|
||||
|
||||
Real world example:
|
||||
|
||||
> Consider the case of a hiring manager. It is impossible for one person to
|
||||
interview for each of the positions. Based on the job opening, she has to decide
|
||||
and delegate the interview steps to different people.
|
||||
> Consider the case of a hiring manager. It is impossible for one person to
|
||||
> interview for each of the positions. Based on the job opening, she has to decide
|
||||
> and delegate the interview steps to different people.
|
||||
|
||||
In plain words:
|
||||
|
||||
@@ -192,11 +192,11 @@ In plain words:
|
||||
Wikipedia says:
|
||||
|
||||
> In class-based programming, the factory method pattern is a creational pattern
|
||||
that uses factory methods to deal with the problem of creating objects without
|
||||
having to specify the exact class of the object that will be created. This is
|
||||
done by creating objects by calling a factory method—either specified in an
|
||||
interface and implemented by child classes, or implemented in a base class and
|
||||
optionally overridden by derived classes—rather than by calling a constructor.
|
||||
> that uses factory methods to deal with the problem of creating objects without
|
||||
> having to specify the exact class of the object that will be created. This is
|
||||
> done by creating objects by calling a factory method—either specified in an
|
||||
> interface and implemented by child classes, or implemented in a base class and
|
||||
> optionally overridden by derived classes—rather than by calling a constructor.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -291,22 +291,22 @@ the client doesn't know what exact sub-class it might need.
|
||||
Real world example:
|
||||
|
||||
> Extending our door example from Simple Factory. Based on your needs you might
|
||||
get a wooden door from a wooden door shop, iron door from an iron shop or a PVC
|
||||
door from the relevant shop. Plus you might need a guy with different kind of
|
||||
specialities to fit the door, for example a carpenter for wooden door, welder
|
||||
for iron door etc. As you can see there is a dependency between the doors now,
|
||||
wooden door needs carpenter, iron door needs a welder etc.
|
||||
> get a wooden door from a wooden door shop, iron door from an iron shop or a PVC
|
||||
> door from the relevant shop. Plus you might need a guy with different kind of
|
||||
> specialities to fit the door, for example a carpenter for wooden door, welder
|
||||
> for iron door etc. As you can see there is a dependency between the doors now,
|
||||
> wooden door needs carpenter, iron door needs a welder etc.
|
||||
|
||||
In plain words:
|
||||
|
||||
> A factory of factories; a factory that groups the individual but
|
||||
related/dependent factories together without specifying their concrete classes.
|
||||
> related/dependent factories together without specifying their concrete classes.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> The abstract factory pattern provides a way to encapsulate a group of
|
||||
individual factories that have a common theme without specifying their concrete
|
||||
classes.
|
||||
> individual factories that have a common theme without specifying their concrete
|
||||
> classes.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -445,23 +445,23 @@ involved.
|
||||
Real world example:
|
||||
|
||||
> Imagine you are at Hardee's and you order a specific deal, lets say,
|
||||
"Big Hardee" and they hand it over to you without *any questions*; this is the
|
||||
example of simple factory. But there are cases when the creation logic might
|
||||
involve more steps. For example you want a customized Subway deal, you have
|
||||
several options in how your burger is made e.g what bread do you want? what
|
||||
types of sauces would you like? What cheese would you want? etc. In such cases
|
||||
builder pattern comes to the rescue.
|
||||
> "Big Hardee" and they hand it over to you without _any questions_; this is the
|
||||
> example of simple factory. But there are cases when the creation logic might
|
||||
> involve more steps. For example you want a customized Subway deal, you have
|
||||
> several options in how your burger is made e.g what bread do you want? what
|
||||
> types of sauces would you like? What cheese would you want? etc. In such cases
|
||||
> builder pattern comes to the rescue.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Allows you to create different flavors of an object while avoiding constructor
|
||||
pollution. Useful when there could be several flavors of an object. Or when
|
||||
there are a lot of steps involved in creation of an object.
|
||||
> pollution. Useful when there could be several flavors of an object. Or when
|
||||
> there are a lot of steps involved in creation of an object.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> The builder pattern is an object creation software design pattern with the
|
||||
intentions of finding a solution to the telescoping constructor anti-pattern.
|
||||
> intentions of finding a solution to the telescoping constructor anti-pattern.
|
||||
|
||||
Having said that let me add a bit about what telescoping constructor
|
||||
anti-pattern is. At one point or the other we have all seen a constructor like
|
||||
@@ -611,7 +611,7 @@ pattern is to be used when the creation is a multi step process.
|
||||
Real world example:
|
||||
|
||||
> Remember dolly? The sheep that was cloned! Lets not get into the details but
|
||||
the key point here is that it is all about cloning.
|
||||
> the key point here is that it is all about cloning.
|
||||
|
||||
In plain words:
|
||||
|
||||
@@ -620,8 +620,8 @@ In plain words:
|
||||
Wikipedia says:
|
||||
|
||||
> The prototype pattern is a creational design pattern in software development.
|
||||
It is used when the type of objects to create is determined by a prototypical
|
||||
instance, which is cloned to produce new objects.
|
||||
> It is used when the type of objects to create is determined by a prototypical
|
||||
> instance, which is cloned to produce new objects.
|
||||
|
||||
In short, it allows you to create a copy of an existing object and modify it to
|
||||
your needs, instead of going through the trouble of creating an object from
|
||||
@@ -665,6 +665,7 @@ class Sheep
|
||||
std::string category_;
|
||||
};
|
||||
```
|
||||
|
||||
Here is how we can clone this object
|
||||
|
||||
```cpp
|
||||
@@ -690,7 +691,7 @@ creation would be expensive as compared to cloning.
|
||||
Real world example:
|
||||
|
||||
> There can only be one president of a country at a time. The same president has
|
||||
to be brought to action, whenever duty calls. President here is singleton.
|
||||
> to be brought to action, whenever duty calls. President here is singleton.
|
||||
|
||||
In plain words:
|
||||
|
||||
@@ -699,8 +700,8 @@ In plain words:
|
||||
Wikipedia says:
|
||||
|
||||
> In software engineering, the singleton pattern is a software design pattern
|
||||
that restricts the instantiation of a class to one object. This is useful when
|
||||
exactly one object is needed to coordinate actions across the system.
|
||||
> that restricts the instantiation of a class to one object. This is useful when
|
||||
> exactly one object is needed to coordinate actions across the system.
|
||||
|
||||
Singleton pattern is actually considered an anti-pattern and overuse of it
|
||||
should be avoided. It is not necessarily bad and could have some valid use-cases
|
||||
@@ -754,22 +755,22 @@ TODO
|
||||
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?"
|
||||
> 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.
|
||||
> 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](#-adapter)
|
||||
- [Bridge](#-bridge)
|
||||
- [Composite](#-composite)
|
||||
- [Decorator](#-decorator)
|
||||
- [Facade](#-facade)
|
||||
- [Flyweight](#-flyweight)
|
||||
- [Proxy](#-proxy)
|
||||
|
||||
### 🔌 Adapter
|
||||
|
||||
@@ -778,32 +779,32 @@ entities.
|
||||
Real world example:
|
||||
|
||||
> Consider that you have some pictures in your memory card and you need to
|
||||
transfer them to your computer. In order to transfer them you need some kind of
|
||||
adapter that is compatible with your computer ports so that you can attach
|
||||
memory card to your computer. In this case card reader is an adapter.
|
||||
> transfer them to your computer. In order to transfer them you need some kind of
|
||||
> adapter that is compatible with your computer ports so that you can attach
|
||||
> memory card to your computer. In this case card reader is an adapter.
|
||||
|
||||
Another real world example:
|
||||
|
||||
> Another example would be the famous power adapter; a three legged plug can't
|
||||
be connected to a two pronged outlet, it needs to use a power adapter that makes
|
||||
it compatible with the two pronged outlet.
|
||||
> be connected to a two pronged outlet, it needs to use a power adapter that makes
|
||||
> it compatible with the two pronged outlet.
|
||||
|
||||
And another:
|
||||
|
||||
> Yet another example would be a translator translating words spoken by one
|
||||
person to another.
|
||||
> person to another.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Adapter pattern lets you wrap an otherwise incompatible object in an adapter
|
||||
to make it compatible with another class.
|
||||
> to make it compatible with another class.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In software engineering, the adapter pattern is a software design pattern that
|
||||
allows the interface of an existing class to be used as another interface. It is
|
||||
often used to make existing classes work with others without modifying their
|
||||
source code.
|
||||
> allows the interface of an existing class to be used as another interface. It is
|
||||
> often used to make existing classes work with others without modifying their
|
||||
> source code.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -848,6 +849,7 @@ class Hunter
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
Now let's say we have to add a wild dog in our game so that hunter can hunt
|
||||
that also (Note: I do not condone the hunting of any dogs). But we can't do that
|
||||
directly because dog has a different interface. To make it compatible for our
|
||||
@@ -902,24 +904,24 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Consider you have a website with different pages and you are supposed to allow
|
||||
the user to change the theme. What would you do? Create multiple copies of each
|
||||
of the pages for each of the themes or would you just create separate theme and
|
||||
load them based on the user's preferences? Bridge pattern allows you to do the
|
||||
second i.e.
|
||||
> the user to change the theme. What would you do? Create multiple copies of each
|
||||
> of the pages for each of the themes or would you just create separate theme and
|
||||
> load them based on the user's preferences? Bridge pattern allows you to do the
|
||||
> second i.e.
|
||||
|
||||
|
||||
|
||||
In plain words:
|
||||
|
||||
> Bridge pattern is about preferring composition over inheritance.
|
||||
Implementation details are pushed from a hierarchy to another object with a
|
||||
separate hierarchy.
|
||||
> Implementation details are pushed from a hierarchy to another object with a
|
||||
> separate hierarchy.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> The bridge pattern is a design pattern used in software engineering that is
|
||||
meant to "decouple an abstraction from its implementation so that the two can
|
||||
vary independently."
|
||||
> meant to "decouple an abstraction from its implementation so that the two can
|
||||
> vary independently."
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -1046,22 +1048,22 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Every organization is composed of employees. Each of the employees has the
|
||||
same features i.e. has a salary, has some responsibilities, may or may not
|
||||
report to someone, may or may not have some subordinates etc.
|
||||
> same features i.e. has a salary, has some responsibilities, may or may not
|
||||
> report to someone, may or may not have some subordinates etc.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Composite pattern lets clients treat the individual objects in a uniform
|
||||
manner.
|
||||
> manner.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In software engineering, the composite pattern is a partitioning design
|
||||
pattern. The composite pattern describes that a group of objects is to be
|
||||
treated in the same way as a single instance of an object. The intent of a
|
||||
composite is to "compose" objects into tree structures to represent part-whole
|
||||
hierarchies. Implementing the composite pattern lets clients treat individual
|
||||
objects and compositions uniformly.
|
||||
> pattern. The composite pattern describes that a group of objects is to be
|
||||
> treated in the same way as a single instance of an object. The intent of a
|
||||
> composite is to "compose" objects into tree structures to represent part-whole
|
||||
> hierarchies. Implementing the composite pattern lets clients treat individual
|
||||
> objects and compositions uniformly.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -1199,23 +1201,23 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Imagine you run a car service shop offering multiple services. Now how do you
|
||||
calculate the bill to be charged? You pick one service and dynamically keep
|
||||
adding to it the prices for the provided services till you get the final cost.
|
||||
Here each type of service is a decorator.
|
||||
> calculate the bill to be charged? You pick one service and dynamically keep
|
||||
> adding to it the prices for the provided services till you get the final cost.
|
||||
> Here each type of service is a decorator.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Decorator pattern lets you dynamically change the behavior of an object at
|
||||
run time by wrapping them in an object of a decorator class.
|
||||
> run time by wrapping them in an object of a decorator class.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In object-oriented programming, the decorator pattern is a design pattern that
|
||||
allows behavior to be added to an individual object, either statically or
|
||||
dynamically, without affecting the behavior of other objects from the same
|
||||
class. The decorator pattern is often useful for adhering to the Single
|
||||
Responsibility Principle, as it allows functionality to be divided between
|
||||
classes with unique areas of concern.
|
||||
> allows behavior to be added to an individual object, either statically or
|
||||
> dynamically, without affecting the behavior of other objects from the same
|
||||
> class. The decorator pattern is often useful for adhering to the Single
|
||||
> Responsibility Principle, as it allows functionality to be divided between
|
||||
> classes with unique areas of concern.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -1355,9 +1357,9 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> How do you turn on the computer? "Hit the power button" you say! That is what
|
||||
you believe because you are using a simple interface that computer provides on
|
||||
the outside, internally it has to do a lot of stuff to make it happen. This
|
||||
simple interface to the complex subsystem is a facade.
|
||||
> you believe because you are using a simple interface that computer provides on
|
||||
> the outside, internally it has to do a lot of stuff to make it happen. This
|
||||
> simple interface to the complex subsystem is a facade.
|
||||
|
||||
In plain words:
|
||||
|
||||
@@ -1366,7 +1368,7 @@ In plain words:
|
||||
Wikipedia says:
|
||||
|
||||
> A facade is an object that provides a simplified interface to a larger body of
|
||||
code, such as a class library.
|
||||
> code, such as a class library.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -1460,20 +1462,20 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Did you ever have fresh tea from some stall? They often make more than one
|
||||
cup that you demanded and save the rest for any other customer so to save the
|
||||
resources e.g. gas etc. Flyweight pattern is all about that i.e. sharing.
|
||||
> cup that you demanded and save the rest for any other customer so to save the
|
||||
> resources e.g. gas etc. Flyweight pattern is all about that i.e. sharing.
|
||||
|
||||
In plain words:
|
||||
|
||||
> It is used to minimize memory usage or computational expenses by sharing as
|
||||
much as possible with similar objects.
|
||||
> much as possible with similar objects.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In computer programming, flyweight is a software design pattern. A flyweight
|
||||
is an object that minimizes memory use by sharing as much data as possible with
|
||||
other similar objects; it is a way to use objects in large numbers when a simple
|
||||
repeated representation would use an unacceptable amount of memory.
|
||||
> is an object that minimizes memory use by sharing as much data as possible with
|
||||
> other similar objects; it is a way to use objects in large numbers when a simple
|
||||
> repeated representation would use an unacceptable amount of memory.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -1567,7 +1569,7 @@ shop.takeOrder("half sugar", 4);
|
||||
std::cout << shop.getPreferenceCount() << std::endl; // Output: 3
|
||||
|
||||
// Serve the customers.
|
||||
shop.serve();
|
||||
shop.serve();
|
||||
// Output: (Note: Since the map is unordered, the serving order may vary.)
|
||||
// Serving tea to table 4
|
||||
// Serving tea to table 5
|
||||
@@ -1586,25 +1588,25 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Have you ever used an access card to go through a door? There are multiple
|
||||
options to open that door i.e. it can be opened either using access card or by
|
||||
pressing a button that bypasses the security. The door's main functionality is
|
||||
to open but there is a proxy added on top of it to add some functionality. Let
|
||||
me better explain it using the code example below.
|
||||
> options to open that door i.e. it can be opened either using access card or by
|
||||
> pressing a button that bypasses the security. The door's main functionality is
|
||||
> to open but there is a proxy added on top of it to add some functionality. Let
|
||||
> me better explain it using the code example below.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Using the proxy pattern, a class represents the functionality of another
|
||||
class.
|
||||
> class.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> A proxy, in its most general form, is a class functioning as an interface to
|
||||
something else. A proxy is a wrapper or agent object that is being called by the
|
||||
client to access the real serving object behind the scenes. Use of the proxy can
|
||||
simply be forwarding to the real object, or can provide additional logic. In the
|
||||
proxy extra functionality can be provided, for example caching when operations
|
||||
on the real object are resource intensive, or checking preconditions before
|
||||
operations on the real object are invoked.
|
||||
> something else. A proxy is a wrapper or agent object that is being called by the
|
||||
> client to access the real serving object behind the scenes. Use of the proxy can
|
||||
> simply be forwarding to the real object, or can provide additional logic. In the
|
||||
> proxy extra functionality can be provided, for example caching when operations
|
||||
> on the real object are resource intensive, or checking preconditions before
|
||||
> operations on the real object are invoked.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -1689,28 +1691,28 @@ TODO
|
||||
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?"
|
||||
> 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.
|
||||
> 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](#-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
|
||||
|
||||
@@ -1719,28 +1721,28 @@ communication.
|
||||
Real world example:
|
||||
|
||||
> For example, you have three payment methods (`A`, `B` and `C`) setup in your
|
||||
account; each having a different amount in it. `A` has 100 USD, `B` has 300 USD
|
||||
and `C` having 1000 USD and the preference for payments is chosen as `A` then
|
||||
`B` then `C`. You try to purchase something that is worth 210 USD. Using Chain
|
||||
of Responsibility, first of all account `A` will be checked if it can make the
|
||||
purchase, if yes purchase will be made and the chain will be broken. If not,
|
||||
request will move forward to account `B` checking for amount if yes chain will
|
||||
be broken otherwise the request will keep forwarding till it finds the suitable
|
||||
handler. Here `A`, `B` and `C` are links of the chain and the whole phenomenon
|
||||
is Chain of Responsibility.
|
||||
> account; each having a different amount in it. `A` has 100 USD, `B` has 300 USD
|
||||
> and `C` having 1000 USD and the preference for payments is chosen as `A` then
|
||||
> `B` then `C`. You try to purchase something that is worth 210 USD. Using Chain
|
||||
> of Responsibility, first of all account `A` will be checked if it can make the
|
||||
> purchase, if yes purchase will be made and the chain will be broken. If not,
|
||||
> request will move forward to account `B` checking for amount if yes chain will
|
||||
> be broken otherwise the request will keep forwarding till it finds the suitable
|
||||
> handler. Here `A`, `B` and `C` are links of the chain and the whole phenomenon
|
||||
> is Chain of Responsibility.
|
||||
|
||||
In plain words:
|
||||
|
||||
> It helps building a chain of objects. Request enters from one end and keeps
|
||||
going from object to object till it finds the suitable handler.
|
||||
> going from object to object till it finds the suitable handler.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In object-oriented design, the chain-of-responsibility pattern is a design
|
||||
pattern consisting of a source of command objects and a series of processing
|
||||
objects. Each processing object contains logic that defines the types of command
|
||||
objects that it can handle; the rest are passed to the next processing object in
|
||||
the chain.
|
||||
> pattern consisting of a source of command objects and a series of processing
|
||||
> objects. Each processing object contains logic that defines the types of command
|
||||
> objects that it can handle; the rest are passed to the next processing object in
|
||||
> the chain.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -1852,27 +1854,27 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> A generic example would be you ordering food at a restaurant. You (i.e.
|
||||
`Client`) ask the waiter (i.e. `Invoker`) to bring some food (i.e. `Command`)
|
||||
and waiter simply forwards the request to Chef (i.e. `Receiver`) who has the
|
||||
knowledge of what and how to cook.
|
||||
> `Client`) ask the waiter (i.e. `Invoker`) to bring some food (i.e. `Command`)
|
||||
> and waiter simply forwards the request to Chef (i.e. `Receiver`) who has the
|
||||
> knowledge of what and how to cook.
|
||||
|
||||
Another example:
|
||||
|
||||
> Another example would be you (i.e. `Client`) switching on (i.e. `Command`) the
|
||||
television (i.e. `Receiver`) using a remote control (`Invoker`).
|
||||
> television (i.e. `Receiver`) using a remote control (`Invoker`).
|
||||
|
||||
In plain words:
|
||||
|
||||
> Allows you to encapsulate actions in objects. The key idea behind this pattern
|
||||
is to provide the means to decouple client from receiver.
|
||||
> is to provide the means to decouple client from receiver.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In object-oriented programming, the command pattern is a behavioral design
|
||||
pattern in which an object is used to encapsulate all information needed to
|
||||
perform an action or trigger an event at a later time. This information includes
|
||||
the method name, the object that owns the method and values for the method
|
||||
parameters.
|
||||
> pattern in which an object is used to encapsulate all information needed to
|
||||
> perform an action or trigger an event at a later time. This information includes
|
||||
> the method name, the object that owns the method and values for the method
|
||||
> parameters.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2012,24 +2014,24 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> An old radio set will be a good example of iterator, where user could start at
|
||||
some channel and then use next or previous buttons to go through the respective
|
||||
channels. Or take an example of MP3 player or a TV set where you could press the
|
||||
next and previous buttons to go through the consecutive channels or in other
|
||||
words they all provide an interface to iterate through the respective channels,
|
||||
songs or radio stations.
|
||||
> some channel and then use next or previous buttons to go through the respective
|
||||
> channels. Or take an example of MP3 player or a TV set where you could press the
|
||||
> next and previous buttons to go through the consecutive channels or in other
|
||||
> words they all provide an interface to iterate through the respective channels,
|
||||
> songs or radio stations.
|
||||
|
||||
In plain words:
|
||||
|
||||
> It presents a way to access the elements of an object without exposing the
|
||||
underlying presentation.
|
||||
> underlying presentation.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In object-oriented programming, the iterator pattern is a design pattern in
|
||||
which an iterator is used to traverse a container and access the container's
|
||||
elements. The iterator pattern decouples algorithms from containers; in some
|
||||
cases, algorithms are necessarily container-specific and thus cannot be
|
||||
decoupled.
|
||||
> which an iterator is used to traverse a container and access the container's
|
||||
> elements. The iterator pattern decouples algorithms from containers; in some
|
||||
> cases, algorithms are necessarily container-specific and thus cannot be
|
||||
> decoupled.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2046,22 +2048,22 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> A general example would be when you talk to someone on your mobile phone,
|
||||
there is a network provider sitting between you and them and your conversation
|
||||
goes through it instead of being directly sent. In this case network provider is
|
||||
mediator.
|
||||
> there is a network provider sitting between you and them and your conversation
|
||||
> goes through it instead of being directly sent. In this case network provider is
|
||||
> mediator.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Mediator pattern adds a third party object (called mediator) to control the
|
||||
interaction between two objects (called colleagues). It helps reduce the
|
||||
coupling between the classes communicating with each other. Because now they
|
||||
don't need to have the knowledge of each other's implementation.
|
||||
> interaction between two objects (called colleagues). It helps reduce the
|
||||
> coupling between the classes communicating with each other. Because now they
|
||||
> don't need to have the knowledge of each other's implementation.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In software engineering, the mediator pattern defines an object that
|
||||
encapsulates how a set of objects interact. This pattern is considered to be a
|
||||
behavioral pattern due to the way it can alter the program's running behavior.
|
||||
> encapsulates how a set of objects interact. This pattern is considered to be a
|
||||
> behavioral pattern due to the way it can alter the program's running behavior.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2078,19 +2080,19 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Take the example of calculator (i.e. originator), where whenever you perform
|
||||
some calculation the last calculation is saved in memory (i.e. memento) so that
|
||||
you can get back to it and maybe get it restored using some action buttons (i.e.
|
||||
caretaker).
|
||||
> some calculation the last calculation is saved in memory (i.e. memento) so that
|
||||
> you can get back to it and maybe get it restored using some action buttons (i.e.
|
||||
> caretaker).
|
||||
|
||||
In plain words:
|
||||
|
||||
> Memento pattern is about capturing and storing the current state of an object
|
||||
in a manner that it can be restored later on in a smooth manner.
|
||||
> in a manner that it can be restored later on in a smooth manner.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> The memento pattern is a software design pattern that provides the ability to
|
||||
restore an object to its previous state (undo via rollback).
|
||||
> restore an object to its previous state (undo via rollback).
|
||||
|
||||
Usually useful when you need to provide some sort of undo functionality.
|
||||
|
||||
@@ -2109,19 +2111,19 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> A good example would be the job seekers where they subscribe to some job
|
||||
posting site and they are notified whenever there is a matching job opportunity.
|
||||
> posting site and they are notified whenever there is a matching job opportunity.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Defines a dependency between objects so that whenever an object changes its
|
||||
state, all its dependents are notified.
|
||||
> state, all its dependents are notified.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> The observer pattern is a software design pattern in which an object, called
|
||||
the subject, maintains a list of its dependents, called observers, and notifies
|
||||
them automatically of any state changes, usually by calling one of their
|
||||
methods.
|
||||
> the subject, maintains a list of its dependents, called observers, and notifies
|
||||
> them automatically of any state changes, usually by calling one of their
|
||||
> methods.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2138,24 +2140,24 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Consider someone visiting Dubai. They just need a way (i.e. visa) to enter
|
||||
Dubai. After arrival, they can come and visit any place in Dubai on their own
|
||||
without having to ask for permission or to do some leg work in order to visit
|
||||
any place here; just let them know of a place and they can visit it. Visitor
|
||||
pattern lets you do just that, it helps you add places to visit so that they can
|
||||
visit as much as they can without having to do any legwork.
|
||||
> Dubai. After arrival, they can come and visit any place in Dubai on their own
|
||||
> without having to ask for permission or to do some leg work in order to visit
|
||||
> any place here; just let them know of a place and they can visit it. Visitor
|
||||
> pattern lets you do just that, it helps you add places to visit so that they can
|
||||
> visit as much as they can without having to do any legwork.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Visitor pattern lets you add further operations to objects without having to
|
||||
modify them.
|
||||
> modify them.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In object-oriented programming and software engineering, the visitor design
|
||||
pattern is a way of separating an algorithm from an object structure on which it
|
||||
operates. A practical result of this separation is the ability to add new
|
||||
operations to existing object structures without modifying those structures. It
|
||||
is one way to follow the open/closed principle.
|
||||
> pattern is a way of separating an algorithm from an object structure on which it
|
||||
> operates. A practical result of this separation is the ability to add new
|
||||
> operations to existing object structures without modifying those structures. It
|
||||
> is one way to follow the open/closed principle.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2172,22 +2174,22 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Consider the example of sorting, we implemented bubble sort but the data
|
||||
started to grow and bubble sort started getting very slow. In order to tackle
|
||||
this we implemented Quick sort. But now although the quick sort algorithm was
|
||||
doing better for large datasets, it was very slow for smaller datasets. In order
|
||||
to handle this we implemented a strategy where for small datasets, bubble sort
|
||||
will be used and for larger, quick sort.
|
||||
> started to grow and bubble sort started getting very slow. In order to tackle
|
||||
> this we implemented Quick sort. But now although the quick sort algorithm was
|
||||
> doing better for large datasets, it was very slow for smaller datasets. In order
|
||||
> to handle this we implemented a strategy where for small datasets, bubble sort
|
||||
> will be used and for larger, quick sort.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Strategy pattern allows you to switch the algorithm or strategy based upon the
|
||||
situation.
|
||||
> situation.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In computer programming, the strategy pattern (also known as the policy
|
||||
pattern) is a behavioural software design pattern that enables an algorithm's
|
||||
behavior to be selected at runtime.
|
||||
> pattern) is a behavioural software design pattern that enables an algorithm's
|
||||
> behavior to be selected at runtime.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2204,8 +2206,8 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Imagine you are using some drawing application, you choose the paint brush to
|
||||
draw. Now the brush changes its behavior based on the selected color i.e. if you
|
||||
have chosen red color it will draw in red, if blue then it will be in blue etc.
|
||||
> draw. Now the brush changes its behavior based on the selected color i.e. if you
|
||||
> have chosen red color it will draw in red, if blue then it will be in blue etc.
|
||||
|
||||
In plain words:
|
||||
|
||||
@@ -2214,12 +2216,12 @@ In plain words:
|
||||
Wikipedia says:
|
||||
|
||||
> The state pattern is a behavioral software design pattern that implements a
|
||||
state machine in an object-oriented way. With the state pattern, a state machine
|
||||
is implemented by implementing each individual state as a derived class of the
|
||||
state pattern interface, and implementing state transitions by invoking methods
|
||||
defined by the pattern's superclass. The state pattern can be interpreted as a
|
||||
strategy pattern which is able to switch the current strategy through
|
||||
invocations of methods defined in the pattern's interface.
|
||||
> state machine in an object-oriented way. With the state pattern, a state machine
|
||||
> is implemented by implementing each individual state as a derived class of the
|
||||
> state pattern interface, and implementing state transitions by invoking methods
|
||||
> defined by the pattern's superclass. The state pattern can be interpreted as a
|
||||
> strategy pattern which is able to switch the current strategy through
|
||||
> invocations of methods defined in the pattern's interface.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2236,27 +2238,28 @@ TODO
|
||||
Real world example:
|
||||
|
||||
> Suppose we are getting some house built. The steps for building might look
|
||||
like:
|
||||
> like:
|
||||
>
|
||||
> - Prepare the base of house
|
||||
> - Build the walls
|
||||
> - Add roof
|
||||
> - Add other floors
|
||||
>
|
||||
> The order of these steps could never be changed i.e. you can't build the roof
|
||||
before building the walls etc but each of the steps could be modified for
|
||||
example walls can be made of wood or polyester or stone.
|
||||
> before building the walls etc but each of the steps could be modified for
|
||||
> example walls can be made of wood or polyester or stone.
|
||||
|
||||
In plain words:
|
||||
|
||||
> Template method defines the skeleton of how a certain algorithm could be
|
||||
performed, but defers the implementation of those steps to the children classes.
|
||||
> performed, but defers the implementation of those steps to the children classes.
|
||||
|
||||
Wikipedia says:
|
||||
|
||||
> In software engineering, the template method pattern is a behavioral design
|
||||
pattern that defines the program skeleton of an algorithm in an operation,
|
||||
deferring some steps to subclasses. It lets one redefine certain steps of an
|
||||
algorithm without changing the algorithm's structure.
|
||||
> pattern that defines the program skeleton of an algorithm in an operation,
|
||||
> deferring some steps to subclasses. It lets one redefine certain steps of an
|
||||
> algorithm without changing the algorithm's structure.
|
||||
|
||||
#### Programmatic Example
|
||||
|
||||
@@ -2283,9 +2286,9 @@ about the architectural patterns, stay tuned for it.
|
||||
All content of this file, unless otherwise noted, is licensed as follows:
|
||||
|
||||
- All provided source code examples are covered by the
|
||||
[MIT License](https://github.com/idinwoodie/cpp-design-patterns-for-humans/blob/master/LICENSE).
|
||||
[MIT License](https://github.com/idinwoodie/cpp-design-patterns-for-humans/blob/master/LICENSE).
|
||||
- The C++ badge that appears in the banner image was created by
|
||||
[Jeremy Kratz](https://jeremykratz.com/) and is licensed by
|
||||
[The Standard C++ Foundation](https://isocpp.org/home/terms-of-use).
|
||||
[Jeremy Kratz](https://jeremykratz.com/) and is licensed by
|
||||
[The Standard C++ Foundation](https://isocpp.org/home/terms-of-use).
|
||||
- Other content, including images, is released under the
|
||||
[Creative Common Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/).
|
||||
[Creative Common Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/).
|
||||
|
||||
Reference in New Issue
Block a user