[pattern] Design By Contract (DBC)

HOT TIP: this content is flagged as highly recommended !

Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts.

"Design by Contract" is a registered trademark of Eiffel Software in the United States, and should not be confused with the general design approach. Microsoft calls their design-by-contract programming implementation "Code Contracts".

Source: Design by contract Version date: 2014-02-23

Both Java and PHP offer a formal interface type, which corresponds to the Unified Modeling Language (UML) element Interface; in C++ the same can be achieved with abstract classes, and can be handled in UML either through special reverse/forward engineering identification methods and/or by «Interface» stereotypes (depending on the UML tool, and the UML version).

Although it is described in the Wikipedia article above as an 'approach for designing software' it is a de facto or "honorary" Design Pattern and features in nearly every modern software Design Pattern.

It is usually supported by access to new (or re-purposed) instances of interface objects obtained as "products" of a factory. The choice of factory implementation will determine the concrete implementations of the interface objects supplied, and the client to the interface objects usually need not know what implementations were chosen, as long as the interface contracts of the products are met.

The Drupal7 coding standards concerning Use of interfaces specifically recommend Design By Contract:

'The use of a separate interface definition from an implementing class is strongly encouraged because it allows more flexibility in extending code later.'

'If there is even a remote possibility of a class being swapped out for another implementation at some point in the future, split the method definitions off into a formal Interface. A class that is intended to be extended must always provide an Interface that other classes can implement rather than forcing them to extend the base class'

The OOE = Object Oriented Examples = One Of Each module (mostly) imposes this policy brutally, since otherwise one simply can't have access to most Design Patterns. Special sterotypes are used in the UML diagrams to indicate «!product» interfaces supplied by a factory, and exceptions, where a specific implementation is chosen by a class without the use of a factory, are indicated by «!chosen» in UML diagrams, and by remarks in "counter-example" methods deliberately included to show you "how not to do it" when working with the OOE system.

There are however pragmatic cases where neither a factory supplying interface products nor even the "local" choice of a specific implementation of an interface are sufficiently indicated.

Even if the use of factories providing interface products may seem like extra fuss at first, mostly it pays off and more than, and suddenly all sorts of magical opportunities open up when one uses them.

Visit also