I experienced this kind of aha moment, that emerged from several (apparently) independent topics I wrote about, a guest post from Miguel Raggi, and my work on three different recent projects. And I wanted to share this moment with you.

The common point between those sources is this: if throughout your development process, you think about Usage First, Implementation After, you will maximize your chances for:

• happy users,
• expressive code,
• faster development time.

The interesting thing is that “usage” and “implementation” have various meanings depending on the different stages in the development process. Let’s see 3 contexts where applying Usage First, Implementation After can bring the three above benefits.

The usage of the user

When thinking about usage, the first thing that comes to mind is how the user is using the application.

In this case, the principle of Usage First, Implementation After translates into the following guideline: decide about what’s best for the experience of the user, without thinking about how to implement the change in the application to achieve this user experience.

Granted, at the end of the day you will have to implement some features in the application to make this user experience tangible. But if you don’t think about the implementation during the reflexion about what would be great for the user, you are freeing your thinking from any limits. Pretend that anything is possible! This leaves room for more awesome ideas.

Only when you’ve decided what you want to do for the user, find a way to make it happen with the application. It’s only at this time that you should take into account the constraints of the existing system, the costs, etc. If necessary, you can always trade off 20% of user experience at this stage to make the development 80% cheaper.

The usage of the developer

Another usage that we think less about is the usage of the developer.

We don’t think about that first because the developer doesn’t use the app, and at first glance they don’t use the code either, they produce the code.

This view stands if the code is one atomic chunk that makes the application run, but it is not the case. The code is made of parts, many parts, and at many scales.

For example, the code of an application is often split into client and server, or front-end and back-end. And within any of those parts, there are modules, that can be composed of several sub-parts. And each piece of code in them is broken down into classes and functions, and so on.

All those are under the control of developers, and at each scale, there are usages: the client uses the services provided by the server, the front-end uses the API of the back-end, the modules uses one another, the internal code of the module uses the public interfaces of the classes, the functions use the prototypes of other functions.

All this is to illustrate that, from the perspective of any part of the code, there is a usage of another part of the code.

Write the call site first

The principle of Usage First, Implementation After applies very well in this context. In practice, it consists in writing the call site first.

Take the example of designing a function: imagine yourself in the middle of writing a piece of code, and you need an intermediary result in order to move on with the writing of your algorithm. You decide to write a function in charge of producing this intermediary result.

One  way to design that sub-function is to think about what it will need and what it will produce, and then write the function. And once the function is written, to call it from the piece of code you were writing initially.

But a better way to go is the other way around: pretend the sub-function already exists, and call it. This leaves you all the liberty to write the call site that suits you best, including a name for the function that fits seamlessly in that context.

This is a very powerful technique to write expressive code.

For more details and a step by step example of this approach of writing code, have a look at this excellent article from Miguel Raggi: How to Write Simple Code to Accomplish Complex Tasks.

The usage of the data

Another situation I found the principle of User First, Implementation Later come in handy is when you have a system where you input data, and that produces data in another form. In this case the principle makes the development process faster.

Renting boats

Let’s take an example to illustrate. Imagine you own a boat rental on the beautiful Lac d’Annecy, where tourists are pressing in the summer season. You rent boats to people for them to take a tour on the Lac, and you want people to be able to book their boat in advance on your website.

The busy days are on the weekends and national holidays, although there is some activity during weekdays in the summer too. The inputs you feed your system are:

• the specific times your rental is open, for each type of day (weekend, weekday, summer season, etc.),
• the available boats and their hourly prices.

People can then book a specific boat for any amount of time, ranging from 30 minutes to a full day.

All that is the data coming in your system. In output, you need an up-to-date view of the available boats on the available slots for each day, so that potential customers can see what’s available in order to book their boat.

Designing the system

There are at least two ways to design this system:

• in order following the workflow,
• or Usage First, Implementation later.

The natural order that would come up to (my) mind is to follow the workflow. The starting point is the data provided by the boat rental owner: the opening times and boats descriptions. It sound only logical to start by thinking about how to take the data in input and how to store it, keeping in mind it will be queried later to display available boats and slots.

I have found that a much faster way is to start designing the end of the system first: the Usage of the data.

Doing that consists in designing the querying and processing of the data as if the data was already present in database in the most convenient format. The nice thing is that this defines what the most convenient format is.

From there, we go back to the beginning of the process, to design how to store the input data in this convenient format.

I used this approach on a project I worked on recently (even though it wasn’t about boats on the Lac d’Annecy) and I was impressed how it resulted in a better design, and a much faster development time.

How you design software

We’ve seen three aspects of software development where the Usage First, Implementation Later principle brought expressive code, fast development and happy users.

Do you also follow this principle or something resembling it? Please let me know how in a comment below, I’d love to read about your experience.

What others principles do you use when designing software?

You will also like

• It all comes down to respecting levels of abstraction
• How to Design Function Parameters That Make Interfaces Easier to Use
• Great Developers Don’t Just Write Great Code
• Runtime Polymorphism Without Objects or Virtual Functions

The post Usage First, Implementation After: A Principle of Software Development appeared first on Fluent C++.

We’ll see the various forms the Factory method design pattern can take, the differences with the Abstract Factory method, and to which design principle the Factory method pattern relates to.

Design patterns and design principles

In case you’re just joining the series, let’s see what we call a design pattern and a design principle.

A design pattern is one of the patterns presented in the classic Gang of Four (GoF) book Design Patterns:

Design principles, on the other hand are more general guidelines to make design robust. The GRASP principles are 9 principles to assign responsibilities to components in code, and they are presented in Craig Larman’s Applying UML and Patterns book:

The 9 GRASP design principles are:

• Low Coupling
• High cohesion
• Creator
• Information expert
• Polymorphism
• Indirection
• Protected Variations
• Pure Fabrication
• Controller

Let’s analyse the GoF design pattern Factory method, and find out to which GRASP principle it relates most.

Factory method

To understand what factory method means, let’s analyse each of its two words:

• method: this means member function,
• factory: this means something that creates objects.

All this means that a factory method is a member function that creates objects.

It is important to note that this comes from a book on object oriented design (the GoF’s Design Patterns book) , that makes heavy use of member functions. But my understanding of the design pattern is that it applies beyond member functions. It applies to free functions too.

So a more generic and idiomatic name for this design pattern in C++ could be “Factory function”.

Factory member functions

The GoF book illustrates the Factory method pattern with a polymorphic member function that returns a polymorphic object. The example is (in essence and in more modern) something like this:

class X { /* ... */ };

class SomeTypeOfX : public X { /* ... */ };

class MyClass
{
public:
    // interface of MyClass...
    virtual std::unique_ptr<X> createX() const;
};

class MyDerivedClass : public MyClass
{
public:
    std::unique_ptr<X> createX() const override
    {
        return std::make_unique<SomeTypeOfX>();
    }
};

The Factory method here is createX. Its only role is to create an X (or an object behaving like an X) and it is the only place in the code that creates an X.

This example uses polymorphism in two places: the factory method is polymorphic, and the created object is polymorphic too. But I don’t think those are essential conditions for the design pattern. A non-polymorphic method could just as well be in charge of creating a non-polymorphic object too.

For this reason, I don’t think that Factory method, in its essence, relates to the Polymorphism design principle. Rather, I would relate it to Pure Fabrication. Indeed, it is convenient for cohesion to centralise the responsibility of creating an object in one member function, even if this function doesn’t represent an element of the domain of the application.

Factory free functions

To illustrate how Factory method can also be implemented with a free function, let’s see the common pattern of the factory function. Before learning design patterns, this is what I thought the generic name “factory” referred too.

Consider the case where we have a class hierarchy:

class Base { /* ... */ };

class Derived1 : public Base { /* ... */ };

class Derived2 : public Base { /* ... */ };

class Derived3 : public Base { /* ... */ };

And we only know at runtime the type of the object we need to create. This information is represented by an enum:

enum class Type
{
    Type1,
    Type2,
    Type3
};

(those are names to illustrate the concepts, in production code we wouldn’t use such names with no information!)

To create an object of the appropriate type, and let the rest of the code use it polymorphically through the Base interface, we can centralise the creation in one function:

std::unique_ptr<Base> createObject(Type type)
{
    switch (type)
    {
        case Type::Type1 :
            return std::make_unique<Derived1>();
        case Type::Type2 :
            return std::make_unique<Derived2>();
        case Type::Type3 :
        default:
            return std::make_unique<Derived3>();
    }
};

This falls under the Factory method design pattern too. And I would also relate this form to the Pure Fabrication principle, as it is a convenient way to centralise the responsibility of creating the object even if it doesn’t mirror a domain concept.

Why not Creator?

It would have sounded nice to relate the Factory method design pattern to the Creator design principle. Indeed, the sole role of the Factory method pattern is to create object (we saw that it didn’t relate to the Polymorphism principle).

However, the Creator principle is something else: it suggests that B should create A if B is going to interact with A, has input to create A, or is, more generally, close to A.

The Factory method is not close to the object it creates, in my view. Once it created it, the factory doesn’t necessarily continue to interact with the object.

The differences between Abstract Factory and Factory method

Abstract Factory and Factory method are two design patterns with the name “factory” in it, and they both describe patterns to create objects. The classical question is then: what is the difference between them?

I won’t describe how Abstract Factory works because it is a topic in itself and it is out of the scope of this article (it you’re not sure about how Abstract Factory works, check out the article dedicated to Abstract Factory).

Here are the differences I see between the two patterns:

• Abstract Factory creates several objects of the same family or brand, whereas Factory method only creates one.
• The essence of Abstract Factory is to provide Polymorphism in the creation of objects, whereas Factory method is only a Pure Fabrication to centralise the creation of an object.

Do you see other differences between the two patterns?

Do you agree with the attribution of Factory method to Pure Fabrication?

Do you often use design patterns and design principles in your code?

Leave a comment below.

You will also like

• Design Patterns VS Design Principles: Abstract Factory
• Minor, Major and Overarching Design Principles
• GRASP: 9 Must-Know Design Principles for Code
• Design Patterns VS Design Principles: Iterator, Mediator and Memento
• Design Patterns VS Design Principles: Template Method

The post Design Patterns VS Design Principles: Factory method appeared first on Fluent C++.

In short, if we keep the value as a reference then we can’t bind to temporary objects. And if we keep it as a value, we incur unnecessary copies when it is initialized from an lvalue.

What’s a C++ programmer to do?

There are several ways to cope with this situation. I find that using std::variant offers a good trade-off to have expressive code.

Keeping track of a value

Here is a more detailed explanation of the problem.

Consider a class MyClass. We would like to give MyClass access to a certain std::string. How do we represent the string inside of MyClass?

We have two options:

• storing it as a reference,
• storing it as a value.

Storing a reference

If we store it as a reference, for example a const reference:

class MyClass
{
public:
    explicit MyClass(std::string const& s) : s_(s) {}
    void print() const
    {
        std::cout << s_ << '\n';
    }
private:
    std::string const& s_;
};

Then we can initialize our reference with an lvalue:

std::string s = "hello";
MyClass myObject{s};
myObject.print();

This code prints out:

hello

All good. But what if we want to initialize our object with an rvalue? For example with this code:

MyClass myObject{std::string{"hello"}};
myObject.print();

Or with this code:

std::string getString(); // function declaration returning by value

MyClass myObject{getString()};
myObject.print();

Then the code has undefined behaviour. Indeed, the temporary string object is destroyed on the same statement it is created. When we call print, the string has already been destroyed and using it is illegal and leads to undefined behaviour.

Really?

To illustrate this, if we replace std::string with a type X where we log in the destructor:

struct X
{
    ~X() { std::cout << "X destroyed" << '\n';}
};

class MyClass
{
public:
    explicit MyClass(X const& x) : x_(x) {}
    void print() const
    {
        // using x_;
    }
private:
    X const& x_;
};

Let’s also add logging to the call site:

MyClass myObject(X{});
std::cout << "before print" << '\n';
myObject.print();

This program then prints (live code here):

X destroyed
before print

We can see that the object is destroyed before we attempt to use it.

Storing a value

The other option we have is to store a value. This allows us to use move semantics to move the incoming temporary into the stored value:

class MyClass
{
public:
    explicit MyClass(std::string s) : s_(std::move(s)) {}
    void print() const
    {
        std::cout << s_ << '\n';
    }
private:
    std::string s_;
};

Now with this call site:

MyClass myObject{std::string{"hello"}};
myObject.print();

We incur two moves (one to construct s and one to construct s_) and we don’t have undefined behaviour. Indeed, even if the temporary is destroyed, print uses the instance inside of the class.

Unfortunately, if we go back to our first call site, with an lvalue:

std::string s = "hello";
MyClass myObject{s};
myObject.print();

Then we’re no longer making two moves: we’re making one copy (to construct s) and one move (to construct s_).

What’s more, our purpose was to give MyClass access to the string, and if we make a copy we have a different instance than the one that came in. So they won’t be in sync.

With the temporary object it wasn’t a problem because it was to be destroyed anyway and we moved it in just before, so we still had access to “that” string. But by making a copy we no longer give MyClass access to the incoming string.

So using a value is not a good solution either.

Storing a variant

Storing a reference is not a good solution, and storing a value is not a good solution either. What we would like to do is to store a reference if the value is initialised from an lvalue, and store a value if it is stored from an rvalue.

But a data member can only be of one type: value or reference, right?

Well, with a std::variant, it can be either one.

However, if we try to store a reference in a variant, like this:

std::variant<std::string, std::string const&>

We get an compilation error expressed with a broken static assert:

variant must have no reference alternative

To achieve our purpose we need to put our reference inside of another type.

This means that we have to write specific code to handle our data member. If we write such code for std::string we won’t be able to use it for another type.

At this point it would be good to write the code in a generic way.

A generic storage class

The storage of our motivating case needed to be either a value or a reference. Since we’re writing this code for a general purpose now, we may as well allow non-const references too.

Since the variant cannot hold references directly, let’s store them into wrappers:

template<typename T>
struct NonConstReference
{
    T& value_;
    explicit NonConstReference(T& value) : value_(value){};
};

template<typename T>
struct ConstReference
{
    T const& value_;
    explicit ConstReference(T const& value) : value_(value){};
};

template<typename T>
struct Value
{
    T value_;
    explicit Value(T&& value) : value_(std::move(value)) {}
};

And let’s define our storage to be either one of those cases:

template<typename T>
using Storage = std::variant<Value<T>, ConstReference<T>, NonConstReference<T>>;

Now we need to give access to the underlying value of our variant, by providing a reference. We create two types of access: one const and one not const.

Defining const access

To define const access, we need to make each of the three possible type inside of the variant produce a const reference.

To access data inside the variant, we’ll use std::visit and the canonical overload pattern, which can be implemented in C++17 the following way:

template<typename... Functions>
struct overload : Functions...
{
    using Functions::operator()...;
    overload(Functions... functions) : Functions(functions)... {}
};

To get our const reference, we can just create one for each case of the variant:

template<typename T>
T const& getConstReference(Storage<T> const& storage)
{
    return std::visit(
        overload(
            [](Value<T> const& value) -> T const&             { return value.value_; },
            [](NonConstReference<T> const& value) -> T const& { return value.value_; },
            [](ConstReference<T> const& value) -> T const&    { return value.value_; }
        ),
        storage
    );
}

Defining non-const access

The creation of a non const reference uses the same technique, except that if is variant is a ConstReference, it can’t produce a non-const reference. However, when we std::visit a variant, we have to write code for each of its possible types:

template<typename T>
T& getReference(Storage<T>& storage)
{
    return std::visit(
        overload(
            [](Value<T>& value) -> T&             { return value.value_; },
            [](NonConstReference<T>& value) -> T& { return value.value_; },
            [](ConstReference<T>& ) -> T&.        { /* code handling the error! */ }
        ),
        storage
    );
}

We should never end up in that situation, but we still have to write some code for it. The first idea that comes to (my) mind is to throw an exception:

struct NonConstReferenceFromReference : public std::runtime_error
{
    explicit NonConstReferenceFromReference(std::string const& what) : std::runtime_error{what} {}
};

template<typename T>
T& getReference(Storage<T>& storage)
{
    return std::visit(
        overload(
            [](Value<T>& value) -> T&             { return value.value_; },
            [](NonConstReference<T>& value) -> T& { return value.value_; },
            [](ConstReference<T>& ) -> T& { throw NonConstReferenceFromReference{"Cannot get a non const reference from a const reference"} ; }
        ),
        storage
    );
}

If you have other suggestions, I’d love to hear them!

Creating the storage

Now that we have defined our storage class, let’s use it in our motivating case to give access to the incoming std::string regardless of its value category:

class MyClass
{
public:
    explicit MyClass(std::string& value) :       storage_(NonConstReference(value)){}
    explicit MyClass(std::string const& value) : storage_(ConstReference(value)){}
    explicit MyClass(std::string&& value) :      storage_(Value(std::move(value))){}

    void print() const
    {
        std::cout << getConstReference(storage_) << '\n';
    }

private:
    Storage<std::string> storage_;
};

Consider the first call site, with an lvalue:

std::string s = "hello";
MyClass myObject{s};
myObject.print();

It matches the first constructor, and creates a NonConstReference inside of the storage member. The non-const reference is converted into a const reference when the print function calls getConstReference.

Now consider the second call site, with the temporary value:

MyClass myObject{std::string{"hello"}};
myObject.print();

This one matches the third constructor, and moves the value inside of the storage. getConstReference then returns a const reference to that value to the print function.

The evolution of the standard library

std::variant offers a very adapted solution to the classical problem of keeping track of either an lvalue or an rvalue in C++.

The code of this technique is expressive because std::variant allows to express something that is very close to our intention: “depending on the context, the object could be either this or that”. In our case, “this” and “that” are a “reference” or a “value”.

Before C++17 and std::variant, solving that problem was tricky and led to code that was difficult to write correctly. With the language evolving, the standard library gets more powerful and lets us express our intentions with more and more expressive code.

We will see other ways in which the evolution of the standard library helps us write more expressive code in a future article. Stay tuned!

You will also like

• How to Write Simple Code to Accomplish Complex Tasks
• How C++17 Benefits from Boost Libraries
• Overview of std::map’s Insertion / Emplacement Methods in C++17
• 3 Simple C++17 Features That Will Make Your Code Simpler

The post How to Store an lvalue or an rvalue in the Same Object appeared first on Fluent C++.

The temptation is then to warm up very specific muscles of our left hand:

• the pinky muscles that will press on the Ctrl key,
• the index finger muscles to press on the C key
• whatever muscles on the right-hand side of our index figer that will move it over the V key.

In other words, we prepare ourselves for a copy-paste development. That is, we find something in the application that is similar to what we want to add, copy-paste it, and change the small bits that are specific to our new feature.

Although the nervous and muscular biological sequence behind a copy-paste is beautiful, there is another beautiful nervous element we can use: our brain.

Indeed, even in copy-paste development, injecting a bit of understanding can reap a lot of benefits, both for our satisfaction and for the quality of our code.

Copy-paste developments

First let’s agree on what we call copy-paste developments. I’m assuming that you follow the DRY (Don’t Repeat Yourself) principle, that is trying to avoid code duplication, at least when this is reasonable.

So copy-pasting is not your default approach. But in some developments, where the feature you’re adding is similar to many existing features that are all copy-pasted from one another, it can be difficult not to copy-paste your new one into existence.

For example, you’re asked to add a new field in a dictionary of existing fields. Or a new value in a report. Or a new field in an XML that is produced by your application.

And you’re not very familiar with the framework of that dictionary, or with that reporting module, or that XML library.

Fortunately, there are many fields in the dictionary, many values in the report, or many fields in the XML, and they all kind of look alike, except for some specific bits to each field.

Have you ever been asked to do such a development?

The temptation can be to just copy-paste, ignore what you don’t really understand, modify the specific part for your new field, and call it a day.

But there is a better way.

The need to understand

We generally don’t see those developments as very interesting or rewarding. But there is one thing we can do to make them more interesting and turn them into learning opportunities: understanding the code we’re copy-pasting.

Of course, not having to copy-paste any code because the framework you’re working in is very well designed is the ideal situation. But if you’re working with existing code, sometimes you don’t choose the quality of the code, or at least the quality it has when you start working with it.

But the least we can do is to understand the code we’re copy-pasting.

Here are several benefits this can bring.

Dead code

One reason to understand what you’re copy-pasting is that perhaps part of it is not necessary for your specific feature.

This has happened to me in a recent development, and realising it saved me from introducing a substantial amount of code inspired from another feature. The most amusing part is that I realised that this other feature I took as a model didn’t need that part too!

Introducing useless code is sad. It makes the code less expressive because there is more to read and understand for the next person. And we don’t get anything for it, because it’s useless.

Understanding what you’re copy-pasting, even if it’s a vague understanding about what each part is used for, can make your code simpler and more expressive.

You’ll need to understand it anyway

In general, when you add a new feature in legacy code, does it work the first time after you’ve compiled it and run the application?

Sometimes it does. But sometimes, we need to adjust the code to make it work and cover all cases. If we don’t understand how the code works, we’re crippled to solve its issues and make our new feature work.

The worst situation is when we think it works, and a bug is discovered later. Then we need to get back to the unfamiliar copy-pasted code and figure it out. And if the bug is urgent to fix because it has been uncovered late in the process… this is not a situation we want to be in, is it?

Since we’re likely going to figure out the code at some point anyway, let’s do it at the beginning and write the code as correctly as possible as early in the process as possible.

Extending your known scope

Taking the time to understand a new framework or module expands your knowledge, and in software engineering, and in legacy code in particular, Knowledge is Power.

For a lot more details about this, you can check out chapter 7 of The Legacy Code Programmer’s Toolbox.

Intellectual interest

A lot of us became developers because they enjoy the intellectual challenge in it. But copy-pasting is a pretty dumb activity.

Personally, the part of programming that I enjoy most is understanding how existing systems work. Even understanding how copy-pasted code work brings me more satisfaction than copy-pasting mysterious code and hoping for it to work.

Is this the same for you? What part of your job do you enjoy the most? Let me know in the comments section!

I wouldn’t presume of what brings you intellectual satisfaction in your job as a programmer, but I’d love to know if understanding systems bring you joy too.

Not copy-pasting

If you understand the code you’re copy-pasting, you’ll more able to see a common pattern between the various features.

This can give you the tools to put some code in common and copy-paste less code to implement your feature, thus applying the DRY principle.

At some point you may even be knowledgable enough about the patterns used by the framework you’re inserting your code in to refactor the framework itself, in a separate development.

This is great exercise, both in detecting abstractions in code and in formulating new ones. This is fundamental, as programming all comes down to respecting levels of abstraction.

Don’t let your fingers muscles do all the work

Do copy-paste developments sound familiar?

When you have to do one, do you invest the time and effort to understand the copy-pasted code?

If you don’t, next time you have to do a copy-paste development, why not use your full brain power to understand the code you’re copy-pasting, and see what the benefits this can bring you?

Share your experience in the comments below!

You will also like

• You Should Refuse to Develop What You Don’t Understand
• To DRY or not to DRY?
• Dry-comparisons: A C++ Library to Shorten Redundant If Statements
• The Legacy Code Programmer’s Toolbox

The post Copy-Paste Developments appeared first on Fluent C++.

Let’s see how Abstract Factory works and what it is useful for, then relate it to a design principle. We will also see a C++ technique to implement Abstract Factory with classes nested in a function.

Design Patterns and Design Principles

What is the difference between design patterns and design principles?

The design patterns we talk about are the collection of patterns described in the popular GoF book:

Design patterns are typical ways to organise the components of a program in typical situations.

Design principles, on the other hand, are general guidelines te help create robust designs. The 9 GRASP principles are described in Craig Larman’s Applying UML and Patterns book:

The 9 GRASP design principles are:

• Low Coupling
• High cohesion
• Creator
• Information expert
• Polymorphism
• Indirection
• Protected Variations
• Pure Fabrication
• Controller

Let’s analyse the GoF design pattern Abstract Factory, and decide to which GRASP principle it relates the most.

What Abstract Factory is useful for

The goal of the Abstract Factory pattern is to make sure that objects are created consistently with each other.

This need arises when several objects can be created in a context, and there are several ways to create those objects. The GoF books uses the term of “family”: there are several families of objects. You can also see it as if there were several brands of objects, and in a given context you want all objects to be created of the same brand.

To do that, the Abstract Factory pattern consists in assigning to one class the responsibility of creating all the objects of a given family or brand.

Concrete factories

Let’s illustrate with a simple example, with an Abstract Factory that builds the parts of a house. In practice, the objects we create in code are more abstract (I’ve used Abstract Factory to create objects related to transactions for example), but let’s use this simple example to illustrate the structure of the pattern.

The objects we want to create are a door, a roof and a wall. There are several types of houses: blue houses, red houses, and yellow houses. And there may be more of them.

When we build a blue house, we want to make sure that all its components are blue. If we were to instantiate each object separately, each time there would be a risk of not instantiating the right type.

To mitigate that risk, we instantiate only one object: the blue house factory. Then we only use this object to create the others. This means that if we get the right factory, we’re guaranteed to get all the components of the right color too.

BlueHouseFactory
{
    Door createDoor() const; // this returns a blue door
    Roof createRoof() const; // this returns a blue roof
    Wall createWall() const; // this returns a blue wall
};

Note that this is a simple factory that doesn’t use polymorphism on the objects it creates (Door, etc.). Indeed, there could also be polymorphism in the objects that the factory creates:

class BlueHouseFactory
{
public:
    std::unique_ptr<Door> createDoor() const; // this returns a blue door
    std::unique_ptr<Roof> createRoof() const; // this returns a blue roof
    std::unique_ptr<Wall> createWall() const; // this returns a blue wall
};

With subclasses for each object:

class BlueDoor : public Door
{
    // ...
};

And the code for createDoor would then look like this:

std::unique_ptr<Door> BlueHouseFactory::createDoor()
{
    return std::make_unique<BlueDoor>();
}

Abstract Factory

Now we have one factory, that creates blue components. We go on and introduce other factories, that create other types of components: the RedHouseFactory and the YellowHouseFactory.

The goal is to use only one factory in a given context. To do that, we introduce an abstract factory, that can be either one of the above factories:

class HouseFactory
{
public:
    virtual std::unique_ptr<Door> createDoor() const = 0;
    virtual std::unique_ptr<Roof> createRoof() const = 0;
    virtual std::unique_ptr<Wall> createWall() const = 0;
    virtual ~HouseFactory() = 0;
};

The concrete factories then implement this interface:

class BlueHouseFactory : public HouseFactory
{
public:
    std::unique_ptr<Door> createDoor() const override; // this returns a blue door
    std::unique_ptr<Roof> createRoof() const override; // this returns a blue roof
    std::unique_ptr<Wall> createWall() const override; // this returns a blue wall
};

class RedHouseFactory : public HouseFactory
{
public:
    std::unique_ptr<Door> createDoor() const override; // this returns a red door
    std::unique_ptr<Roof> createRoof() const override; // this returns a red roof
    std::unique_ptr<Wall> createWall() const override; // this returns a red wall
};

class YellowHouseFactory : public HouseFactory
{
public:
    std::unique_ptr<Door> createDoor() const override; // this returns a yellow door
    std::unique_ptr<Roof> createRoof() const override; // this returns a yellow roof
    std::unique_ptr<Wall> createWall() const override; // this returns a yellow wall
};

Creating the factory

The factory is made to create objects, but who creates the factory?

There are various ways to do that. One of them is to instantiate various concrete factories in various places of the code, depending on the context. Given a function that uses a factory:

House buildAHouse(HouseFactory const& houseFactory);

We could call this fonction with a concrete factory if we know which one to use:

auto const blueHouse = buildAHouse(BlueHouseFactory{});

Another option is to centralise the creation of the factory, in a function (that happens to follow another design pattern, Factory Method, which we’ll explore in another post):

std::unique_ptr<HouseFactory> createHouseFactory(Color color)
{
    switch (color)
    {
        case Color::Blue:
        {
            return std::unique_ptr<BlueHouseFactory>{};
            break;
        }
        case Color::Red:
        {
            return std::unique_ptr<RedHouseFactory>{};
            break;
        }
        case Color::Yellow:
        default:
        {
            return std::unique_ptr<YellowHouseFactory>{};
            break;
        }
    }
}

This has the drawback of having to deal with the default case (Should we have a default color as in the above code? Should we produce an error? Or return a nullptr that we test everywhere?).

If you centralise the creation of the factory, know that C++ gives you the option to centralise the definitions of the factories along with them, by using classes nested in a function:

std::unique_ptr<HouseFactory> createHouseFactory(Color color)
{
    switch (color)
    {
        case Color::Blue:
        {
            class BlueHouseFactory : public HouseFactory
            {
            public:
                std::unique_ptr<Door> createDoor() const override { return std::make_unique<BlueDoor>(); };
                std::unique_ptr<Roof> createRoof() const override { return std::make_unique<BlueRoof>(); };
                std::unique_ptr<Wall> createWall() const override { return std::make_unique<BlueWall>(); };
            };

            return std::unique_ptr<BlueHouseFactory>{};
            break;
        }

        case Color::Red:
        {
            class RedHouseFactory : public HouseFactory
            {
            public:
                std::unique_ptr<Door> createDoor() const override { return std::make_unique<RedDoor>(); };
                std::unique_ptr<Roof> createRoof() const override { return std::make_unique<RedRoof>(); };
                std::unique_ptr<Wall> createWall() const override { return std::make_unique<RedWall>(); };
            };

            return std::unique_ptr<RedHouseFactory>{};
            break;
        }

        case Color::Yellow:
        default:
        {
            class YellowHouseFactory : public HouseFactory
            {
            public:
                std::unique_ptr<Door> createDoor() const override { return std::make_unique<YellowDoor>(); };
                std::unique_ptr<Roof> createRoof() const override { return std::make_unique<YellowRoof>(); };
                std::unique_ptr<Wall> createWall() const override { return std::make_unique<YellowWall>(); };
            };

            return std::unique_ptr<YellowHouseFactory>{};
            break;
        }
    }
}

An advantage of this is that all the factory code is located together, and you’re guaranteed that no other code can instantiate a BlueHouseFactory, because they don’t have access to that class.

But as a drawback, it makes the factory creation fonction bigger. If the implementations of the factories are not very simple, this makes the code hard to follow.

Design principles

The role of Abstract Factory is to present an interface for creating objects, that is implemented by various concrete factories. For this reason, I think Abstract Factory implements the Polymorphism GRASP design principle.

Also, the factory often doesn’t model a domain object. It is a technical helper to centralise the creation of consistent objects. This also makes it a Pure Fabrication.

Doesn’t Abstract Factory also implement the Creator GRASP design principle? Given its name, this is what I would have thought before digging in the analysis.

But if we go back to the definition of Creator, it suggests that B should create A if B is close to A: if it uses A, if it has inputs to create A, if it already contains other instances of A, etc. This does not match the description of Abstract Factory as well as Polymorphism does.

Would you also have reacted Abstract Factory to Polymorphism and Pure Fabrication, or to another one?

Do you know of creational patterns that are not in the GoF book?

Let me know by leaving a comment below.

You will also like

• Minor, Major and Overarching Design Principles
• GRASP: 9 Must-Know Design Principles for Code
• esign Patterns VS Design Principles: Chain of responsibility, Command and Interpreter
• Design Patterns VS Design Principles: Iterator, Mediator and Memento
• Design Patterns VS Design Principles: Observer, State and Strategy

The post Design Patterns VS Design Principles: Abstract Factory appeared first on Fluent C++.

This is called a “Cartesian product”.

For example, this kind of operation is necessary in the cartesian_product range adaptor, in the cartesian_product pipe, and in the killer feature of verifyAllCombinations in the ApprovalTest.cpp library, to cite just a few.

The most basic usage of a Cartesian product looks like this:

auto const inputs1 = std::vector<int> {1, 2, 3};
auto const inputs2 = std::vector<std::string>{"up", "down"};
auto const inputs3 = std::vector<std::string>{"blue", "red"};

cartesian_product(displayCombination,
                  inputs1,
                  inputs2,
                  inputs3);

Where displayCombination is a function that takes one element from each collection:

void displayCombination(int input1, std::string const& input2, std::string const& input3)
{
    std::cout << input1 << '-' << input2 << '-' << input3 << '\n';
}

The above code generates all the possible combinations of the elements coming from the three input collections and sends each combination to displayCombination. The output of this program is then:

1-up-blue
1-up-red
1-down-blue
1-down-red
2-up-blue
2-up-red
2-down-blue
2-down-red
3-up-blue
3-up-red
3-down-blue
3-down-red

A few days ago I published a blog post that suggested that you try and code it up yourself. It’s not too late to try! Indeed, implementing cartesian_product is a very instructive experiment.

Let’s see one way of implementing such a cartesian_product in C++.

The main loop

The main body of the cartesian_product function consists in iterating over all the combinations of the elements coming from the input ranges, and sending each of those combinations to the incoming function.

In pseudo-code, that loops looks like this:

template<typename Function, typename... Ranges>
void cartesian_product (Function function, Ranges const&... ranges)
{
    for(combination = first combination;
        we finished iterating;
        go to next combination)
    {
        call function on that combination
    }
}

Our goal is now to transform each of those bits of pseudo-code into real C++ code.

If there were only one collection, the above code would have used an iterator on that collection. To generalise from this, we can use a tuple of iterators: each element of the tuple contains an iterator to an element of one of the input ranges.

We then need to be able to:

• instantiate this tuple of iterators with the first combination,
• call the incoming function on the current combination
• make it advance to the next combination,
• identify when we’ve been over all the combinations.

By implementing those 4 steps, we’ll be able to flesh out the above pseudo-code into compiling C++ code.

Instantiating the first combination

The first combination is probably the easiest one to create: just take an iterator to the first element of each collection:

template<typename Function, typename... Ranges>
void cartesian_product (Function function, Ranges const&... ranges)
{
    auto const beginIterators = std::make_tuple(begin(ranges)...);

    for(auto combination = beginIterators;
        we finished iterating;
        go to next combination)
    {
        call function on that combination
    }
}

Calling the function on a combination

Now we have a tuple of iterators that represents a combination. But the incoming function doesn’t take iterators as parameters, much less a tuple of them.

We therefore need to do two things: break up the tuple in individual elements, and dereference each of those elements.

We’ll do this in the opposite order: we will first create a tuple of references to the elements (as opposed to iterators), then break up this tuple to send individual parameters to the incoming function.

Creating a tuple of references

Creating a tuple of references out of a tuple of iterators consists in applying a function (here, operator*) on each element. This sounds like a std::transform but for tuples.

To achieve that we can use one of our algorithm on tuples:

template<typename... Ts>
auto dereference(std::tuple<Ts...> const& tuple)
{
    return tuple_algos::transform(tuple, [](auto&& element) -> decltype(auto) { return *element; });
}

We need to be explicit about the return type of the lambda by using decltype(auto), because the default type would have returned a copy and not a reference to the element referenced by the iterator. For more about the difference between auto and decltype(auto), read item 3 of Effective Modern C++.

Breaking up a tuple into individual function parameters

Now that we have a tuple of references, we have to pass each of them as an argument to the incoming function.

This is exactly what std::apply does:

template<typename Function, typename... Ranges>
void cartesian_product (Function function, Ranges const&... ranges)
{
    auto const beginIterators = std::make_tuple(begin(ranges)...);

    for(auto combination = beginIterators;
        we finished iterating;
        go to next combination)
    {
        std::apply(function, dereference(combination));
    }
}

std::apply comes with C++17. If you don’t have access to C++17 yet, at the end of this post I will point you to adapted implementations of cartesian_product for C++11 and C++14.

We’re now left with the iteration itself.

Generating the next collection

If we have a given combination, what should the next one be?

The way that sounds the most natural to be it to iterate over combinations in a lexicographical order:

• 1) increment the last iterator until reaching the end of the last collection,
• 2) when we reach the end of the last collection, increment the iterator of the collection before last, and reset the iterator of the last collection to its beginning,
• 3) repeat the two previous steps, until reaching the end of the collection before last,
• then increment the iterators of the collection before the one that is before last,
• repeat the previous steps,
• and so on.

Let’s implement this recursive definition of the traversal of the collection.

To start, let’s implement the general step of incrementing the iterator of the I-th collection (the calling code with call this with I = N-1 to increment the last iterator, as in the algorithm described above):

template<size_t I, typename... Iterators>
void increment_iterator(std::tuple<Iterators...>& iterators,
                        std::tuple<Iterators...> const& beginIterators,
                        std::tuple<Iterators...> const& endIterators)
{
    auto& it = std::get<I>(iterators);
    auto const begin = std::get<I>(beginIterators);
    auto const end = std::get<I>(endIterators);
    
    ++it; // step 1) of the algorithm above
    
    if (it == end)
    {
        it = begin; // step 2) of the algorithm above
        increment_iterator<I - 1>::_(iterators, beginIterators, endIterators);  // step 3) of the algorithm above
    }
}

The comments in the above snippet are not to be kept in the code, they just indicate which lines of code correspond to the steps listed in the recursive algorithms we described earlier.

We then need to implement the final step of the algorithm: incrementing the iterator in the first collection.

To do that, we need to specialise the above template for I = 0, to just increment the first iterator.

This would be a partial specialisation of the template, because the Iterators... types would still be template parameters. But since we can’t partially specialise template functions, we need to do the usual trick of wrapping them as static function in a template struct.

The whole code of increment_iterator then becomes:

template<size_t I>
struct increment_iterator
{
    template<typename... Iterators>
    static void _(std::tuple<Iterators...>& iterators, std::tuple<Iterators...> const& beginIterators, std::tuple<Iterators...> const& endIterators)
    {
        auto& it = std::get<I>(iterators);
        auto const begin = std::get<I>(beginIterators);
        auto const end = std::get<I>(endIterators);
        
        ++it;
        
        if (it == end)
        {
            it = begin;
            increment_iterator<I - 1>::_(iterators, beginIterators, endIterators);
        }
    }
};

template<>
struct increment_iterator<0>
{
    template<typename... Iterators>
    static void _(std::tuple<Iterators...>& iterators, std::tuple<Iterators...> const&, std::tuple<Iterators...> const&)
    {
        auto& it = std::get<0>(iterators);
        
        ++it;
    }
};

We can now use increment_iterator to generate the next combination:

template<typename... Iterators>
void next_combination(std::tuple<Iterators...>& iterators,
                      std::tuple<Iterators...> const& beginIterators,
                      std::tuple<Iterators...> const& endIterators)
{
    constexpr auto N = sizeof...(Iterators);
    increment_iterator<N - 1>::_(iterators, beginIterators, endIterators);
}

Finally, we can use this in our main loop:

template<typename Function, typename... Ranges>
void cartesian_product (Function function, Ranges const&... ranges)
{
    auto const beginIterators = std::make_tuple(begin(ranges)...);
    auto const endIterators = std::make_tuple(end(ranges)...);

    for(auto combination = beginIterators;
        we finished iterating;
        next_combination(combination, beginIterators, endIterators))
    {
        std::apply(function, dereference(combination));
    }
}

This was the hardest part! The only step left is to know when to stop incrementing the iterators of the current combination.

Identifying the end of the combinations

Given our above way of going to the next permutation, we reach the last permutation when we reach the end of the first collection.

This make the stopping condition pretty simple:

template<typename Function, typename... Ranges>
void cartesian_product (Function function, Ranges const&... ranges)
{
    auto const beginIterators = std::make_tuple(begin(ranges)...);
    auto const endIterators = std::make_tuple(end(ranges)...);

    for(auto combination = beginIterators;
        std::get<0>(combination) != std::get<0>(endIterators);
        next_combination(combination, beginIterators, endIterators))
    {
        std::apply(function, dereference(combination));
    }
}

The case of en empty collection

There is at least one case that the above code does not cover: the case where there is an empty collection.

Indeed, with an empty collection, we should not dereference the iterator coming from that collection. What to do then?

Let’s go back to the need: what does it mean to generate all possible combinations of the elements of several collections when one if them is empty? It means: to do nothing at all!

For this reason, we can check that all collections contain data before starting the loop, in order to avoid dereferencing iterators that don’t reference data, which would make the application crash.

To do this we can use our any_of algorithm on tuple (while we’re at it, let’s also static_assert that there is more than one incoming range):

template<typename Function, typename... Ranges>
void cartesian_product (Function function, Ranges const&... ranges)
{
    static_assert(sizeof...(Ranges) > 0, "There should be at least one range in cartesian_product.");
    auto const hasEmptyRange = tuple_algos::any_of(std::forward_as_tuple(ranges...), [](auto&& range){ return range.size() == 0; });

    if (!hasEmptyRange)
    {
        auto const beginIterators = std::make_tuple(begin(ranges)...);
        auto const endIterators = std::make_tuple(end(ranges)...);
        
        for (auto combination = beginIterators; std::get<0>(combination) != std::get<0>(endIterators); next_combination(combination, beginIterators, endIterators))
        {
            std::apply(function, dereference(combination));
        }
    }
}

Here is all the code put together.

Not yet at the latest version of C++?

The above code uses several features of C++14 (auto in lambda parameters), and C++17 (std::apply).

If you’re still in the process of upgrading to the latest and greatest version of C++ but are not quite there yet (a lot of companies are like you!) then you can find a version of this code using only C++14, and one using only C++11 (thanks mika-fischer).

You will also like

• Understand ranges better with the new Cartesian Product adaptor
• Mux: Zip Without Tuples
• The Demux Pipe

The post How to Generate All the Combinations from Several Collections appeared first on Fluent C++.

For example, consider the three following collections:

auto const inputs1 = std::vector<int> {1, 2, 3};
auto const inputs2 = std::vector<std::string>{"up", "down"};
auto const inputs3 = std::vector<std::string>{"blue", "red"};

Then (2, up, blue) and (3, up, red) are two of the possible combinations of elements from those three collections.

In total, there are 3*2*2, that is 12 possible combinations.

If we apply the following function to each combination:

void displayCombination(int input1, std::string const& input2, std::string const& input3)
{
    std::cout << input1 << '-' << input2 << '-' << input3 << '\n';
}

Then we would expect an output looking like this:

1-up-blue
1-up-red
1-down-blue
1-down-red
2-up-blue
2-up-red
2-down-blue
2-down-red
3-up-blue
3-up-red
3-down-blue
3-down-red

Writing code that generates all those possible combinations is a very instructive exercise.

We’re going to see one way of achieving that in C++ but, since it’s instructive, I’d suggest that you give it a go first to benefit from the reflexion. You’ll have a chance to code it up right on this page, and in the next post we’ll see one possible solution.

The interface

We’d like to implement a Cartesian product that applies a function to each of the combinations of the elements coming from of an arbitrary number of collections.

A natural interface is to take the function as the first parameter, followed by a variadic pack of ranges:

template<typename Function, typename... Ranges>
void cartesian_product (Function function, Ranges const&... ranges)
{
    //...

There are as many parameters in function as the number of ranges in the variadic pack.

cartesian_product picks an element from each range of the pack and passes it to function.

Give it a try

If the requirement is clear, you can now try to implement it yourself!

Here is a playground with several test cases: a main one with a couple of ranges, and a few corner cases where one of the ranges is empty. In those last cases, we don’t expect the cartesian_product to generate any combination. Indeed, a combination has to take elements from all the input ranges.

Here is the playground:

Alternatively, you can use this Coliru link and keep your attempts for later reference.

In a couple of days I’ll share with you one possible way to implement cartesian_product. In the meantime, if you write expressive code that passes the above tests, I’d love to see it!

Please share it a Godbolt link in the comment section below.

Happy coding!

You will also like

• Code It Yourself: Merging Consecutive Elements in a C++ Collection
• Understand ranges better with the new Cartesian Product adaptor
• Mux: Zip Without Tuples
• How to Define a Variadic Number of Arguments of the Same Type

The post Code It Yourself: Generate All the Combinations from Several Collections appeared first on Fluent C++.

Error handling is a tricky part of software programming.

It’s tricky in several aspects: it’s difficult to get right, and it can make code less expressive.

But it doesn’t always have to be that way. Sometimes asking the question “how can we prevent the error from happening in the first place?” can avoid the need for error handling altogether.

Why handling errors is difficult

Several things make error handling in code difficult.

We haven’t got the right tool yet

If you look back on the history of C++, the number of tools for errors handling has been growing at a steady pace.

C used error numbers returned from a function to indicate whether an operation succeeded, and give an error ID to identify the reason why it failed.

C also provided errno, a global indicator for an error number qualifying the last error that happened.

C++ came with exceptions, which allow to exit a function early if it can’t react to an error.

C++11’s error_code improved on the concept of error codes.

C++17 brought std::optional into the standard, allowing a function to return nothing in the case it failed to return what it was supposed to. This makes function interfaces more expressive.

C++20 almost had contracts (but they were taken out at the last moment). Contracts are a way to handle errors by checking the pre-conditions and post-conditions of an operation.

Looking back on this historical perspective, at any given point in time, better tools to handle errors were to be added in the future. So we never had optimal tools to handle errors.

It’s no different now. If we take a peek at what the future might hold for us in terms of error handling tools, there are at least two things.

First, Boost Outcome could well make it into a future version of the standard. Boost Outcome is a bit like std::optional in that it allows a function not to return its result if it’s not able to. But contrary to std::optional, Outcome embeds some information about what went wrong during the operation.

expected, which is in the same spirit as Boost Outcome, has been proposed to the C++ standard.

Another component that could make it in the standard are static exceptions, which have been pushed forward by Herb Sutter. Herb talked about error handling and static exceptions in his ACCU 2019 keynote.

If you’d like to see a more detailed overview of C++ errors handling tools than this quick overview, Phil Nash made a good job of listing and comparing error handling strategies in his C++Now 2018 talk.

The point is, there are many tools to handle errors in C++, and more to come, and until we’re at the final version of C++, we will probably have to wait more to get yet a better tool to handle errors.

The current tools are difficult to use correctly

If we look back on the first error handling tools, such as error codes, they were quite difficult to use correctly. We couldn’t make sure the caller checked them at all, and if they checked them, they needed to be very careful not to mix up the error codes.

Exceptions made it impossible for their caller to ignore them, and made the qualification of the error more explicit. But they came with their constraints, in particular having exception safe code.

Making code exception safe is a good thing in itself, as exception safe code tends to have a better design. But there are lots of not-exception-safe code out there, which makes it difficult to use exceptions.

The more recent tools don’t have those issues, but whatever the tool we use to handle errors, we still need to write code to deal with them. This is code that is not in the “happy path”, which is the code that gets executed when no error is happening.

When we think about coding up a feature, we (or at least, myself) tend to think about the happy path. Whatever the tool we use, handling errors adds more complexity to the code, and makes it by itself more difficult to understand and creates potential sources for incorrect behaviour.

Preventing errors from happening in the first place

Another approach when designing a software solution for a problem is to prevent errors from happening in the first place.

When we struggle with handling errors in code, we can simply ask ourselves: “can we prevent this error from happening in the first place?”

The very fact of thinking about this possibility opens a range of solutions that we don’t explore when we focus on choosing between using exceptions or std::optional.

One way to prevent errors from happening is by working on the user interface. In an application with a GUI, we can make small fixes that make certain combinations of configuration impossible to set up.

When the user chooses a certain option in the GUI, we can make the components react to that action. For example, we can open a modal window to force the user to go all the way through a series of choices or cancel that first option altogether. Or we can hide or disable some components to prevent the user from selecting inconsistent options.

I’m no UX expert, but several times a simple fix in the UI avoided us to put cumbersome error handling in our code. And it’s better for the user too: if no error happens, the user doesn’t get to see annoying error messages. The user is guided by the UI to make sure they stay in the “happy path”.

This has the advantage of making the user aware of what the happy path is. I’ve seen once an application was silently falling back on the happy path when the user selected a configuration the application wasn’t supporting. Even if this led to the application producing a “happy path” result, it silently fell back on a behaviour that the user didn’t ask for. This doesn’t look like a good solution overall.

I’m not saying that all errors can be handled by constraining the user interface. But some can, and every time it starts by asking the question “can we prevent this error from happening in the first place?”

Does your team usually think about this question? How do you prevent errors from happening in the first place?

You will also like

• A Concise Implementation of Fizzbuzz with std::optional
• Clearer interfaces with optional<T>
• Extract Function: Should I Extract the Condition Too?
• How to Make If Statements More Understandable

The post A Good Way to Handle Errors Is To Prevent Them from Happening in the First Place appeared first on Fluent C++.

The GoF meets the GRASP

If you’re just joining the series, The GoF meets the GRASP is about relating each of the GoF design patterns with one of the 9 GRASP design principles.

GoF design patterns are the 23 patterns in the hugely popular Design Patterns book:

GRASP design principles are higher level principles that are explained in Craig Larman’s Applying UML and Patterns:

The 9 GRASP design principles are:

• Low Coupling
• High cohesion
• Creator
• Information expert
• Polymorphism
• Indirection
• Protected Variations
• Pure Fabrication
• Controller

Let’s analyse the GoF design pattern Visitor, and decide to which GRASP principle it relates the most.

Visitor

In short, the Visitor design pattern consists in separating objects from operations into two separate class hierarchies.

In more details, consider a set of classes representing objects:

Those objects have operations X, Y and Z. Those operations share the same semantics, but not the same implementation. Put another way, each class has a specific way to accomplish X, a specific way to accomplish Y, and a specific way to accomplish Z:

The Visitor design pattern consists in refactoring this design by dedicating specific classes to X, Y and Z:

Seen this way, Visitor allows to create High Cohesion. Indeed, without Visitor, class A was concerned about X, Y and Z. With Visitor, there is a class X of which the sole responsibility is to perform the operation X.

Note that even if Visitor is a way to achieve High Cohesion, I don’t think that Visitor is a Pure Fabrication. Indeed, operations such as X, Y and Z can map to operations of the domain that the code is modelling.

But what about the visit() method?

If you’ve ever read a description of the Visitor design pattern, chances are that it drew attention on the visit and accept methods.

In the above description, they don’t appear once. Why?

I think that they are just one way to implement Visitor as described, and they are not part of the essence of the pattern.

Just in case you haven’t come across the visit and accept method, here is how they work. First, they require you to put the code of the operations as methods of the corresponding classes:

Second, they require to have an interface above each of the two groups of classes. Those interfaces contain the visit and accept methods:

Notes: Object and Operation are generic terms used here for the explanation. In practice, they would carry domain names. In the example, operation is const and object is not, but that could be different in practice too. And the operations return void, but they could also return something.

Then the visit and accept methods play a ping pong game in order to reach the implementation of the correct operation on the correct class. Here is how it works:

The user has an Object& object reference and a Operation const& operation reference. The user calls visit on the operation by passing the object:

operation.visit(object);

The implementation of visit looks like this:

void Operation::visit(Object& object) const
{
    object.accept(*this);
}

This calls the virtual method accept on the object hierarchy, which goes into one of the concrete implementation (not on the above diagram for simplicity). Say that the concrete type of the Object is A. The execution goes into:

void A::accept(Operation const& operation)
{
    operation.operateOnA(*this);
}

The object A passes the ball back to the operation hierarchy, calling the virtual method operateOnA (the fact that it’s virtual is omitted from the above diagram for simplicity). This leads to the concrete implementation of operateOnA in the concrete operation.

Say that the concrete operation is X. Then the execution goes to:

void X::operateOnA(A& a)
{
    // actual operation, the code that used
    // to be in doX() of class A,
    // at the beginning of the article.
}

The execution was sent from the operation to the object, and back to the operation. Why?

An emulation of double dispatch

That table tennis exchange comes from the fact that in C++, like in many languages, we can only resolve virtual calls on one type at the same time.

It would have been ideal to be able to write code like this:

void perform(Operation const& operation, Object& object);

perform(operation, object);

And that would have called one of nine functions taking each possible combination of (A,B,C) with (X,Y,Z). This is called runtime double-dispatch. Some languages do that (Smalltalk, I think?) but C++ doesn’t.

Therefore, we have to resolve one polymorphic interface at a time. First the Object interface in the visit method, then the Operation interface in the accept method.

In fact, there is a way to emulate this in C++, relying on std::map and std::type_info, that Scott Meyers explains in detail in Item 31 of More Effective C++. Check out the book for more details about that.

Note though that C++ has compile-time multiple-dispatch, a.k.a function overloading, that could be used to implement the Visitor design pattern, without visit and accept, and even without the Object and Operation interfaces.

But to use it, we need to know the concrete types of the object and the operation at compile time.

If the last two sentences didn’t make sense, that’s all right. It’s outside of the scope of this post, and we’ll get back to it in detail in articles dedicated to polymorphism.

std::variant‘s visitor

There is yet another implementation of the Visitor design pattern in the C++ standard library, in C++17, with std::variant. The standard library even offers a function called std::visit.

You can pass it an object that can be called on each type of the variant, along with the variant itself:

auto const object = std::variant<int, std::string, double>{"forty-two"};

auto const x = [](auto const& object){ std::cout << object << '\n'; };

std::visit(x, object);

This code displays:

forty-two

For more forms of operations, check out the reference page of std::visit.

The variant type plays the role of the Object interface, and the lambda plays the role of one of the operations.

So this is like half a Visitor. Indeed, there can be several types of objects, but only one type of operation. There is no polymorphism on the operation side. Only on the object side.

Various levels of polymorphism

In the Visitor design pattern, the various polymorphisms are just ways to implement the pattern. Its essence is rather to create High Cohesion by separating objects from operations.

The various types of polymorphism only make Visitor more or less generic:

In its rawest expression, the Visitor design pattern could separate one operation from one class, and have no interface nor polymorphism in place.

A more elaborate form is to have one operation on several types of objects. Then we need some sort of polymorphism in place. If you only need polymorphism on the object side and you know the set of possible types of objects, you don’t need more than a std::variant. Otherwise you need virtual functions in one hierarchy.

Now if you have several types of objects and several types of operations, you need a double polymorphism, which is commonly called double-dispatch. If you know the types at compile time you can use function overloading.

If you don’t know the types at compile time, you have to resort to the full-fledged construction of visit and accept that is commonly presented for the Visitor pattern, or use the C++-y solution in Item 31 of More Effective C++.

You will also like

• Design Patterns VS Design Principles: Chain of responsibility, Command and Interpreter
• Design Patterns VS Design Principles: Iterator, Mediator and Memento
• Design Patterns VS Design Principles: Observer, State and Strategy
• Design Patterns VS Design Principles: Template Method

The post Design Patterns VS Design Principles: Visitor appeared first on Fluent C++.

This is exactly what I want you to do. Rather than pouring down my opinions, my point is to ignite a debate with you on how to use programming paradigms to write expressive code.

In fact, as you’ll see, I will largely quote the opinions of some other people I had the chance to watch or talk to. There is no right or wrong answer so please, let us hear your opinion too! End of warning

In her closing keynote of Polyconf 2017, Anjana Vakil classifies programming paradigms into 4:

• the imperative paradigm: the program consists in a structured set of instructions for the computer to execute,
• the object-oriented paradigm: the program consists in objects that send messages to each other,
• the functional paradigm: the program consists in functions that call each other,
• the declarative paradigm: the program consists in statements that describe the intention of the programmer.

They roughly correspond to overlapping periods in the history of computer programming.

Some languages fall into one of those paradigms. For instance, Haskell is totally in the functional programming paradigm, whereas SmallTalk is in the object-oriented one. Some other languages, like C++ or Python, span across several programming paradigms.

So choosing a programming paradigm doesn’t always mean choosing a language. It can also be programming in your language with a certain programming style. As Steve McConnell puts it, rather than programming in a language, you want to program into a language. This essentially means that we should strive to work around the capabilities of a language to implement what we think is the most adapted style possible.

So, what is the best paradigm to write expressive code in C++, or in any other language?

Functional is the new object-oriented

It’s funny to see how paradigms shape our view on programming.

Well, that’s essentially the definition of a paradigm after all, but it’s striking to dig writings from the past and see how the world of programming sometimes revolved around a unique concept.

Take for example the excellent article Arguments and Results from James Noble. This article was published in 1997 and, back then, the ultimate view on programming was to be object-oriented. The hype was then around Java, the OO part of C++, SmallTalk and the like.

In this article, James describes object methods as “protocols” and he writes:

a program’s protocols are the glue that binds its objects together

He also states that “Object’s protocols also known as interfaces are very important in object oriented design”, but the above quotation says a lot about what the emphasis was on at the time: objects.

The 90’s were the glory of the object-oriented paradigm, but today this is no longer quite true. Objects still have a large share in programs, but today the functional programming paradigm is becoming increasingly popular.

We’ve seen functional languages, such as Haskell, that had lived in the academic field for decades, burst out to the public attention over the past few years. So much so that some universities that I know (EPITECH in Paris) require their students to hand in some of the assignments in Haskell.

Also, the functional trend is seeping its way into mainstream languages, with Java 8 taking on streams and lambdas, and modern C++ also including lambdas and (hopefully, hopefully soon) range-like constructs.

What’s so good about functional programming?

One typical property of functional programming is that it forbids mutable state. In pure functional programming, variables don’t even exist. And in imperative and object-oriented programming, a lot of bugs come from a mutable state… that is not in the state it should be. This immutability property allows to get rid of a whole class of bugs, and is at least partly responsible for the success of functional programming.

Also, not having mutable state has another nice consequence: when reading code, you don’t have to maintain in your head the various states of the program. This makes the code that much easier to understand, and that much expressive.

Is object-oriented hopeless then?

Seduced by the modern trend of functional programming and its advantages, one may be tempted to think that the object-oriented paradigm is a steam engine of programming: it was convenient at the time we didn’t know better, but its most useful place now is in a museum.

But programming paradigms aren’t really like trains.

Rather, when a programming paradigm ousts another one there are two things we can do:

• find what the two paradigms have in common. This points us to even deeper programming concepts that outlive paradigms,

• search for useful ways to make them work together. After all, all paradigms had enough traction to change the world’s view on programming. There must be some of their specific aspects that are worth saving from the trash, right?

Let’s dig into those two aspects.

Modularity and its siblings don’t want to die

One of the big things about objects is that they expose an interface, that hides data and behaviour that stay confined to an implementation behind that interface. Then the other objects can evolve around that interfaces, without seeing the implementations.

This concept of exposing an interface has several facets:

• modularity and decoupling: interfaces create clear boundaries between the various objects interacting together and helps making them independent from one another. This makes the system more structured, and therefore easier to understand and change.

• encapsulation: the implementation being hidden from the clients of an object, changing it only goes so far as the internal boundary of that objects delimited by the interface.

• polymorphism: another possible change is to swap out an implementation of an interface for another. In object-oriented systems, this can even happen at runtime with virtual methods,

• levels of abstraction: an interface defines a level of abstraction, and its implementation is at the level immediately below it. And writing expressive code mostly comes down to respecting levels of abstraction.

It turns out that those concepts are also present in functional programming. For one thing, functions define an interface and you could nearly replace the word “object” with “function” in the 4 above concepts. But functional languages also have more elaborate ways to define interfaces, like with Haskell’s type classes.

And when you think about it, those concepts where also present in imperative programming, although in a much more basic way: by splitting the code into subroutines.

All this illustrates the interesting fact that modularity, encapsulation, polymorphism and levels of abstractions are fundamental notions to write good code, and they transcend programming languages and even programming paradigms.

This ties up well with the two main aspects of programming defined by Steve McConnell in Code Complete: managing complexity and reacting to change.

Making paradigms collaborate

Another way to benefit from the variety of paradigms is to make them work together.

John Carmack takes the position of avoiding mutating state in general, whenever this is practical and doesn’t kill performance. In the rarer cases where it does impact performance, he advocates to be practical and go for the side effects (for instance don’t return a copy of a C++ standard container each time you want to add something to it).

I have had the opportunity to talk with Michael Feathers about that question too. His view on the topic sounded quite sensible to me: a good way to mix object-oriented code with functional code is to structure your code with objects, and implement their methods in a functional programming style.

It seems to me that there are also cases where using objects inside of a functional-like piece of code can help making the code more expressive.

Take the example of curried objects. These objects can lump several functions together and make them share a common input. They can even play the role of adapters by embedding some logic and translate an interface into another.

Actually, and I know this can sound surprising in this context, those objects can even hold some mutable state. Take the example of an object that builds a CSV line from various strings that you send to it. The object remembers if it is at the beginning of the line to know whether or not to write a comma. If you have to have a mutable state, you might as well encapsulate it in an object rather that let it spill over the various call sites in the code.

The declarative paradigm, the ultimate style or just another passing paradigm?

The declarative paradigm is a interesting trend even though there aren’t as many programs that use it compared to the other paradigms. By declarative, I mean code where you merely state your intentions of the desired behaviour, as opposed to how to implement the desired behaviour.

At this stage, this style seems very attractive to me. Indeed, you have to state your intentions at some point, as the computer can’t figure them out for you. But if we could do only that, it would transform the face of programming.

When I talk about expressive code, I usually describe this as code where you can understand the intent of the person who wrote it. If the code were merely intentions, well, we would be there.

However, it seems difficult to achieve from a practical point of view today. The closest we can get is by designing declarative interfaces, and writing code to implement them.

One example is by implementing Domain Specific Languages (DSL). Another example we’ve come across is to use a rules engine to make declarative if statements:

auto isAGoodCustomer = RulesEngine{};

isGoodCustomer.If(customer.purchasedGoodsValue()) >= 1000);
isGoodCustomer.If(!customer.hasReturnedItems()));
isGoodCustomer.If(std::find(begin(surveyResponders), end(surveyResponders), customer) != end(surveyResponders));

auto isNotAGoodCustomer = isAGoodCustomer.Not;
isNotAGoodCustomer.If(customer.hasDefaulted());

if (isAGoodCustomer())
{
    // ...
}
else
{
    // ...
}

Apart for a few technical artifacts, this syntax of this code shares similarities with a specification document that expresses the intent we have for the program.

Declarative programming is a fascinating area, and if you have ideas on how to write declarative code, I would be grateful if you shared them with me.

Let’s discuss programming paradigms

If you found this article interesting and generally agree with it, that’s cool. But if you disagree and have a different view on programming and paradigms, it’s great, and now is the time to let your voice be heard in the comments section that’s all yours!

Related articles:

• Using a rules engine to make declarative if statements
• It all comes down to respecting levels of abstraction

The post Which Programming Paradigm Gives the Most Expressive Code? appeared first on Fluent C++.