Η Λεξούλα (https://lexoula.com) ήρθε στη ζωή μας να μας προσφέρει ένα μικρό διάλειμμα στη βαρετή καθημερινότητα της πανδημίας. Είναι γνωστή ως το ελληνικό Wordle (Greek Wordle). Οι κανόνες απλοί: ο χρήστης έχει έξι προσπάθειες για να μαντέψει μια λέξη με πέντε γράμματα, σε κάθε προσπάθεια πολύχρωμα τετραγωνάκια δείχνουν εάν τα γράμματα υπάρχουν στη λέξη και εάν βρίσκονται στη σωστή θέση ή όχι. Ο μινιμαλιστικός σχεδιασμός και η ευκολία στη χρήση είναι αυτό που έκανε τους χρήστες να το αγαπήσουν. Είναι δωρεάν, δεν απαιτείται εγγραφή λογαριασμού, και το παιχνίδι διαρκεί για 2–3 λεπτά και μόνο μία φορά την ημέρα.

Η Λεξούλα έχει ξεχωρίσει ως το απόλυτο ελληνικό Wordle. Οι εγκέφαλοι πίσω από το https://lexoula.com Έρμος Κυριακίδης και Ανδρέας Πογιάς έχουν αφιερώσει πολύ χρόνο για να εντοπίσουν και να επιλέξουν όλες τις πιθανές λέξεις 5 γραμμάτων που θα μπορούσαν να χρησιμοποιηθούν. Αυτό είναι σημαντικό καθώς το παιχνίδι δεν επιτρέπει στον παίκτη να εισαγάγει μια μη έγκυρη ελληνική λέξη. Χρησιμοποιώντας τεχνικές όπως Data Scraping και Data Crawling, βρήκαν όλες τις πιθανές ελληνικές λέξεις 5 γραμμάτων από κείμενα στο διαδίκτυο και σύγχρονη ελληνική λογοτεχνία. Επίσης, χρησιμοποίησαν μεθοδολογίες εξόρυξης δεδομένων, όπως Frequent Pattern Mining and Sequence Prediction Mining για να ταξινομήσουν τις λέξεις που θεωρούνται κατάλληλες για το παιχνίδι ή αλλιώς οι ¨επιλεγμένες¨ λέξεις. Μόνο οι ¨επιλεγμένες¨ λέξεις είναι αυτές που χρησιμοποιούνται ως λέξη της ημέρας.

Η ταξινόμηση αυτή έχει να κάνει με δύο παραμέτρους,

1. Ποιά λέξη χρησιμοποιείτε πιο συχνά στην λογοτεχνία και στη καθημερινότητα (Frequent Pattern Mining)
2. Ποιά κλίση της συγκεκριμένης λέξης είναι πιο συχνή (Sequence Prediction Mining).

Η ταξινόμηση ¨επιλεγμένων¨ λέξεων είναι πολύ σημαντική για την ικανοποίηση και ψυχαγωγία των χρηστών. Ο χρήστης δεν πρέπει προσπαθεί να μαντέψει μια λέξη που δεν χρησιμοποιεί καθημερινά ή να ξοδεύει τρείς από της έξι προσπάθειες του για να βρει την επιθυμητή κλίση της.

The Decorator pattern is a structural pattern that lets you attach additional functionalities to an object dynamically. In other words, the client has the freedom to create an object and then extend it by adding a variety of “features” to it. A good analogy to simplify this pattern is: “Wrapping a gift, putting it in a box, and wrapping the box”.

The Decorator pattern is classified among structural design patterns which are all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality. [by Design Patterns explained simply]

A backpack in the perfect example of a Decorator pattern:

• Nowadays, the backpacks can have a variety of features. The features can range from something as simple as a laptop slot, side pockets, or even a power-bank for USB charging.

• The main target of the Decorator pattern is to allow the client to add whatever features are required, dynamically, safely and in the easiest possible way. It should be as straight forward and tidy as fitting back the backpack in the picture.
• The snippet of code below is purposely written as it converges so nicely with the quote we mentioned above: “Wrapping a gift, putting it in a box, and wrapping the box”. We assemble a backpack to which we add a USB charger to which we add a laptop slot to which we add …

int main // the client 
{ 
  IBackpack *bp = new LaptopSlot(new UsbCharge(...))));
  return 1;
}

Step 1 — Keywords

Defining keywords is the secret recipe in this series of quick-guides. This method helped me truly understand the design patterns, hardcode them in my mind and comprehend the differences among other design patterns.

• Flexibility: We want to give to the client the power and flexibility to dynamically add any feature to a component/object, that could be considered valuable.
• Extend functionality: The title may be a little bit misleading, this pattern is not only about “decorating” a certain object, but it is mainly about extending its functionality.

Step 2 — Diagrams by example

Let’s start explaining the diagram from bottom to top. The target is to “assemble” a backpack and add several functionalities to it.

• Concrete Decorators: We have three examples of these classes which are responsible to extend an extra functionality each: (1) LaptopSlot, (2) USBCharge, (3) WaterBottle. They hold the implementation of the functionality and they can “assemble” a backpack accordingly. Notice that they have a constructor that receives a decorator as a parameter.

• Decorator: This class derives the above classes and inherits from the component which is IBackpack. The decorator also has an instance of IBackpack. After IBackpackis instantiated, it is being used inside the assemble()method.
• Concrete Component: This class is the most important piece of the puzzle as it is the key to linking everything together. It is the component (backpack) which is in the plainest form it could get. For example, a plain backpack consists only of the “shoulder straps and main compartment”. The plain backpack performs as a start of a chain. It is passed to the decorator constructor and itself is passed to the constructor of a concrete decorator (to add specific functionalities i.e. a laptop slot) which can be passed to another constructor of a concrete decorator and another and so on.
• Component: It is an abstract view of the object we want to decorate. We can have different concrete components inheriting from it. In this example we could be separating the “PlainBackpack” as “OfficeBackpack”, “CampingBackpack”, “HikingBackpack” but we choose to keep it simple.

Step 23— Code by example

I would suggest to copy the code class by class from my git repository “Andreas Poyias” or the snippets below (in the order provided) and paste it in any of the available online C++ editors like c++shell, jdoodle , onlineGDBand run it to observe the output. Then read the comments or description below. Take time reading it thoroughly (that means one minute, not less and not more).

IBackpack:
The following code snippet is a simple inheritance, IBackpackis inherited by PlainBackpackclass. All derived classes must implement assemble(), since it is a pure virtual function = 0;. A plain backpack only has shoulder straps and the main compartment.

#include <iostream>
using namespace std;

class IBackpack 
{
public:
  virtual void assemble() = 0;
  virtual ~IBackpack() {}
};

class PlainBackpack: public IBackpack 
{
public:
  virtual void assemble(){cout<<"\n ShoulderStraps and mainCompartment";}
};

BackpackDecorator:
The above snippet is responsible for the construction of a plain backpack. Now, let’s decorate it using the BackpackDecorator. The decorator inherits from theIBackpack which means it must implement theassemble() method. It also contains an IBackpackobject which is used to delegate the implementation of the assemble()method depending on the type of m_decorator.

class BackpackDecorator: public IBackpack
{
public:
  BackpackDecorator(IBackpack* decorator):m_Decorator(decorator) {}
  
  virtual void assemble() 
  {
    m_Decorator->assemble();
  }
private:
  IBackpack* m_Decorator;
};

Concrete decorators:
The snippet below shows three different decorators that are derived from theBackpackDecorator class which itself inherits fromIBackpack. In this example, they are all identical apart from the implementation ofassemble(). The first adds a laptopSlot, the second adds a UBCharge and the third adds a waterBottle.

class WithLaptopSlot : public BackpackDecorator
{
public:
  WithLaptopSlot(IBackpack* dcrator):BackpackDecorator(dcrator){}
  virtual void assemble() 
  {
    BackpackDecorator::assemble();
    cout << " + LaptopSlot";
  }
};
 
class WithUSBCharge : public BackpackDecorator
{
public:
    WithUSBCharge(IBackpack* dcrator):BackpackDecorator(dcrator){}
    virtual void assemble() 
    {
        BackpackDecorator::assemble();
        cout << " + USBCharge";
    }
};
 
class WithWaterBottle : public BackpackDecorator
{
public:
    WithWaterBottle(IBackpack* dcrator):BackpackDecorator(dcrator){}
    virtual void assemble() 
    {
        BackpackDecorator::assemble();
        cout << " + WaterBottle";
    }
};

Main (Client):
The main method operates as the client(the same as the previous guides). We are finally able to put all the pieces of the puzzle together. But before doing so, let’s remember what was mentioned in the first paragraph of the blog “Wrapping a gift, putting it in a box, and wrapping the box”. To understand this we must read the construction of the backpack (in the snippet below) in reverse order:

1. Create a PlainBackpack.
2. Pass it to the BackpackDecorator.
3. Which passes it along to be decorated with a laptop slot.
4. In turn, it is passed to be decorated with a USB charge.
5. Finally, the “box” is “wrapped” with a water bottle.

It is also important to observe the print order as assemble()is being called. The order is related to how the constructors were initialized. It again starts from the plain backpack and is decorated all the way with to reach waterbottle.

int main()
{
  IBackpack* pBackpack = 
   new WithWaterBottle(        //5
    new WithUSBCharge(         //4
     new WithLaptopSlot(       //3
      new BackpackDecorator(   //2
       new PlainBackpack()))));//1

  pBackpack->assemble();
  delete pBackpack;

  return 0;
}

// Output
// ShoulderStraps and mainCompartment + LaptopSlot + USBCharge
// + WaterBottle

The simplicity offered to the client is one of the biggest benefits.

• The client has the power to dynamically assemble a backpack with any features available.
• It is simple, easy and safe.
• The client does not need to mingle with the code.
• Adding an extra “derived” decorator is simple and independent from other derived decorators.

Don’t forget to like/clap my blog-post and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing. If there is a specific design pattern that you would like to learn about then let me know in the comments below so I can provide it for you in the next few weeks.

Other quick-guides on design patterns:

1. Design Patterns — A quick guide to Abstract Factory.
2. Design Patterns — A quick guide to Bridge Pattern.
3. Design Patterns — A quick guide to Builder Pattern.
4. Design Patterns — A quick guide to Decorator Pattern.
5. Design Patterns — A quick guide to Facade Pattern.
6. Design Patterns — A quick guide to Observer Pattern.
7. Design Patterns — A quick guide to Singleton Pattern.

The Builder pattern is a creational design pattern that handles the construction of complex objects step by step (or brick by brick). It is probably the easiest pattern to spot if the existing code needs such design. The Builder pattern allows the creation of different representations of an object using the same construction code.

Builder pattern is classified in the creational design patterns which is all about class/object instantiation. More precisely, how to effectively use inheritance (class-creation patterns) or delegation (object-creation patterns). [by Design Patterns explained simply]

Example: Let’s start with an example on my favorite topic. Food!! More precisely the example will be about pizza. Pizza is separated into three layers, the dough, the sauce, and the toppings. Now, let’s ask ourselves, how would we “construct” a pizza object selecting among various toppings and a variety of sauces.

Questions before designing a solution to this problem:

• How would the Pizza class constructor look like?
• Should we have multiple overloading constructors with parameters for all the combinations like sauces, toppings plus sauces, etc? What if we have different types of dough as well?
• What if later on, we decide to add cheese or different types of cheese? Would that be easy to implement? What about dependencies on existing code?
• Should we just have a default constructor that creates a “plain pizza”? Wouldn’t that force the client to call a number of setters accordingly? Is this safe? What if the client forgets and then we send a plain pizza to the customer?

The solution to all these questions is the builder pattern. We need a “builder” to construct a pizza step by step. At the same time, the client will be safe to “order” a specific pizza and have the builder build it for him.

Step 1 — Keywords

1. Representation: An object can have different representations. For example, a pizza can have tomato mozzarella toppings and another representation of pizza would be with mushrooms and parma ham.
2. Construction code: Objects can be constructed in different ways, for example using constructors. Constructors can be overloaded, they have the same name (name of the class) but a different number/types of arguments. Depending on the number and type of arguments passed, the specific constructor is called.

It is easy to fall into the trap of having a class of numerous constructors where each one is taking a different number of parameters. The developer is forced to instantiate the class with the correct combination of parameters on each situation. This problem has a name, it is a popular anti-pattern called the telescoping constructor and builder pattern is the go-to solution for it. Let’s oversimplify Builder pattern by bluntly saying:

The Builder pattern’s main intent is to have the minimum number of overloading constructors to support the constuction of several representations of an object.

Step 2 — Diagram (By example)

Let’s stick to the pizza example. In summary, we have the pizza class, the cook and the concrete builders that inherit from the abstract builder. We will explain the diagram bottom to top:

• Pizza_Product: This class is the actual pizza. It is represented by three attributes: (1) Dough, (2) sauce and (3) toppings.

• ConcreteBuilder: Each concrete builder is responsible for a specific representation. In this example, we have Margherita and Spicy Pizza. Both concrete builders are responsible to “build” their own representation of pizza based on the three attributes listed above.
• AbstractBuilder: Contains a pizza member variable and the concrete builders inherit from it.
• Cook_Director: In this example, the director is the actual cook. The class is responsible to initiate the construction of a given representation by putting the pieces together such that the builder will follow and adapt according to the director’s needs.

Step 3 — Code by example

I would suggest to copy the code class by class from my git repository “Andreas Poyias” or the snippets below (in the order provided) and paste it in any of the available online C++ editors like c++shell, jdoodle , onlineGDBand run it to observe the output. Then read the comments or description below. Take time reading it thoroughly (that means one minute, not less and not more).

Product:
This is the pizza class. It is a simple class with three setters and a taste() method that prints all the ingredients.

#include <iostream>
#include <memory>     // unique_ptr
using namespace std;

class Pizza_Product
{
public:
 void setDough(const string& dough) { m_dough = dough; }
 void setSauce(const string& sauce) { m_sauce = sauce; }
 void setTopping(const string& topping) { m_topping = topping; }

void taste() const
{
  cout << "Pizza with " << m_dough << " dough, " 
       << m_sauce << " sauce and "
       << m_topping << " topping. Mmmmmmm." << endl;
}
private:
 string m_dough;
 string m_sauce;
 string m_topping;
};

Abstract Builder:
The abstract builder is an interface that contains a pizza object. It has a getter that returns the pizza object and a method to instantiate the pizza object. It also declares the three builder methods that will be implemented by the concrete builders further down.

class Pizza_Builder
{
public:
  virtual ~Pizza_Builder() {};

  Pizza_Product* getPizza(){ return m_pizza.release(); }

  void createNewPizzaProduct()
  {
    m_pizza = make_unique<Pizza_Product>();
  }

  virtual void buildDough() = 0;
  virtual void buildSauce() = 0;
  virtual void buildTop()   = 0;

protected:
  unique_ptr<Pizza_Product> m_pizza;
};

Concrete Builders:
Two examples of concrete builders and two representations of a pizza. They both implement their own build methods using the m_pizza object from the parent class (Abstract builder)

class Margherita_ConcreteBuilder : public Pizza_Builder
{
public:
 virtual void buildDough() { m_pizza->setDough("cross"); }
 virtual void buildSauce() { m_pizza->setSauce("tomato"); }
 virtual void buildTop() { m_pizza->setTopping("mozzarela+basil"); }
};

class Spicy_ConcreteBuilder : public Pizza_Builder
{
public:
 virtual void buildDough() { m_pizza->setDough("pan baked"); }
 virtual void buildSauce() { m_pizza->setSauce("tomato+chilli"); }
 virtual void buildTop(){ m_pizza->setTopping("pepperoni+salami"); }
};

Director:
This class puts everything together. It has a Pizza_Builder variable. It uses the makePizza()to receive a concrete builder as a parameter. Then calls the build operations which work for both representations accordingly. Therefore we achieve the purpose of having one construction-code to represent different types of pizzas. The tastePizza()method is to print the contents of a pizza.

class Cook_Director
{
public:
 void tastePizza(){ m_pizzaBuilder->getPizza()->taste(); }

void makePizza(Pizza_Builder* pb)
 {
   m_pizzaBuilder = pb;
   m_pizzaBuilder->createNewPizzaProduct();
   m_pizzaBuilder->buildDough();
   m_pizzaBuilder->buildSauce();
   m_pizzaBuilder->buildTop();
 }

private:
 Pizza_Builder* m_pizzaBuilder;
};

Main (client):
The main method operates as the client(the same as the previous guides). It is so easy for the client to be able to build different representations of a pizza. We need the director, and then, by just passing two different concrete builders as a parameter to themakePizza, we will be able totaste two different types of pizzas.

int main()
{
  Cook_Director               cook;
  Margherita_ConcreteBuilder  margheritaBuilder;
  Spicy_ConcreteBuilder       spicyPizzaBuilder;

  cook.makePizza(&margheritaBuilder);
  cook.tastePizza();

  cook.makePizza(&spicyPizzaBuilder);
  cook.tastePizza();
}

// Output

// Pizza with cross dough, tomato sauce and mozzarela+basil topping. // Mmmmmmm.

// Pizza with pan baked dough, tomato+chilli sauce and
// pepperoni+salami topping. Mmmmmmm.

Let’s summarise the benefits of this pattern:

• There are many possible representations but only one common input.
• We have a standard protocol for creating all possible representations. The steps of this protocol are clearly exposed by a Builder interface.
• There is one derived concrete class for each target representation.
• It is easy for a developer to add a new self-maintained and independent representation (of a Pizza) without the fear of breaking something else.
• The client can simply register the ConcreteBuilder to the Director and get the expected representation.

The next blog will be a quick guide to the Decorator design pattern. It is a structural pattern which is a must have to your knowledge repository. Don’t forget to like/clap my blog-post and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing. If there is a specific design pattern that you would like to learn about then let me know in the comments below so I can provide it for you in the next few weeks.

Other quick-guides on design patterns:

1. Design Patterns — A quick guide to Abstract Factory.
2. Design Patterns — A quick guide to Bridge Pattern.
3. Design Patterns — A quick guide to Builder Pattern.
4. Design Patterns — A quick guide to Decorator Pattern.
5. Design Patterns — A quick guide to Facade Pattern.
6. Design Patterns — A quick guide to Observer Pattern.
7. Design Patterns — A quick guide to Singleton Pattern.

The Bridge pattern is a very important design pattern. It is commonly used in industry as it is an easy way to simplify classes by separating the low-level logic implementation from the high-level definition of a class (which is usually abstracted/inherited). The purpose of this guide is to explain this pattern in three easy, clean steps.

The Bridge pattern is classified among structural design patterns which are all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality. [by Design Patterns explained simply]

Step 1 — Keywords

The formal definition of the Gang of Four (GoF) book — the first people to introduce the design patterns: “Bridge pattern decouples an abstraction from its implementation so that the two can vary independently.”

• Abstraction is a high-level interface that contains non-specific implementation of any control logic (or business logic).
• The logic is separated from abstraction and it exists in a different object the “implementation object” which is responsible for the low-level work.

The abstraction contains a reference to the implementation object, therefore it can control its methods. Let’s dive into an example with the use of diagrams.

Step 2 —Diagrams
Design Bridge pattern by example

In this example, we have three animals that “move” in different ways:

• Person that moves by walking. (We are all animals at the end of the day)
• Fish that moves by swimming.
• Bird that moves by flying.

Abstraction: It is only obvious that there is a pattern here. Three objects that move but in different ways. Why don’t we make an abstraction out of it?

As shown in the diagram, the class Animal is an abstraction (or interface) such that the three animals inherit from it. Each animal individually implements their own specific logic as to how they move(). Therefore, they declare their own move method.
However, we are still not quite there yet. Bridge pattern is NOT about a simple inheritance. The pattern’s intent is to separate the move()logic from the abstraction. In this example, the code within the Animal classes should only be about defining the animal object representations.

Implementation: Each move()method has a different logic (or control logic, or business logic). For example, a person walks by using his legs one at a time, a bird needs to flap its wings in a specific frequency and so on.

The diagram shows the full scale of the bridge pattern. The animals don’t implement their own move()methods but they have a MoveLogic object that they refer to. The move() implementation is decoupled from the Animal interface. The benefit is that the code in the Animal class is cleaner, easy to understand and smaller. Developers don’t need classes with thousand lines of code which is irrelevant to the object's definition. In addition, if in the future we would like to add a new class, for example, Reptilewe can use the existing Swim class instead of copy pasting the logic inside the Reptile class.

Step 3 — Code by example

I would suggest to copy the code class by class from my git repository “Andreas Poyias” or the snippets below (in the order provided) and paste it in any of the available online C++ editors like c++shell, jdoodle , onlineGDBand run it to observe the output. Then read the comments or description below. Take your time, reading it thoroughly (that means one minute, not less and not more).

Implementation:
First, we start with the implementation objects. We have the different types of movement likeWalk and Swim, inheriting fromMoveLogic. Each of those classes contains the logic required for the specificmove() function “hiding” the implementation from the Animals. This probably sounds familiar to another design pattern from a previous blog (the Facade pattern). The main difference between the two is the intent. One could easily say that the MoveLogic could as well be the Facade such that the Animal classes don’t contain and maintain the complexities of the move operation.

#include<iostream>
#include<string>
using namespace std;
 
class MoveLogic {
public:
    virtual void move() = 0;
};
 
class Walk : public MoveLogic {
public:
    void move() { cout << "Move alternating legs\n"; }
};
 
class Fly : public MoveLogic {
public:
    void move() { cout << "Flap wings\n"; }
};

Abstraction:
This is a simple inheritance from an interface. Each animal’s is constructor receives a MoveLogic object to be initialized. Then the animal can call the move() function where the move is going to perform the complicated logic that is required.

class Animal {
public:
    virtual void howDoIMove() = 0;
};
 
class Person : public Animal {
    MoveLogic* _myMoveLogic;
public:
    // Constructor receives the MoveLogic object to be initialized
    Person(MoveLogic *obj): _myMoveLogic(obj){}

    void howDoIMove() {
        _myMoveLogic->move();
    }
};
 
class Bird : public Animal {
    MoveLogic* _myMoveLogic;
public:
    Bird(MoveLogic *obj) :_myMoveLogic(obj){}
    void howDoIMove() {
        _myMoveLogic->move();
    }
};

Main function
As always (in my examples) the main function operates as the client. The client’s job is simple. MoveLogic objects are created, then they are passed to the animals which use the decoupled move implementation.

int main() 
{
    MoveLogic* walk = new Walk();
    MoveLogic* fly  = new Fly();
 
    Animal* animalA = new Person(walk);
    Animal* animalB = new Bird(fly);
 
    animalA->howDoIMove();
    animalB->howDoIMove();
 
    return 1;
}

// Output:
// Move alternating legs
// Flap wings

The next blog will be a quick guide to the Builder design pattern. It is a creational pattern which is a must have to your knowledge repository. Don’t forget to like/clap my blog-post and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing. If there is a specific design pattern that you would like to learn about then let me know so I can provide it for you in the future.

Other quick-guides on design patterns:

1. Design Patterns — A quick guide to Abstract Factory.
2. Design Patterns — A quick guide to Bridge Pattern.
3. Design Patterns — A quick guide to Builder Pattern.
4. Design Patterns — A quick guide to Decorator Pattern.
5. Design Patterns — A quick guide to Facade Pattern.
6. Design Patterns — A quick guide to Observer Pattern.
7. Design Patterns — A quick guide to Singleton Pattern.

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

Observer pattern is a very commonly used pattern. In fact, it is so common that is being standardized in many programming languages/libraries. In Java, it exists injava.util.Observer (deprecated in Java 9). In Python it as close as apip install pattern-observer. In C++, we can sometimes use boost library, more precisely #include <boost/signals2.hpp>. However, it is widely used in industry as a custom-made solution. To be able to use it correctly and understand its complexity, we need to dive in and explore it.

Observer pattern is classified among the behavioral design patterns. Behavioral design patterns are most specifically concerned with communication between classes/objects. [by Design Patterns explained simply]

What is an observer pattern? Apart from a walking monitor that broadcasts analog television (as in the picture). The pattern’s aim is to define a one-to-many relationship such that when one object changes state, the others are notified and updated automatically. More precisely, it wishes to be informed about events happening in the system. Lets put the pieces of the puzzle together in three steps.

Step 1 — Keywords

Defining keywords is the secret recipe in this series of quick-guides. This method helped me truly understand the design patterns, hardcode them in my mind and comprehend the differences among other design patterns.

1. Subject: It is considered as the keeper of information, of data or of business logic.
2. Register/Attach: Observers register themselves to the subject because they want to be notified when there is a change.
3. Event: Events act as a trigger in the subject such that all the observers are notified.
4. Notify: Depending on the implementation, the subject may “push” information to the observers, or, the observers may “pull” if they need information from the subject.
5. Update: Observers update their state independently from other observers however their state might change depending on the triggered event.

Step 2 — Diagram

Lets split this design into different classes to simplify this a little bit.

• The ConcreteObservers are classes that contain information specific to the current instance. The update function is called by the subject’s notify() operation. The observers update independently based on their current state.
• The Observer is the parent class of the concrete observers. It contains a subject instance. When an observer is initialized, it registers/attaches itself to the subject.
• The Subject class has a list or a collection of observers. When an event is triggered it calls the notify()operation which loops through all the observers by calling their update function.

Step 3 — Code by Example

I would suggest to copy the code class by class from my git repository “Andreas Poyias” or the snippets below (in the order provided) and paste it in any of the available online C++ editors like c++shell, jdoodle , onlineGDB and run it to observe the output. Then read the comments or description below. Take your time, reading it thoroughly (that means one minute, not less and not more).

Example: Consider a football game. Many supporters are watching the game. We split the supporters into two categories by age, young and old. When their team scores a goal the supporters react differently according to their age and their excitement level.
Now, let’s talk with terms used for the observer pattern:

• The game is the subject and the supporters are the observers.
• All observers are attached/registered to the subject and they are notified when their football team scores (the trigger-event is if their team scores).
• The observers update their behavior depending on the notification received.

Subject
For this class, we need access to a list of observers. When the observers are about to register, they call theattach(this) function to add themselves to the available list (this is an observer's instance). When an event is triggered wenotify() all of the observers to independently update their state. In this example, the trigger is if the observer’s football team scored.

#include <iostream>
#include <vector>
using namespace std;

class Subject {
    vector < class Observer * > observers; 
    bool scored;                    // trigger, event

public:
    // register observers
    void attach(Observer *obs) {
        observers.push_back(obs);
    }
   
   // This is the EVENT
   // set the if scored and notify ALL observers
   void setScored(bool Score) {
      scored = Score;
      notify();
   }

bool getScored() {
      return scored;
   }

   // notify implementaion is further down
   // so that the script compiles and runs
   void notify();
};

Observer
This class is dependent on the subject it is registered with. When concrete observers get initialized they attach themselves to theSubject. In this example, the state of each observer is his excitementLevelabout the game.

class Observer 
{
    Subject *subj;
    int excitementLevel;               // state

  public:
    Observer(Subject *mod, int excLevel) 
    {
        subj = mod;
        excitementLevel = excLevel;
        // Observers register/attach themselves with the Subject
        subj->attach(this);
    }

    virtual void update() = 0;

  protected:
    Subject *getSubject() {
       return subj;
    }

    void setExcitementLevel(int excLevel) {
       excitementLevel = excLevel;
    }

    int getExcitementLevel() {
       return excitementLevel;
    }
};

This is theSubject::notify() declaration and as we mentioned before its job is to notify all observers to update their state.

void Subject::notify() {
  for (int i = 0; i < observers.size(); i++)
    observers[i]->update();
}

Concrete Observers
The concrete observers inherit from the Observer class and they all must have the update function. In this example, the concrete observers are distinguished between young and old supporters. If their excitement level gets too high the older supporters have the risk of heart attacks and the younger ones have the risk of drink and drive. Their state updates independently as we will prove in the main function further below.

class Old_ConcreteObserver: public Observer 
{
   public:
     // Calls parent constructor to register with subject
     Old_ConcreteObserver(Subject *mod, int div)
        :Observer(mod, div){}

     // For older people, if the excitement level 
     // is over 150 they run risk of heart attack
     void update() 
     {
        bool scored = getSubject()->getScored(); 
        setExcitementLevel(getExcitementLevel() + 1);

        if (scored && getExcitementLevel() > 150) 
        {
          cout << "Old Observer's team scored!!" 
               << " His excitement level is " 
               << getExcitementLevel() 
               << " watch out of heart attacks!" << endl;
        }else{
          cout << "Team didn't score. Yeeeih nothing to worry about"
               << endl;
        }
    } // end update()
};

class Young_ConcreteObserver: public Observer 
{
   public:
     // Calls parent constructor to register with subject
     Young_ConcreteObserver(Subject *mod, int div)
       : Observer(mod, div){}

     // For older people, if the excitement level 
     // is over 100 they run risk of heart attack
     void update() 
     {
        bool scored = getSubject()->getScored(); 
        setExcitementLevel(getExcitementLevel() + 1);

        if (scored && getExcitementLevel() > 100) 
        {
          cout << "Young Observer's team scored!!" 
               << " His excitement level is " 
               << getExcitementLevel() 
               << " dont't drink and drive!!" << endl;
        }else{
          cout << "Team didn't score. Yeeh nothing to worry about"
               << endl;
       }
    } // end update()
};

Main function
The concrete observers register themselves to theSubject instance. Their state is the excitement level which is the second parameter. When the event is triggered “subj.setScored(true)”, thenSubject::notify() is called to update the registered observers. In the scenario below, we have three observers, the youngObs1is overexcited and runs the risk of drink and drive, the oldObs1is also overexcited a runs a different risk (of heart attack). Finally, youngObs2 who is also young as the first one has nothing to worry about as he is not overexcited.

It is important to notice that the three observers updated independently based on their state (excitement level) and their type (young or old).

int main() {
   Subject subj;
   Young_ConcreteObserver youngObs1(&subj, 100); 
   Old_ConcreteObserver oldObs1(&subj, 150); 
   Young_ConcreteObserver youngObs2(&subj, 52);
   subj.setScored(true);
}

// Output
// Young Observer's team scored!! His excitement level is 101
// dont't drink and drive!! 

// Old Observer's team scored!! His excitement level is 151 watch 
// out of heart attacks! Team didn't score. 

// Yeeh nothing to worry about

There are a few benefits for the use of Observer pattern and a few points to be noted when this pattern is to be approached[Learning Python Design Patterns].

• The Observer pattern provides a design where the Subject and Observer are loosely coupled. The subject does not need to know about the ConcreteObserver class. Any new Observer can be added at any point in time. There is no need to modify the Subject when a new Observer is added. Observers and subjects are not tied up and are independent of each other, therefore, changes in the Subject or Observer will not affect each other.
• There is no option for composition, as the Observer interface can be instantiated.
• If the Observer is misused, it can easily add complexity and lead to performance issues.
• Notifications can be unreliable and may result in race conditions or inconsistency.

The next blog will be a quick guide to the Bridge design pattern. It is a structural design pattern which is used quite a lot in the industry. Don’t forget to like/clap my blog-post and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing. If there is a specific design pattern that you would like to learn about then let me know so I can provide it for you in the future.

Other quick-guides on design patterns:

1. Design Patterns — A quick guide to Abstract Factory.
2. Design Patterns — A quick guide to Bridge Pattern.
3. Design Patterns — A quick guide to Builder Pattern.
4. Design Patterns — A quick guide to Decorator Pattern.
5. Design Patterns — A quick guide to Facade Pattern.
6. Design Patterns — A quick guide to Observer Pattern.
7. Design Patterns — A quick guide to Singleton Pattern.

Design Patterns — A quick guide to Observer pattern. was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.

Facade pattern is often needed when there is a large number of interdependent classes or because parts of the code are unavailable. It is used as a camouflage to cover the complexities of a large system and therefore provides a simple interface to the client. In other words, it is a wrapper class used to hide the implementation details.

Facade pattern is classified as a structural design pattern. This design patterns is all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality. [by Design Patterns explained simply]

The picture above is the perfect example of a Facade pattern. A customer in a restaurant orders food from the menu, which is probably described in half a line. The order goes to the kitchen and the food comes back after a while. Simple! The customer doesn’t want to know who will cut the meat for how long will it be cooked and who is going to wash the dishes afterward. The customer just wants to eat a tasty meal that meets the expectations. Therefore, the menu serves as the facade to make it easier for the customer by avoiding the complexities coming from the kitchen or even the tasks that the waiter is assigned through this process.

Step 1 — Keywords

Defining keywords is the secret recipe in this series of quick-guides. This method helped me truly understand the design patterns, hardcode them in my mind and comprehend the differences among other design patterns.

1. Simplification: This is the goal of this design pattern. Simplify a complicated system.
2. Restriction: Simplification often comes with a “sacred cost”, restriction. By simplifying the code, we restrict clients from unauthorized access. Therefore, it prevents them from doing mistakes that would be difficult to be perceived in a complicated subsystem.

There is a tradeoff between simplification and restriction. Over-simplifying a system means that the developer is over-restricted, therefore less freedom than necessary which not always a good thing. Under-simplifying Facade pattern means that there is too much freedom which makes the Facade pattern irrelevant. Finding the fine balance is what makes a good, useful and effective Facade pattern.

Step 2 — Diagram

The diagram is also based on the given example. To simplify this diagram we can separate into three pieces.

1. Client: The client in this example is the customer of a restaurant that wants to order food.
2. Facade: Its job is to be able to provide to the client more simplified access towards numerous interdependent subsystems that are considered complicated. In this example, a client’s food-order would require a series of carefully sequenced method calls of two different subsystems (Waiter and Kitchen).
3. Subsystems: The subsystems are hidden from the client. They might also be not accessible to the client. The client cannot fiddle with any of the subsystems where a simple code-change may prove to be fatal or even break other unknown parts of the system itself. In this scenario, the waiter and the kitchen have to do a series of tasks. A subsystem’ s task is sometimes dependent on the anothers task. For example, the kitchen cannot prepare the food if the waiter doesn’t bring the order to the kitchen. The waiter cannot serve the customer if the food is not cooked.

Step 3 — Code by example

I would suggest to copy the code class by class from my git repository “Andreas Poyias” or the snippets below (in the order provided) and paste it in any of the available online C++ editors like c++shell, jdoodle , onlineGDB and run it to observe the output. Then read the comments or description below. Take your time, reading it thoroughly (that means one minute, not less and not more).

Subsystems

In this example, the two subsystems are the Waiter_Subsystem1and theKitchen_Subsystem2. At a first glance, each subsystem seems to be independent as they can do certain tasks individually. But is this true?

#include <iostream>
using namespace std;

class Waiter_Subsystem1
{
public:
  void writeOrder()   { cout << " Waiter writes client's order\n";}
  void sendToKitchen(){ cout << " Send order to kitchen\n";}
  void serveCustomer(){ cout << " Yeeei customer is served!!!\n";}
};

class Kitchen_Subsystem2
{
public:
    void prepareFood(){ cout << " Cook food\n";}
    void callWaiter() { cout << " Call Waiter\n";}
    void washDishes() { cout << " Wash the dishes\n";}
};

Facade: In this example, the Facade class is about food-orders in the restaurant. To execute a food-order successfully, we rely on a specific sequence of method calls and one call is dependent on the previous one and so on. The kitchen, cannot prepare the food if the waiter doesn’t write the order and send it to the kitchen. The Facade class provides theorderFood task to the client to simplify it and avoid any misuse due to the complexity that exists.

class Order_Facade
{
private:
    Waiter_Subsystem1waiter;
    Kitchen_Subsystem2 kitchen;
public:
    void orderFood()
    {
        cout << "A series of interdependent calls on various subsystems:\n";
        waiter.writeOrder();
        waiter.sendToKitchen();
        kitchen.prepareFood();
        kitchen.callWaiter();
        waiter.serveCustomer();
        kitchen.washDishes();
    }
};

Main function
The main function operates as the client(the same as the previous guides). It is so easy for the client to be able to create a Facade instance and call a function to do his job.

int main(int argc, char *argv[])
{
    // Simple for the client 
    // no need to know the order or the 
    // dependencies among various subsystems.
    Order_Facade facade;
    facade.orderFood();

return 0;
}

// Output
// A series of interdependent calls on various subsystems:
//  Waiter writes client's order
//  Send order to kitchen
//  Cook food
//  Call Waiter
//  Yeeei customer is served!!!
//  Wash the dishes

There are a few benefits for the use of Facade pattern and a few points to be noted when Facade is to be approached.

• Facade defines a higher-level interface that makes the subsystem easier to use by wrapping a complicated subsystem.
• This reduces the learning curve necessary to successfully leverage the subsystem.
• It also promotes decoupling the subsystem from its potentially many clients.
• On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that “power users” may need.

The next blog will be a quick guide to the Observer design pattern. It is a behavioral pattern which is a must have to your knowledge repository. Don’t forget to like/clap my blog-post and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing. If there is a specific design pattern that you would like to learn about then let me know so I can provide it for you in the future.

Other quick-guides on design patterns:

1. Design Patterns — A quick guide to Abstract Factory.
2. Design Patterns — A quick guide to Bridge Pattern.
3. Design Patterns — A quick guide to Builder Pattern.
4. Design Patterns — A quick guide to Decorator Pattern.
5. Design Patterns — A quick guide to Facade Pattern.
6. Design Patterns — A quick guide to Observer Pattern.
7. Design Patterns — A quick guide to Singleton Pattern.

This is another quick-guide to mastering a very commonly used design pattern, the Singleton pattern. Singleton pattern is one of the simplest but most controversial design patterns (with pros and many cons). This is one of the main reasons why it is very common in programming interviews.

Singleton pattern is classified in the creational design patterns which is all about class/object instantiation. More precisely, how to effectively use inheritance (class-creation patterns) or delegation (object-creation patterns). [by Design Patterns explained simply]

Singleton definition: In mathematics, is defined as “a set which contains exactly one element”. This pattern is very simple to understand and easy to implement since it is only a few lines of code and the application is quite straight-forward. It is a pattern that ensures a class has only one instance and provides a global point of access to it. For example, we can only have one active Pope of Italy, therefore, it is possible that the Pope can be represented with a Singleton pattern.

Step 1 — Keywords

Defining keywords is the secret recipe in this series of quick-guides. This method helped me truly understand the design patterns, hardcode them in my mind and comprehend the differences among other design patterns.

This time the keywords take us a trip back to basics. It is an introduction to the very simple code that will follow. Feel free to skip to the next step if you feel comfortable with the terms.

1. Class-instance: An instance is a concrete occurrence of any object. It exists usually during the runtime of a computer program and it emphasizes in distinctly identifying the object. Similarly, class-instances are created from classes by subroutines like constructors/destructors.
2. Private Constructor: A private constructor is a special instance constructor. It is generally used in classes that contain static members only. If a class has one or more private constructors and no public constructors, then other classes (except nested classes) are not allowed to create instances of this class.
3. Static data members: When we declare a member of a class as static it means no matter how many objects of the class are created, there is only one copy of the static member. [from TutorialPoint]
4. Static Function: A static member function can be called even if no objects of the class exist. [from TutorialPoint]

Step 2 — Diagram

There are one-two programming tricks to make a class Singleton. Other than that it is quite trivial. Reading the diagram from top to bottom: We should have

• A static(underlined) and private(-) instance of the class
• A private constructor.
• A public(+) and static function that returns the instance.

Class definition should not be more than 7–8 lines of code, depending on the programming language.

Step 3 — Code by example

I suggest to copy the code class by class from my git repository “Andreas Poyias” or from the snippets here and paste it in any of the available online C++ editors like c++shell, jdoodle , onlineGDB and run it to observe the output. Then read the comments or description below.

Class definition
I am showing the class definition in C++ which is 8 lines of code.

#include <iostream>

class Singleton
{
public:
    static Singleton *getInstance();
private:
    Singleton(){}
    static Singleton* s_instance;
};

Now we move on to the declaration of the getInstance()method and the static data member which is outside the class definition. There are different ways to write the getInstance function. For simplicity, I chose the one shown in the snippet below. So if the instance does not exist, instantiate one if it does exist then just return it.

Singleton* Singleton::s_instance = 0;

Singleton* Singleton::getInstance()
{
    if(!s_instance) {
        s_instance = new Singleton();
        std::cout << "There is no instance so we created one.\n";
        return s_instance;
    }else{
        std::cout << "Hey this is the same instance!\n";
      return s_instance;
    }
}

Main function
The main function operates as the client. The client cannot create a second instance of theSingletonclass and is forced to use the existing one. This can be displayed by the output as well.

int main()
{
 Singleton *singlA = Singleton::getInstance();
 Singleton *singlB = Singleton::getInstance();
 return 0;
}

// Output
// There is no instance so we created one.
// Hey this is the same instance!

There are a few benefits for the use of Singleton pattern. Other design patterns like Abstract Factory, Facade can use Singleton pattern (usually only one Facade object is required). As I mentioned in the first paragraph this design pattern is quite controversial and that is why a popular interview question is: “what is wrong with Singleton pattern, or why is Singleton pattern considered anti-pattern?”

Anti-pattern
I will summarise the reasons why singleton is considered anti-pattern. There is a very popular discussion on StackOverflow which provides really good justice justifying why one should be careful with this design pattern.

1. Singleton patterns violate the single responsibility principle: by virtue of the fact that they control their own creation and lifecycle.
2. They are generally used as a global instance which may lead to hidden dependencies in the code that could be exposed via interfaces.
3. They inherently cause code to be tightly coupled.
4. It is very difficult to adjust Singleton pattern in a multithreading environment and very easy to fall into race condition problems during initialization.

For deeper understanding as to why this is considered anti-pattern, have a look in this site by Michael Safyan.

Since we mentioned it above, the next blog will be a quick guide to the Facade design pattern. The Facade is not a creational pattern like Singleton and Abstract Factory but is classified as a structural design pattern. Don’t forget to like/clap my blog-post and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing.

Other quick-guides on design patterns:

1. Design Patterns — A quick guide to Abstract Factory.
2. Design Patterns — A quick guide to Bridge Pattern.
3. Design Patterns — A quick guide to Builder Pattern.
4. Design Patterns — A quick guide to Decorator Pattern.
5. Design Patterns — A quick guide to Facade Pattern.
6. Design Patterns — A quick guide to Observer Pattern.
7. Design Patterns — A quick guide to Singleton Pattern.

This is a quick-guide to mastering one of the most commonly used design patterns, the Abstract Factory. Even though the coding examples will be in C++ as I am more comfortable with, they can be easily adjusted to any programming language like Java, Python, C#, Javascript and more.

Abstract Factory is classified in the creational design patterns which is all about class/object instantiation. More precisely, how to effectively use inheritance (class-creation patterns) or delegation (object-creation patterns). [by Design Patterns explained simply]

Factory definition: “It is a building or group of buildings where products are manufactured/created”. Products are then being sent to the clients for use at their own responsibility. At the same time, the factory clients are many, it should be fairly easy for the clients to order their product and similarly easy for the factory to adapt according to the client’s needs.

Let’s connect the dots to understanding this design pattern. We use it when we need an interface for the creation of dependent objects without necessarily specifying their concrete classes. At the same time, we want to encapsulate the construction of “products” using inheritance.

Step 1 — Keywords

Defining keywords is the secret recipe in this series of quick-guides. This method helped me truly understand the design patterns, hardcode them in my mind and comprehend the differences among other design patterns.

1. Product: It is an object built by a factory and it is included in a family of objects. It is very specific as there is no abstraction to it. Example: BMWdoorHandle, FordDoorHandle.
2. Abstract Product: It is a higher level view of a product which defines its family. Example DoorHandle, DoorWindow
3. Concrete Factory: It is a factory that is “physically” micro-managing the creation and completion of a product. Example: BMWFactory, FordFactory.
4. Abstract Factory: Is an interface for creating families of related or dependent objects without specifying their concrete classes. Example: CarFactory

Step 2 —Diagram

When discussing Abstract Factory everything should be relevant to the keywords above. If the code starts to diverge from those words then probably something isn’t quite right. Let’s make this simple, Concrete Factory is inheriting from Abstract Factory and Product from Abstract Product. The diagram is as plain as it looks; two classes inheriting from their abstract classes. The concrete factory is the one to do the dirty work to create specific Products (which is identified by the red line). Now with this diagram, it is easy to understand that this design pattern can easily be updated by adding more concrete factories and more products i.e. ProductC, ProductD etc. In other words, this picture can only grow wider and definitely not in height.

Step 3 — Code by example

I would suggest to copy the code class by class from my git repository “Andreas Poyias” and paste it in any online C++ editor like c++shell, jdoodle or onlineGDB or any other and run it to observe the output. Then read the comments or description below. The class names are written such that after the underscore I give the keyword related to it.

AbstractProduct
The abstract product is an abstract class and as expected it defines a family of products that inherit from it. In this example, the abstract product is aDoorHandle, I added a function that prints something for the purposes of showcasing.

#include <iostream>

class DoorHandle_AbstractProduct
{
public:
 // A dummy function that prints something
 virtual void printSerialNumber() = 0;
};

Product
In this example, the products are BMW or Ford door handle. They have different serial numbers, therefore, each class can print their own product-specific serial number. We could also have DoorWindoworSteeringWheel. The door handle classes inherit from the abstract class above.

// BMW door handle [in the family of doorHandles]
class BMWDoorHandle_Product : public DoorHandle_AbstractProduct 
{
public:
    // Prints product-specific serial number
    void printSerialNumber (){
        std::cout << " DoorHandle_Product: BMW123 \n";
    }
};

// Ford door handle [in the family of doorHandles]
class FordDoorHandle_Product : public DoorHandle_AbstractProduct 
{
public:
    // Prints product-specific serial number
    void printSerialNumber (){
        std::cout << " DoorHandle_Product: Ford123 \n";
    }
};

AbstracFactory
This is a very generic/abstract class which should not have much more than the createfunctions. In the end, a factory is just creating products.

class Car_AbstractFactory 
{
public:
 virtual DoorHandle_AbstractProduct* createDoorHandle () = 0;
 //virtual DoorWindow_AbstractProduct* createDoorWindow () = 0;
};

ConcreteFactory
This factory class is quite specific to the product. It is the hard worker that puts the puzzle together. In this example, it is specific to a brand {BMW, Ford}. Its job is to return an instance of a product which is specific to that brand. Again, if we wanted to createBMWDoorWindow we could actually create a new function that returns an instance of the relevant abstract class. In my git repository, there is the full implementation with theDoorWindow parts as well.

class BMWCar_ConcreteFactory : public Car_AbstractFactory 
{
public:
    DoorHandle_AbstractProduct* createDoorHandle (){
        return new BMWDoorHandle_Product;
    }
};

class FordCar_ConcreteFactory : public Car_AbstractFactory 
{
public:
    DoorHandle_AbstractProduct* createDoorHandle (){
        return new FordDoorHandle_Product;
    }
};

Main function
Finally, this is the last piece of code. The main function which operates as the client. The client can easily “order” products from the factory and can use them in any way he likes.

int main()
{
    // Client needs a doorHandle and a doorWindow
    Car_AbstractFactory* abstractFactory;
    DoorHandle_AbstractProduct* dHandle_AbstractProduct;
 
    // The client needs products from Ford brand
    abstractFactory = new FordCar_ConcreteFactory;

    // Ford concrete factory creates them 
    // and returns them to the client
    dHandle_AbstractProduct = abstractFactory->createDoorHandle();

    // Client uses the products
    dHandle_AbstractProduct -> printSerialNumber();

    // Now the client wants products but from BMW brand
    abstractFactory = new BMWCar_ConcreteFactory;

    // So the BMW concrete factory creates them 
    // and returns them to the client
    dHandle_AbstractProduct = abstractFactory->createDoorHandle();

    // Client uses the products
    dHandle_AbstractProduct -> printSerialNumber();

return 0;
}

// Output
// DoorHandle_Product: Ford123   
// DoorHandle_Product: BMW123

Benefits might not be instantly obvious. But imagine for a second how many products a car has and how many things can a car factory do. Now imagine the chaos maintaining a badly designed code every time BMW decides to alter a door handle. Add a new type of driver-seat or even change something in the engine. Now adding to the complexity, imagine maintaining these problems but for multiple brands. Abstract factory offers a maintainable and clean approach, that can be used for years to come. It would be difficult for a new developer to mess up and so easy to add/remove a new product.

Abstract factory is just the beginning of this journey. This is one of the most commonly used design patterns and many times it is used in combination with other design patterns. The next blog will be a quick-guide to Singleton design pattern. Don’t forget to like my blog and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing.

Other quick-guides on design patterns:

1. Design Patterns — A quick guide to Abstract Factory.
2. Design Patterns — A quick guide to Bridge Pattern.
3. Design Patterns — A quick guide to Builder Pattern.
4. Design Patterns — A quick guide to Decorator Pattern.
5. Design Patterns — A quick guide to Facade Pattern.
6. Design Patterns — A quick guide to Observer Pattern.
7. Design Patterns — A quick guide to Singleton Pattern.