During a recent discussion between two developers here at the Dataworks office a scenario arose on a project where there was a need to validate the parameters being passed to particular functions. 

The discussion queried not only using unit tests to test for these scenarios but how these tests would rely on code within the functions checking the various conditions on the parameters.  This code could become lengthy, cluttering business logic implemented by the class and adding a code maintenance overhead.

Design by Contract (DBC) was suggested as a solution to the problem that would complement the unit testing while giving a clean way to check conditions expected by functions within particular classes. 

DBC is a concept in programming based on the metaphor of contracts between suppliers and clients in business.  It describes an approach to programming where functions in a class can set preconditions, post conditions and invariants which must be honored by any program calling that function.  If any of the preconditions, post conditions or invariants are not honored an exception is raised by the function being called.  In this way clients must honor preconditions and can depend on post conditions and invariants.

A precondition is a condition guaranteed on calling a supplier, so placing an obligation on the client which calls the function while freeing the function from having to handle cases outside of the precondition.  For example null parameters.

A post condition is a condition guaranteed on exiting the supplier, so placing an obligation on the function being called while freeing the client from checking those conditions after calling the function.

An invariant can be assumed throughout the supplier from entry to exit.  So for each call to functions in a class the invariant conditions will be maintained within their specified tolerances after execution of the function.

This approach allows developers to define a precise verifiable interface for a given component. When a contract condition is not met the supplier is expected to fail hard. Generally an exception is raised.  The supplier does not try to handle the breach of contract it just throws an exception. There can be concern that DBC related code can introduce a performance overhead.  For this reason DBC is often used only in debug and is turned off in release code.

The concept originated in Eiffel language and the name Design by Contract is a trade mark of Eiffel Software. For .Net developers, Microsoft has a library called Code Contracts which facilitates the use of design by contract concepts in applications developed on the .Net framework. This library is available for .Net framework version 4.0.

Read our next blog where we cover the use of the Code Contracts library and how it facilitates the implementation of the DBC concepts discussed here: Code Contracts and Implementation of DBC

At Dataworks we enable the perfect hybrid of configurable off the shelf toolsets and custom software development to deliver innovative solutions to match your specific business process requirements. This ensures we are the best at what we do.

If you would like to discuss how we can use our experience and expertise to deliver real benefits toyour business please contact us today on 051 878555 or email info@dataworks.ie

Image courtesy of pat138241 / FreeDigitalPhotos.net