Tagged: C++

Design Patterns: Builder

It’s time for another design pattern example and today it’s gonna be builder design pattern! Another creational pattern, as the name suggests. And how does it work?

Using builder pattern is something like outsourcing a constructor into a separate class. It deals with building object that have a lot of various parts. This increases the level of complexity of the object, which often results in complicated initialization. Builder splits the construction into a number of stages in which different parts are built. The builder is an abstract class (or an interface) that is able to build various components of the final object, but not the object itself. The building process is controlled by another class — a director. Director has an instance of builder and uses it to build the final object. Decides what components will be used and at the end, the director’s output is the final fully initialized object.

Class diagram

Class diagram for builder pattern (source: wikipedia.org)

The example, I will be working with is a process of assembling a car. Don’t worry, I won’t go through each screw in the engine, I don’t know much about that stuff anyway :-). The point is, a car is quite complicated thing to build and that’s exactly what we’re looking for.

So take this, we’re in a factory that builds two types of cars: a big-ass SUVs and tiny smarts. The both cars have virtually the same parts. Well, both have wheels, an engine, some windows (not to be confused with the operating system, that would be a deadly weapon, a car with Windows XP installed) and maybe doors. They might differ in their attributes — size, shape, used material, but both are used for the same purpose and in our example, they will be of the same type.

Then, there are two types of guys in our store — builders and a director. Builders work on the low-level. Every builder knows how to assemble various parts of a car (an engine, car body, a wheel). There might be multiple builders for multiple types of cars — nobody can understand everything. The director then takes those parts from a builder and puts them together so they form a working vehicle. The director controls the whole construction process, does important decisions and takes responsibility for the product while builders take care of assembling the smaller basic parts.

When a customer comes to the director and says, `Hi, can I have one Big Ass SUV?’ The director’s like, `Sure buddy, gimme a sec’, and goes into the back of the store to the builders. He asks them for the parts and assembles them together. After while he comes back and hands the customer the keys to his new chick magnet. If something goes wrong during this process, for instance builder cannot give him four wheels because they’ve run out of tires, the director apologizes to the customer, that they cannot build him the SUV today (maybe next time).

In other words, there are one algorithm for setting up an object from some parts, which is implemented in director class and it’s independent from the exact types of the basic parts. Basic parts are built by builders, that are associated with the director. The final shape of the product is determined by both.

Difference between Builder and Abstract Factory

The Builder pattern is somewhat similar to the Abstract Factory. This pattern extends the abstract factory with the director object which makes the design more flexible. Some initialization is often associated to the building process as well.

Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

Builder often builds a composite while Abstract Factory outputs a set of objects.

C++

This time the code is not included in the post due to it’s length. It’s available only through github.
Download C++ example

Python

Same as the C++ code. You can see it at github.
Download Python example

Sources

Advertisements

Design Patterns: Abstract Factory

I’m trying to keep up the tempo and do a pattern a day, so here goes another one! Today it’s abstract factory. I wrote a post about the factory method yesterday and this one (as you can guess) is somewhat similar.

What exactly is an abstract factory? It’s from the creational patterns group, so it controls object creation. The intent is to abstract creating whole families of objects without specifying concrete classes. We have a class called abstract factory that controls the creation. The class is abstract, because it has only virtual methods. This interface is later implemented by concrete factory classes. These object factories then creates a matching set of objects under some circumstances.

Take this for instance, you have a certain set of objects, that works on Windows and a certain set of objects, that does the same job, but under Linux. In this case there will be two subclasses of the abstract factory class. One that will create objects for windows and the second one for Linux. At the runtime, you create an instance of either one, depending on what platform is the program running on and the factory will build the appropriate set of objects.

More in-depth explanation is here. I’m trying to focus at the code examples:

User Interface Example with Gimp

The code is not as straight-forward as the previous, I’ll try to explain it with some more detail. I used a picture of GIMP UI to illustrate better what I mean, but this has absolutely nothing to do with the GIMP’s code and how it’s implemented!

Gimp UI

Gimp User Interface Example

So take this for instance. Your task is to write user interface for a program. The interface design says, there will be three windows (like there are in gimp). Also, among the requirements, there is one that says your code has to work natively with both — KDE and Gnome desktop environments. Each of these is built on a different toolkit. KDE uses Qt, Gnome uses Gtk. So somewhere in your code, you’ll need to check, what environment is available and construct an object, that will work with the current environment. This is where the abstract factory comes handy.

You will encapsulate the creation of all the UI components (in this case the three windows) into the abstract factory. Abstract factory is a class, something like this:

class UIFactory
{
    virtual void Window* getToolboxWindow() = 0;
    virtual void Window* getMainWindow() = 0;
    virtual void Window* getLayersWindow() = 0;
};

It’s an abstract class — it says, “I can get you the user interface”, but it doesn’t say how or what exactly are you going to recieve. Then, for each case (in our example it’s Qt and Gtk), there will be a subclass that implements this abstract factory, saying “from me, you’re going to get Qt/Gtk windows”. Then in your program, you check what your environment is and create an instance of QtUIFactory or GtkUIFactory. At this point you can be sure, that all windows will be constructed with support of the correct environment.

C++

Here is the implementation of the above in C++.

class Window
{
    protected:
        int width;
        int height;
        std::string toolkit;
        std::string type;

        Window(std::string usedToolkit, std::string windowType)
            : toolkit(usedToolkit), type(windowType)
        {}

    public:
        std::string getToolkit();
        std::string getType();
};

class GtkToolboxWindow : public Window
{};

class GtkLayersWindow : public Window
{};

class GtkMainWindow : public Window
{};


class QtToolboxWindow : public Window
{};

class QtLayersWindow : public Window
{};

class QtMainWindow : public Window
{};

/* This is the abstract factory. */
class UIFactory
{
    public:
        virtual Window* getToolboxWindow() = 0;
        virtual Window* getLayersWindow() = 0;
        virtual Window* getMainWindow() = 0;

};

/* Factory for Gtk toolkit */
class GtkUIFactory : public UIFactory
{
    public:
        Window* getToolboxWindow()
        {
            return new GtkToolboxWindow();
        }

        Window* getLayersWindow()
        {
            return new GtkLayersWindow();
        }

        Window* getMainWindow()
        {
            return new GtkMainWindow();
        }
};

/* Factory for Qt toolkit */
class QtUIFactory : public UIFactory
{
    public:
        Window* getToolboxWindow()
        {
            return new QtToolboxWindow();
        }

        Window* getLayersWindow()
        {
            return new QtLayersWindow();
        }

        Window* getMainWindow()
        {
            return new QtMainWindow();
        }
};

int main()
{
    UIFactory* ui = 0;

    /* Check what environment is running
and create appropriate factory. */
    if (/* Gtk == */ true)
    {
        ui = new GtkUIFactory();
    }
    else
    {
        ui = new QtUIFactory();
    }

    /* Use the factory to build interface. */
    Window* toolbox = ui->getToolboxWindow();
    Window* layers = ui->getLayersWindow();
    Window* main = ui->getMainWindow();

    /* See what have we recieved. */
    std::cout << toolbox->getToolkit() << ":"
              << toolbox->getType() << std::endl;

    std::cout << layers->getToolkit() << ":"
              << layers->getType() << std::endl;

    std::cout << main->getToolkit() << ":"
              << main->getType() << std::endl;
}

The code has been shortened a little. The fully working source file is available, as per ushe at github.

Python

And here is the Python version.

class Window:
    __toolkit = ""
    __purpose = ""

    def __init__(self, toolkit, purpose):
        self.__toolkit = toolkit
        self.__purpose = purpose

    def getToolkit(self):
        return self.__toolkit

    def getType(self):
        return self.__purpose

class GtkToolboxWindow(Window):
    def __init__(self):
        Window.__init__(self, "Gtk", "ToolboxWindow")

class GtkLayersWindow(Window):
    def __init__(self):
        Window.__init__(self, "Gtk", "LayersWindow")

class GtkMainWindow(Window):
    def __init__(self):
        Window.__init__(self, "Gtk", "MainWindow")


class QtToolboxWindow(Window):
    def __init__(self):
        Window.__init__(self, "Qt", "ToolboxWindow")

class QtLayersWindow(Window):
    def __init__(self):
        Window.__init__(self, "Qt", "LayersWindow")

class QtMainWindow(Window):
    def __init__(self):
        Window.__init__(self, "Qt", "MainWindow")

# Abstract factory class
class UIFactory:
    def getToolboxWindow(self): pass
    def getLayersWindow(self): pass
    def getMainWindow(self): pass

class GtkUIFactory(UIFactory):
    def getToolboxWindow(self):
        return GtkToolboxWindow()

    def getLayersWindow(self):
        return GtkLayersWindow()

    def getMainWindow(self):
        return GtkMainWindow()

class QtUIFactory(UIFactory):
    def getToolboxWindow(self):
        return QtToolboxWindow()

    def getLayersWindow(self):
        return QtLayersWindow()

    def getMainWindow(self):
        return QtMainWindow()

if __name__ == "__main__":
    gnome = True
    kde   = not gnome

    # What environment is available?
    if gnome:
        ui = GtkUIFactory()
    elif kde:
        ui = QtUIFactory()

    # Build the UI
    toolbox = ui.getToolboxWindow()
    layers  = ui.getLayersWindow()
    main    = ui.getMainWindow()

    # Let's see what have we recieved
    print "%s:%s" % (toolbox.getToolkit(), toolbox.getType())
    print "%s:%s" % (layers.getToolkit(), layers.getType())
    print "%s:%s" % (main.getToolkit(), main.getType())

The whole thing at github.

Sources

Design Patterns: Factory Method

Another design pattern today! The second most common after the singleton is in my opinion factory method. It’s a creational design pattern, that’s useful while you need to control creation process of the objects a little more than by a constructor.

For instance you might want to decide what subclass to create at the runtime rather than while writing the code. Or you don’t care what subclass will be constructed. Factory method in some more advanced implementations also allows reusing old objects insead of always creating new instances. The factory method will give you an object when you request it, but the creation process is encapsulated. That encapsulation is enforced, and allows an object to be requested without inextricable coupling to the act of creation.

Detailed description of the design pattern can be found at sourcemaking.com. I’ll just throw in the code. In my examples, there’s a base class — a Cup and two subclasses RedCup and BlueCup. The base class has a factory method that will get you a cup of the color you like.

C++

class Cup
{
    public:
        Cup()
          : color("")
        {}

        std::string color;

        /* This is the factory method. */
        static Cup* getCup(std::string color);
};

class RedCup : public Cup
{
    public:
        RedCup()
        {
            color = "red";
        }
};

class BlueCup : public Cup
{
    public:
        BlueCup()
        {
            color = "blue";
        }
};

Cup* Cup::getCup(std::string color)
{
    if (color == "red")
        return new RedCup();
    else if (color == "blue")
        return new BlueCup();
    else
        return 0;
}

/* A little testing */
int main()
{
    /* Now we decide the type of the cup at
* runtime by the factory method argument */
    Cup* redCup = Cup::getCup("red");
    std::cout << redCup->color << std::endl;

    Cup* blueCup = Cup::getCup("blue");
    std::cout << blueCup->color << std::endl;
}

The whole source file is available on git.

Python

class Cup:
    color = ""

    # This is the factory method
    @staticmethod
    def getCup(cupColor):
        if (cupColor == "red"):
            return RedCup()
        elif (cupColor == "blue"):
            return BlueCup()
        else:
            return None

class RedCup(Cup):
    color = "red"

class BlueCup(Cup):
    color = "blue"

# A little testing
redCup = Cup.getCup("red")
print "%s(%s)" % (redCup.color, redCup.__class__.__name__)

blueCup = Cup.getCup("blue")
print "%s(%s)" % (blueCup.color, blueCup.__class__.__name__)

The whole source text is available on git.

Sources

Design Patterns: Singleton

Let’s start with something simple. Singleton is probably the most basic design pattern. When someone explains design patterns, you can be sure, that at some point he will mention this one — the singleton.

I won’t go through the whole theory, there are a way to many good sources, that explain singleton well already. I’ll just focus on the code. So, we want to have a single, one and only globally accessible instance of a certain class in our program. There are couple steps we need to do:

  • Have some place to store the instance — static variable.
  • Have some way of globally accessing the instance — static method.
  • Prevent any other way of instantiation the class — disable constructor.

C++

Implementation in C++ is pretty straight-forward. All the tasks mentioned above are easy to achieve with C++. Here is the code:

class Singleton
{
    private:
        /* Here will be the instance stored. */
        static Singleton* instance;

        /* Private constructor to prevent instantiation. */
        Singleton();

    public:
        /* Static access method. */
        static Singleton* getInstance();
};

/* Null, because instance will be initialized on demand. */
Singleton* Singleton::instance = 0;

Singleton* Singleton::getInstance()
{
    if (instance == 0)
    {
        instance = new Singleton();
    }

    return instance;
}

Singleton::Singleton()
{}

You can download the whole code here.

Python

In Python situation gets a little bit stickier, but it’s not that hard to produce a singleton class as well. The problem is, that there’s no such a thing as private constructor in Python. So, you need to find another way of preventing multiple instantiation of the class. This can be achieved by raising and exception in constructor which works good, but some might not consider that a good practice since exceptions should be use only for errors. Let’s have look at the code:

class Singleton:
    # Here will be the instance stored.
    __instance = None

    @staticmethod
    def getInstance():
        """ Static access method. """
        if Singleton.__instance == None:
            Singleton()
        return Singleton.__instance

    def __init__(self):
        """ Virtually private constructor. """
        if Singleton.__instance != None:
            raise Exception("This class is a singleton!")
        else:
            Singleton.__instance = self

Again, you can get the whole thing here.

Sources

Design Patterns

Another thing I’ve been avoiding for a long time is design patterns and their use in software development. Now it’s time to learn to use those things! What I intend to do is go through all of them and write an example implementation of each in C++ and Python. You’ll find links to respective posts here later.

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Patterns are often divided into three categories.

Creational Design Patterns

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. Creational design patterns are further categorized into Object-creational patterns and Class-creational patterns. Where, Object-creational patterns deal with Object creation and Class-creational deal with Class-instantiation.

Structural Design Patterns

Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities.

Behavioral Design Patterns

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.

Sources