mirror of
https://github.com/iandinwoodie/cpp-design-patterns-for-humans.git
synced 2025-12-17 20:44:40 +03:00
Added text for creational design patterns.
This commit is contained in:
190
README.md
190
README.md
@@ -77,26 +77,216 @@ solve this problem by somehow controlling this object creation.
|
|||||||
|
|
||||||
### 🏠 Simple Factory
|
### 🏠 Simple Factory
|
||||||
|
|
||||||
|
#### Overview
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
In plain words:
|
||||||
|
|
||||||
|
> Simple factory simply generates an instance for client without exposing any
|
||||||
|
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".
|
||||||
|
|
||||||
|
#### Programmatic Example
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
||||||
|
#### When To Use
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
### 🏭 Factory Method
|
### 🏭 Factory Method
|
||||||
|
|
||||||
|
#### Overview
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
In plain words:
|
||||||
|
|
||||||
|
> It provides a way to delegate the instantiation logic to child classes.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
#### Programmatic Example
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
||||||
|
#### When To Use
|
||||||
|
|
||||||
|
Useful when there is some generic processing in a class but the required
|
||||||
|
sub-class is dynamically decided at runtime. Or putting it in other words, when
|
||||||
|
the client doesn't know what exact sub-class it might need.
|
||||||
|
|
||||||
### 🔨 Abstract Factory
|
### 🔨 Abstract Factory
|
||||||
|
|
||||||
|
#### Overview
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
In plain words:
|
||||||
|
|
||||||
|
> A factory of factories; a factory that groups the individual but
|
||||||
|
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.
|
||||||
|
|
||||||
|
#### Programmatic Example
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
||||||
|
#### When To Use
|
||||||
|
|
||||||
|
When there are interrelated dependencies with not-that-simple creation logic
|
||||||
|
involved.
|
||||||
|
|
||||||
### 👷 Builder
|
### 👷 Builder
|
||||||
|
|
||||||
|
#### Overview
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
below:
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
||||||
|
As you can see; the number of constructor parameters can quickly get out of hand
|
||||||
|
and it might become difficult to understand the arrangement of parameters. Plus
|
||||||
|
this parameter list could keep on growing if you would want to add more options
|
||||||
|
in future. This is called telescoping constructor anti-pattern.
|
||||||
|
|
||||||
|
#### Programmatic Example
|
||||||
|
|
||||||
|
TODO
|
||||||
|
|
||||||
|
#### When To Use
|
||||||
|
|
||||||
|
When there could be several flavors of an object and to avoid the constructor
|
||||||
|
telescoping. The key difference from the factory pattern is that; factory
|
||||||
|
pattern is to be used when the creation is a one step process while builder
|
||||||
|
pattern is to be used when the creation is a multi step process.
|
||||||
|
|
||||||
### 🐑 Prototype
|
### 🐑 Prototype
|
||||||
|
|
||||||
|
#### Overview
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
In plain words:
|
||||||
|
|
||||||
|
> Create object based on an existing object through cloning.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
scratch and setting it up.
|
||||||
|
|
||||||
|
#### Programmatic Example
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
||||||
|
#### When To Use
|
||||||
|
|
||||||
|
When an object is required that is similar to existing object or when the
|
||||||
|
creation would be expensive as compared to cloning.
|
||||||
|
|
||||||
### 💍 Singleton
|
### 💍 Singleton
|
||||||
|
|
||||||
|
#### Overview
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
In plain words:
|
||||||
|
|
||||||
|
> Ensures that only one object of a particular class is ever created.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
but should be used with caution because it introduces a global state in your
|
||||||
|
application and change to it in one place could affect in the other areas and it
|
||||||
|
could become pretty difficult to debug. The other bad thing about them is it
|
||||||
|
makes your code tightly coupled plus mocking the singleton could be difficult.
|
||||||
|
|
||||||
|
#### Programmatic Example
|
||||||
|
|
||||||
|
TODO
|
||||||
|
|
||||||
|
#### When To Use
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
|
||||||
## Structural Design Patterns
|
## Structural Design Patterns
|
||||||
|
|||||||
Reference in New Issue
Block a user