🍌 C++ Feed

Arthur O’Dwyer
Inheritance is for sharing an interface (and so is overloading)

This blog post was inspired by my answer to a question
on Code Review StackExchange. To utterly oversimplify the question: When is it appropriate
to use classical inheritance?

struct Cat {
    void meow();
};
struct Dog {
    void bark();
};

// Should I write a struct AbstractAnimal?

Here’s what the same code would look like, with an AbstractAnimal base class
(and omitting the NVI
for pedagogical reasons):

struct AbstractAnimal {
    virtual void do_speak() = 0;
};

struct Cat : public AbstractAnimal {
    void meow();
private:
    void do_speak() override { meow(); }
};

struct Dog : public AbstractAnimal {
    void bark();
private:
    void do_speak() override { bark(); }
};

The only reason to use a base class here is in order to write polymorphic code that operates
on (a pointer or reference to) that base class.

// If all my code looks like this, I don't need a base class.
void operateOnCat(Cat *c) { c->meow(); }
operateOnCat(myCat);

// I need the base class only if I want to write code like this.
void operateOnAnything(AbstractAnimal *a) { a->do_speak(); }
operateOnAnything(myCat);
operateOnAnything(myDog);

If you don’t need to write operateOnAnything, then you shouldn’t write AbstractAnimal.
Abstraction is a tool for solving problems — and, as such, it is also a signal to the reader
that a problem is being solved! If your code doesn’t actually need polymorphism in order
to work, then you should avoid making an inheritance hierarchy.

Keep it simple, stupid.

The design principles of polymorphic programming apply equally to generic programming…

When should I name two methods the same?

Notice that in our original Cat/Dog code, I named the two methods Cat::meow()
and Dog::bark(). It’s very tempting to give them the same name:

struct Cat {
    void talk();  // meows
};
struct Dog {
    void talk();  // barks
};

However, this is once again a signal to the reader that something indispensable is
going on here! Meowing and barking are vaguely similar at an abstract level, yes;
but abstraction is a tool for solving problems, and so we should avoid it unless
a problem exists to be solved.

The only reason to use the same name for meowing and barking, here, is in order
to write generic code that operates on an object of unknown type T.

// If all my code looks like this, I don't need to reuse the
// same name in both classes.
void operateOnCat(Cat& c) { c.meow(); }
operateOnCat(myCat);

// I need the same name only if I want to write code like this.
template
void operateOnAnything(T& t) { t.talk(); }
operateOnAnything(myCat);
operateOnAnything(myDog);

Notice that another way to ask “When should I name two methods the same?”
is to ask “When should I define a C++20 concept modeled by both these classes?”
The rules of classical OOP are isomorphic to the rules of generic programming with
concepts: just replace “base class” with “concept” and “derives from” with “models.”

Let’s go deeper.

When should I put two functions into an overload set?

The previous section was about reusing the same name outside of an overload set:
Cat::talk and Dog::talk aren’t “overloads” per se. But what about something like
this?

struct Snake {
    void eatPellet(const Pellet&);
    void eatCat(const Cat&);
};

Should we rename both methods to just Snake::eat, creating an overload set?

The only reason to use the sa

15 views18:31