Design by Contract Programming in C++

The Eiffel programming language introduced "design by contract" to object oriented programming. The main idea here is to model interfaces between classes as contracts. In this article, we will be applying this powerful technique to C++ programming.

Interfaces as Contracts

In legal terms, a contract is a binding document that describes the responsibilities and expectations of the parties entering into the contract. Interfaces between classes can be modeled in the same way. Whenever an object invokes a method of an other object, this interaction should be viewed as a contract between the caller and the called method. This contract consists of the following conditions:

Design by Contract Framework

We will consider an example here to see how "design by contract" is implemented in C++. We start by looking at the basic framework for design by contract. The framework consists of the following macros that are available only in the debug mode. The macros are defined to blank in the release build.

Design by Contract Framework

Debug and Release Builds

The "design by contract" framework can work only if the programmers can introduce aggressive checks without having to worrying about their performance implications. The main idea here is that lab testing of the product should be done with debug builds (i.e. _DEBUG flag is defined) where all the "design by contract" macros are enabled. These macros will allow you to zero in on the faults very quickly as all breach of contract conditions are being checked. This can dramatically lower the debugging time in a large project. This means you will have less of those unhealthy finger pointing sessions when bugs have to be isolated.

When the product is ready to be shipped, the release build can be made. This build will disable all the macros used in the "design by contract" framework. Thus you will obtain complete performance. If CPU performance is not a big issue, in the initial deployment you may decide to retain the macros and replace the exit condition in the ASSERT macro with exception throwing. Thus you have complete control on the level of debugging you wish to have in the final product.

An important thing to note here is that the "design by contract" framework is not a replacement for defensive programming. You still write defensive code which handles error conditions even in the release build. You can view the contract checking as a diagnostic programming technique that allows you to be extra suspicious in handling contracts when the implementation of the contract is new and untested. When you get comfortable with the contract implementation, you turn off the extra suspicious checking.

Another benefit of "design by contract" technique is that it gives you extra diagnostic capability without compromising readability. There is no need to add redundant if statements for diagnostic programming.  In fact, these macros will actually improve the readability as they clearly state the expectations of the caller and the called methods.

An Example of Design by Contract Programming

Here we have taken an example from the STL Design Patterns article and added support for the "design by contract" framework. All the additions to the original Terminal Manager are shown in bold.

Terminal Manager