Interfaces in C++

I once had a discussion with other programmer who claimed that interfaces are bad programming practice in C++. I have ordered most well-known and respected books about C++ and looked for quotations corresponding to my question:

Is it a good programming practice to have interfaces?
Are they commonly used?

Let the masters speak.

 

Bjarne Stroustrup, The C++ Programming Language, Addison Wesley, 2006, chapter 25.3, page 769:

The simplest way of loosening the coupling between users of a class and its implementation and also between code that creates objects and code that uses such objects is to introduce an abstract class that represents the interface to a set of implementations of a common concept.

(…) To sum up, an abstract type aims to:

[1] define a single concept in a way that allows several implementations of it to coexist in a program [this is what's needed for unit testing]
[2] provide a reasonable run-time and space efficiency through the use of virtual functions
[3] let each implementation have only minimal dependency on other classes; and
[4] be comprehensible in isolation

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addison Wesley, 2005, chapter 1 (“Introduction”), page 18:

There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes:

1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.
2. Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface.

This so greatly reduces implementation dependencies between subsystems that it leads to the following principle of reusable object-oriented design:

Program to an interface, not an implementation

Don’t declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class. You will find this to be a common theme of the design patterns in this book.

Bruce Eckel, Thinking in C++, vol. 1, Second Edition, Prentice Hall, chapter 15 (“Polymorphism & Virtual Functions”), page 646

Abstract base classes and pure virtual functions

Often in a design, you want the base class to present only an interface for its derived classes. That is, you don’t want anyone to actually create an object of the base class, only to upcast it to so that its interface can be used. This is accomplished by making that class abstract, which happens if you give it at least one pure virtual function. (…)

(…) The only reason to establish the common interface is so it can be expressed differently for each different subtype. It creates a basic form that determines what’s in common with all of the derived classes ― nothing else.

Bruce Eckel, Thinking in C++, vol. 2, Prentice Hall, chapter 9 (“Multiple Inheritance”, “Interface Inheritance”), page 576

Interface inheritance, on the other hand, only adds member function declarations to a derived class interface and is not directly supported in C++. The usual technique to simulate interface inheritance in C++ is to derive from an interface class, which is a class that contains only declarations (no data or function bodies). These declarations will be pure virtual functions, except for the destructor. (…)

Herb Sutter, Andrei Alexandrescu, C++ Coding Standards, Addison Wesley, 2004, chapter “Class Design and Inheritance”, page 62.

36. Prefer providing abstract interfaces

Summary
Love abstract art: Abstract interfaces help you focus on getting an abstraction right without muddling it with implementation or state management details. Prefer to design hierarchies that implement abstract interfaces that model abstract concepts.

Discussion
Prefer to define and inherit from abstract interfaces. An abstract interface is an abstract class made up entirely of (pure) virtual functions and having no state (member data) and usually no member function implementations. Note that avoiding state in abstract interfaces simplifies the entire hierarchy design (see [Meyers96] for examples).

In conclusion, interfaces in C++, expressed as pure abstract classes, are recommended and commonly used.

Marek Bliziński, my father

17th March is my father’s death anniversary. I noticed that English Wikipedia didn’t have an entry about him, so I translated the Polish one.

Lenina was very kind to proofread and correct my translation. Thanks!

Books ordered

I talked with my boss about problem with my co-worker. Although he says it’s not bullying, he sees that a problem exists. I can call that a progress.

I have ordered a book about bullying, as well as few other ones about C++ to have something to refer to when talking about technical things. Not to mention all the goodness of having them available every day.

The survival kit costs over £160 and consists of:

1. Bjarne Stroustrup: The C++ Programming Language
2. Gang of Four: Design Patterns
3. Bruce Eckel: Thinking in C++ (Vol 1 & 2)
4. Tim Field: Bully in sight

Bullying

I’m working on a project written in C++, which, as many other projects, suffers from various bugs popping here and there. One of the best things to do in such situation, as recommended by Bruce Eckel, is to use unit testing to ensure that various pieces of software work properly.

I was utterly surprised to learn that the main programmer (D.) disapproved one of the changes needed by unit testing. Class interfaces, which in C++ are called pure abstract classes are well known and widely adapted. It’s mentioned in most C++ books, such as Bjarne Stroustrup’s C++ Language, Bruce Eckel’s Thinking in C++ and the Gang of Four’s Design Patterns.

It has became clear to me that the problem is not technical. It’s sociological.

Looking for help, I started reading teamwork-related pages on Wikipedia. My girlfriend asked what I was looking for and pointed me at the right term: bullying.

It’s the first time I had became a target of bullying. I only recently started to see the pattern in which D. acts. Until now, I was trying to find higher reasons for him to make my life difficult. I was sure that there was a reason, but I wouldn’t see it.

It’s a lots of small events which start to make sense altogether. For instance, my first two days at the new work, he was absent! There wasn’t really anybody who would get me started. The professor did his best, but he couldn’t really introduce the guts of the program to me. After that, it wasn’t any better, really. D. didn’t help me with anything. He wouldn’t care if I had all I needed to do my job. I did manage somehow, but it was nothing like proper task delegating. Being a new employee, I didn’t want to make too much noise. I just sat down and worked hard to get my job done.

If it was bullying I experienced first few days, is hard to tell. However, bullying is not a single event. It’s a series of events, where each event can be rationalized and explained. “I was absent because this and that.” or “I didn’t tell him that because I didn’t know that he didn’t know.” It’s the pattern that betrays bullying.

Bullying in school is often primitive. However, in a workplace, bullying can take subtle forms. In this case everything takes place in world of programming, technology and code. In this world, I’m one on one with the aggressor. Nobody around can really tell what’s going on. On the surface, people only see me sitting there in silence, working on my laptop.

Looking for more information, I found Bully on-line, which is a great source of information about bullying. I read lots of interesting things there, like: What makes one vulnerable to bullying? What’s typical bully like? What’s the typical motive?

From what I read there, the typical situation is when someone with a strong position but lacking competence is turning against someone competent, but with weaker position.

D., as far as I know, has no computer science education. I heard that he is a statistician, who learned C++ “on the way”. Perhaps D. has a problem with that and he wants to show the world that he can program better than a computer science MSc.

D. is deadly effective so far, destroying all my contribution to the project. He refused to use Autotools, he vetoed class interfaces (needed by unit testing), doubled my work in many places and generally refused cooperation (not explicitly, of course).

I’m going to talk to my boss about this on Monday. So far, he always avoids this topic. I try to tell him that the source of the problem might be not technological. Every time I try that, he says something like “let’s just, for now, do…” and some non-solution follows.

How it will end, is hard to tell. I will be working with D. for at least one and a half month more.

mockpp 1.14.2 for Ubuntu 6.10 Edgy Eft

I couldn’t find any packages with mockpp (Mock Objects for C++) for Ubuntu 6.10 Edgy Eft, so I made my own package. If you want to use it, here you go:

•  mockpp_1.4.2.deb

Enjoy!

By the way, since people like to sue everybody for everything, please note that you use this package at your own risk.