Author image

Command Design Pattern

Encapsulate a request as an object, thereby letting users parameterize clients with different requests, queue or log requests, and support undoable operations.

You are not encapsulating the object that sends the request, or the object that receives the request, but encapsulate the actual request as an object with state. Of course, some commands can be stateless chunks of pure behavior (no data members).
The command pattern also makes undoable operations a piece of cake (they're considerably harder to implement wihout it). Derived Commands can leverage CRTP to be statically bound. To familiarize yourself with CRTP check this tutorial.

Note that the code executing the commands is responsible for freeing their memory.


  • define a base class or interface (abstract class)...

Author image

Curiously Recurring Template Pattern

Curiously Recurring Template Pattern, or CRTP for short, is ultimately a C++ only idiom. It is also known as Static Polymorphism or Simulated polymorphism.

Requirements for dynamic polymorphism:

  1. Is-a relationship between base and derived class.
  2. Base class defines a 'generic' algorithm that is used by derived class.
  3. The 'generic' algorithm is customized by the derived class.

Requirements for static polymorphism:

  1. 'Is-a' relationship between base and derived class.
  2. Base class defines a 'generic' algorithm that is used by derived class.
  3. The 'generic' algorithm is customized by the derived class.
  4. This method is pure virtual. The derived method implements it. But, to avoid run time costs:
  5. When the specialized method is invariant of the one in the base method then this resolution can be achieved...

Author image

Strategy Design Pattern


Define a family of algorithms, encapsulate each one and make them interchangeable.

It is also known as 'policy' pattern. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

Strategy vs State:

In contrast to the State pattern which favors inheritance, Stategy favors composition, while both allowing you to change object properties @ runtime. with State the object literally changes its class at runtime (requires inheritance). With Strategy the object itself doesn't change, some of its behaviors though can change (requires composition).


  • create your algorithms as classes, or abstract classes
  • refine your algorithms by inheriting from them
  • create your target object
  • the...

Author image

State Design Pattern

This is a demonstration of the State Design Pattern in C++ with a groovy example that sticks (hopefully).

The state pattern allows an object to alter its behavior at runtime when its internal state changes. There is a base State class and various concrete derives state classes. The state class hierarchy make up a state machine and the desired object can be at any single state at a time. State is an alternative behavioral software design pattern to the Strategy pattern.

Author image

Visitor Design Pattern

I have to agree that this designed pattern confused me for a longer time than I'd want to admit. But your confusion is now over! This cancer curing project will solve all mysteries for the Visitor pattern.

A decent example works wonders! The project provides an example that is implemented without a vistor and then with a visitor. Compare and contrast and imagine the possibilities of what you and a Visitor can accomplish if you work togethearoar!

I've used Windows 8.1 x86_64, Visual Studio 2017, C++17 to compile

Definition: Represent an operation to be performed on elements of an object structure. Visitor lets you define a new operation without changing (recompiling) the classes of the elements on which it operates.

Did you understand anything yet? No, I didn't think so; keep on reading. I never understood those definitions either!

Visitor is a behavioral software design pattern is a good choice if you would want...

Author image

Composite Design Pattern

Here we decipher the obscure Composite Pattern hieroglyphics.

Definition: Compose objects into tree structures to represent part-whole hierarchies.

The Composite pattern enables us to iterate over objects or collection of those objects in a uniform manner, without having to typecheck or differentiate between the concrete objects and their collections. All those objects share a common interface/base class.

The whole point of the Composite pattern is that the Composite can be treated atomically as if it was a leaf object, without needing to know that there are many objects inside. Leaf objects perform a request directly, and Composite objects forward the request to their child components recursively downwards the tree structure. This makes client classes easier to implement, change, test, and reuse.

Author image

Proxy Design Pattern

What is a proxy? Dictionary says “The authority to represent someone else”. hmmm… Ponder on that a bit and let's see how the “Name and Conquer” of Proxy applies to software design patterns.

The definition of the Proxy pattern goes like this:

Provides a surrogate or placeholder for another object in order to control access to it.

Let's get the obvious stuff out of the way:

  1. A proxy certainly provides another level of indirection to another “target” object that we basically want to access

That's it. I have nothing else that seems obvious from the definition alone. But after further investigation and coding I realize that a Proxy object is indeed useful when we want to lazy-instantiate an object, or when we want to hide the implementation details of the object. For whatever reason, but this often comes up in software, we represent a back-end highly complicated object with a more...

Author image

Adapter, Wrapper, Facade Design Pattern

Here we will disambiguate the Adapter Wrapper Facade Software Design patterns.

A confused pattern, yes.
It has many names.
Adapter, Facade, Wrapper.
But they're all pretty much the same..

Basically the Adapter (aka Facade aka Wrapper class) wraps a legacy class with a new interface into an updated class that respects the new interface. It is often used to make existing classes work with others without modifying their source code. Many Windows WinAPI functions are an example of this.


  • an interface (perhaps legacy) is not compatible with the current system needs
  • an abstract base class is created that specifies the desired interface
  • an adapter class is defined that publicly inherits the interface of the abstract class, and privately inherits the implementation of the legacy class
  • this adapter class “(impedance) matches” the new interface to...

Author image

Pointer to Implementation (Pimpl) - Bridge Design Pattern

In C++, when anything in a header file class definition changes, all users of that class must be recompiled - even if the only change was to the private class members that the users/clients of the class cannot even access. This is because C++'s build model is based on textual inclusion, and because C++ assumes that callers know two main things about a class that can be affected by private members: 1. Size and Layout 2. Functions

Because private data members of a class participate in its object representation, affecting size and layout, and because private member functions of a class participate in overload resolution (which takes place before member access checking), any change to those implementation details requires recompilation of all users of the class.

pImpl breaks this compilation dependency by storing only a pointer to another class; changes to the implementation do not cause recompilation. Consequently, if a library uses pImpl in its ABI,...

Author image

Prototype Design Pattern

Implementing Prototype Design Pattern like a boss and then laughing it out.
Bonus: lewd way of spawning arrays of objects from a prototypical instance.

The prototype pattern is used when the type of object(s) to create is determined by a prototypical instance, which is cloned to produce new objects. This pattern is used to:

  • avoid subclasses of an object creator, like the factory pattern does
  • avoid the inherent cost of creating a new object in the standard way (like using new) when can be prohibitively expensive for a given application


  1. define a Prototype class with a clone() method that returns a copy of itself
  2. create subclasses of Prototype which describe the concrete types. Implement the clone method (and whichever other method you want of course)
  3. create a...

1 2 3 ... 6