Design By Contract (DBC)


Design by Contract (DBC) also called Programming by Contract is an approach that is used in the software design to define the formal interface specifications for software components where such specification are referred to as contracts (Metaphor for obligations and conditions of the regular business contracts). Such specifications extend the value of the data type abstraction by introducing the pre-conditions and post-conditions in this approach (Grand, 2009).

Software programs requires robustness, correctness, and reliability and any software program is considered correct if it performs according to its specifications and it can be robust if such program can handle situations that is not covered in its specifications in a decent manner. The main principle idea behind the design by contract approach is that having a contract between a class and its clients where the client must guarantee certain conditions before calling a method within such class (the pre­conditions) while the class will guarantee certain properties once the call is made (the post-conditions). If both pre-conditions and post-conditions are implemented in a way that the complier can check these conditions then any violation of the contract between the class and the client will be immediately detected (Holzl, 1998).

Design by Contract

Design by Contract advocates an additional assertions to the class or the interface implementation where the pre-conditions defines the rules (the obligations) of the caller of the method to stick with which have to be satisfied before the class’s method is called while also defines the post-conditions that will ensure the outcomes of the method (Grand, 2009).

McCafferty (2007) explained that Design-by-contract saves the developers’ effort that can be spent within the debugging mode and also spending time to see if the object reference correctly to the an instance of an object. With Design-by-Contract approach assists developers to write expressive code and also promotes better self-documentation within the code. Without having the DBC implemented within the code, usually comments are used (hopefully are exist within the code) to describe to the client how the code will be used and if any warning or caution that should be expected from using a specific method within the interface. The client in such case represents a third party that might be calling your API where the restriction of using such API or method is documented within the code (Called contract) and promised certain outcomes. With such implementation, despite the fact that the documentation was in place to clarify the API contract; there are a few problems with this approach:

  • If the client didn’t read the comments or didn’t pay enough attention to such comments, there a great chance that the client might pass invalid information and gets unexpected results.
  • The client might pass null values to some arguments (parameters) required by the method and such behavior will create an exception errors.
  • Passing wrong information from the client, allows the method not to be obligated to any sort of response to the client based on the contract agreement.

McCafferty (2007) also explained that with Design by Contract promotes the bidirectional explicit contracts instead of implicit contract where the contract obligates both the target method to guarantee a particular result and the client to invoke the method in a particular way. With such approach the contract is reinforced by one or more of pre-conditions and the on calls method also reinforced with one or more of post-conditions. With the bidirectional contract in place; the previous drawbacks have been addressed, and the code became more self-documented. The following are the benefits of implementing the Design-By-Contract in the code (DBC):

  • Implementing a better understand of how the software is constructed and how the methods work.
  • A more systematic approach giving the chance of building bug-free systems.
  • Implementing the design by contract approach allows implementing a framework that is more effective for testing, debugging, and with high quality assurance.
  • Design by contract represents a great approach of self-documenting software components.

Ananiev (2005) argues that contracts are essential part for Web Services, and design by contract is not a new approach that needs to be applied in the web services implementation, however the pre-condition and the post-condition never become mainstream, and it’s about time to implement the DBC to the mainstream for the following reason:

  • From the client’s prospective debugging and testing the web services calls represent a high cost process for testing and debugging a local method call, and some of these reason can be because the service provider might restrict the number of calls per day for testing and from the client prospective it not important for the client to be able to understand exactly what is returned from the web services (post-condition) and what is required for the client (pre-condition).
  • Web services can be exposed to different varieties of the client’s technologies, and as such’ it’s important for the service provider to be able to defined a contract that can simplify the exception processing, errors and unambiguously by separating the service’s business logic from the validation logic.

Ananiev (2005) explained that pre-condition and post-condition for web services must provide the following capabilities:

  • Pre-condition and post-condition should be able to provide the required validation for input parameter and output parameters and also post-condition should be able to validate the outputs parameter that is relative to the inputs parameter (e.g. Result-FlightbookingDate >= Input-FlightRequestedDate).
  • Pre-condition and post-conditions should be able to validate the service state (e.g. operation “B” can be called only after the operation “A” is called).
  • Pre-condition and post-condition checks can be implemented to run on the client or on the server and as such; during the testing phase of the web services, it might be beneficial to run such conditions on the client side to speed up the development process.

With the above being said, it is easier for the service provider to implement the pre-condition and the post-condition in the client’s libraries which allows the clients to deal with APIs which expresses in a language they can understand instead of having the clients to deal with WSDL. Such implementation will be more convenient for the clients, and the cost of such library will never be costly to implement (Ananiev, 2005).

To use a specific function written by someone, it’s important to know the range of arguments exist in the function and the effects of calling such function, and as such; using the Design by Contract will provide two types of information to express the obligation of the function caller (pre-condition) and callee “function” (post-condition) where the caller has to meet all the pre-condition of the function being called, and the callee “function” is obligated to meet its own post-condition. The failure of either party to ensure the above to happen and to live up to the terms of such contract shows that there’s a bug in the software (Mills, 2004).

Mills (2004) explained that the following are the benefits of using the DBC as part of the design implementation:

  • Since it’s difficult to implement contracts within a poorly defined responsibilities code, using the Design by Contract (DBC) will improve the design of the software and leads to a better code.
  • Well defined contracts that are merged with unit testing can help find the bugs early, and as such; reduces the debugging time.
  • Design by Contract represents a great documentation within the code, and also guarantee that the code always having the latest update of such documentation since any testing at runtime of such contract that shows bugs will be a good indication of the out-of-date documentation within the system.
  • The Design by contract is integrated within the build process which allows different level of checking on the contract implementation and ensures that the unit testing met all the requirements for certain software functionality.

Please watch the following presentation for DBC through the following link:  ide=


The traditional development approaches decrease the dependency issues within the software systems through the assumption of having functions and objects that expecting certain arguments and states that should be in a certain range, and in a certain type, and as such; violating such assumptions will lead to many bad things to happen. With implementing the Design by Contract approach, it is easy to construct and validate the hidden assumptions in the software. The DBC approach explicitly specifies the contractual relationships between the APIs and the client, where the compiler will generate additional code to check them at runtime. Setting the design by contract condition on impossible conditions will ensure that such contract can stop the execution immediately before these errors can happen, and producing debugging hints that can help fix errors within the code faster (, 2007).

Finally, (2007) explained that by implementing the Design by Contract within the code will add the following benefits to the design of the software:

  • The code becomes more reliable since the assumptions and the arguments within the code are clearly specified in writing.
  • There are always a check points in the code that prevent errors to creep in.
  • Since the contract implemented within the code specifies behaviors, such code can be reused without having to reverse engineering the code.
  • Implementing the design by contract within the code represent an up-to-date documentation since the in-sync is always exist to cover any bugs that might show up during the run-time.
  • It is easy to build test cases for specific functionality within the software since the contract specifies boundary conditions.
  • The implementation of any function within the system is much clearer since the contract states very clearly the relationship and the obligations between the caller and callee.
  • With the implementation of the Design by Contract the debugging becomes easy since any contractual violation will immediately throw an exception instead of propagating the error through many functions levels.
  • Maintenance with DBC approach is easier since the code represent a clear vision of the limitation imposed within the code through the contract implementation.


Ananiev, A. (2005) Design by Contract for Web Services [Online]. Available from:­contract-for-web-services (Accessed: 19 March 2011).

Grand, S. (2009) What is Design by Contract? [Online]. Available from: (Accessed: 19 March 2011). (2007) Design By Contract–Automatic Debugging [Online]. Available from: (Accessed: 19 March 2011).

Holzl, M. (1998) Design by Contract [Online]. Available from:  (Accessed: 19 March 2011).

McCafferty, B. (2007) Design-By-Contract: A Practical Introduction [Online]. Available from:­introduction.aspx (Accessed: 19 March 2011).

Mills, C. (2004) Using Design by Contract in C [Online]. Available from: (Accessed: 19 March 2011).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: