Why interfaces are poor contracts

what’s an interface for?

ok, we can achieve loose coupling and a higher degree of abstraction by shielding clients of a service or component from concrete implementations, that allows us to be very flexible in changing the underlying implementation. We also can describe flexible, independent type systems without the restriction of single class inheritance by having classes that might implement more than one Interface, playing multiple roles in different areas of one or more applications.

But there’s one underlying, basic connotation, that’s asserted significant to all those goals: the idea of an Interface as a kind of contract between a client and the implementor of that interface.
Even Sun’s java tutorial argues about Interfaces and contracts:

“Implementing an interface allows a class to become more formal about the behavior it promises to provide. Interfaces form a contract between the class and the outside world”

the idea of an Interface as a contract is very tempting – in the light of the above mentioned goals, an interface provides a kind of interaction basis between client and implementor. As long as both sides stick to the stipulated ‘terms’ of the Interface, they’re able to cooperate, no matter ‘where they come from’.

but this metaphor is dangerous and even misleading. the metaphor of a contract is way to strong for interfaces – i will show you …

what’s a contract for?

first of all, let’s take a closer look at the core signification of a ‘contract’ in the scope of software development.
in an object oriented world, we have an arbitrary number of objects that might need to collaborate in order to complete their tasks. in an abstract form, we can identify a client object and a supplier object on whom the client relies on to fullfill it’s task.

one of the biggest challenge for a client (or the designer of that client) is to ascertain if the supplier object is adequate in respect of the needed services the client relies on. the client is only able to function in a correct and robust way, if it knows about the precise constraints and effects of the supplier he depends on.
that said, the most difficult problem is to improve software reliability in terms of defining for each software element what it is supposed to do, as precisely as possible on a behavioral level – specifying and ensuring those constraints and effects (let’s say the obligations and benefits) is the main job of a contract!

now take a look back at interfaces in relation to that kind of contract metaphor.
they are way to poor to act as a real contract a client and supplier can rely on, since they only apply to a syntactical level of collaboration.
for better comprehensibility, i’ll demonstrate the basic essentials of their non-compliance on the basis of a simple example.

the contract of an account

say we want to implement a money transaction (as a command or within an order service). in order to accomplish the task we rely on two instances of type Account, one to debit and the other one to credit. because there are many different accounts with different characteristics, it’s abstracted and modeled as an interface, so the transaction logic is able to handle a wide variety of concrete account instances (admitted, it’s an overused example, but therefore well known and serves pretty good for our purpose).

take a look at the first version of the following interface of an account :

public interface Account{
	public BigDecimal deposit( BigDecimal amount );
	public void withdraw( BigDecimal amount );
}

lack of semantic expressiveness

so what could be the ‘contract’ of method deposit() we can rely on?
of course, using appropriate, meaningful names for operations and its arguments is common sense, so we understand that deposit() will likely credit the given account by the amount that’s passed into. but even we might understand the meaning of the method, it lacks some significant statements about it’s constraints and overall effects – it lacks a detailled specification of its behavioral semantic:

• it doesn’t tell you if it’s allowed to deposit a negative amount (or at least a minimum amount that’s required for a legal deposition).

• it isn’t obvious how an account should or will behave, if you deposit a negative amount.

• it doesn’t tell you about the meaning of the return value – it may be the additional fee for that deposition or the current balance (before or after the deposition?)

• it doesn’t tell you in which ways a withdrawal may affect the account (i.e. if it’s allowed to overdraw or under what circumstances the account may be blocked)

of course we could increase expressiveness by introducing some new types that are better suited for the problem domain. a BigDecimal is evidently an improper type for depositing – it’s money that we deposit:

public interface Account{
 	public Balance deposit( Money m );
	public Money withdraw( BigDecimal amount ) throws NegativeAmountException;
	...
}

// Implementation!!! forces you to only have Money with positive amount
public class Money{
	...
	public Money( BigDecimal amount, Currency currency ) throws NegativeAmountException{...}
}

now it’s clear that you can only deposit a positive amount of money and that the account’s balance is returned. but still, the interface isn’t able to specify if it’s the balance before or after deposition. ok, it’s obviously the balance after deposition (we suppose so), but can we really trust that ‘contract’ ?
as we have seen, introducing types may attenuate some of the semantic gaps, as those types may introduce some constraints of their own that will also hold for the interface they are used within: we can’t create a money instance with a negative amount, so it’s clear that we can also deposit only money with a positve amount.
but even if types are able to increase the semantical expressiveness to a certain extend, they are not able to give answers to all facets of specifying intended behaviour: as you may have seen, a money type not only holds an amount but also a certain currency. now’s the question if we can deposit money with an arbitrary currency (and the account may handle conversion between different currencies).
we may could give a ‘hint’ and add a new method getCurrency() to the accounts interface (providing the client with the account’s currency), but those methods are completely unrelated:

public interface Account{
	/** the account currency */
	public Currency getCurrency();

	/** ...
	 * @param money Money to deposit - only with account currency
	*/
 	public Balance deposit( Money money );
	...
}

and although we established another well known instrument that might increase expressiveness – comments – an Implementor of that interface is not forced to respect or relate to the account currency while depositing the given money (some kind of accounts may take all they can get)!
some might say, that commenting an interface in a ‘detailed’ way will be sufficient – it’s not sufficient in the context of a real contract – that will lead to the second, more important lack of an interface as a contract …

lack of enforcement of intended behaviour

the immediate objection is that documenting a module’s purpose will not ensure that it will achieve that specification;
you also could reverse this proposition and note that if we don’t enforce what a module should do, there is little likelihood that it will do it. (the law of excluded miracles)

as an example, here we have an implementation that fully implements the ‘syntactical contract’ but completely violates the intended ‘behavioural contact’:

public class BusinessAccount implements Account{
	...
	public Balance deposit( Money credit ){
		// we take all we can get ...
		balance.add( new Money( credit.getAmount(), getCurrency() );
		return balance;
	}

	/**
	 * ... and reduces the current balance by the requested amount
	 */
	public Money withdraw( BigDecimal amount ) throws NegativeAmountException{
		return new Money( amount, getCurrency() );
		// oops - we forgot to reduce the balance ... of course only by accident ...
	}
}

now i ask you, what’s that documented ‘contract’ worth if an implementor isn’t forced to play by the interfaces rules (be it by accident or by incident)?
even if we wanted to – how could we state and force the intended behaviour of reducing the balance when withdrawing a given amount, only given the possibility of expressing behaviour on a more or less syntactical level?

another one: how could we force implementors of that interface to block an account if a certain overdraft is exceeded?
again we could add a method getMaxOverdraft(), delivering the maximum allowed amount for overdrawing the balance – but again, implementors are not forced to relate to that overdraft when processing withdrawal – there’s no forced relationship between these to methods.

Design by Contract

let’s recap: generally, the contracts conditions defines mutual obligations and benefits all parties of that contract agree on. they force them to behave accordingly to the stated constraints during collaboration, focussing on the semantical behaviour of the involved collaborators – in its core, it’s not about a formal compliance with syntactical formalities – they are only an accessory part which doesn’t state anything about the intended constraints and effects.
in essence, successfull collaboration between a client and a supplier object needs a reliable basis, that’s build upon behaviour and not upon syntactical formalities. defining what an element is supposed to do is therefore about specifying how it will behave under which conditions – notably the constraints under which it is valid to call a method and the observable effects of that method to himself and its environment. it is especially not about a formal specification of a set of methods names. in fact, we wouldn’t care if one implementation of an account would offer a method named deposit() and another one a method named credit(), as long as their behaviour (its constraints and effects) would be the same!

one idea, that’s far more capable to specify and enforce behaviour on a more semantical level is the concept of Design by Contract. the idea was first coined by Betrand Meyer and fully supported in his language Eiffel (there are many excellent sources out there, so i won’t go into the details here). this concept is far more accomplishing the before mentioned contract metaphor than plain interfaces ever will – the ability to define constraints within so called preconditions (that must hold true before a method gets called) and effects within postconditions (that have to be ensured after the method returns) on a semantical level allows for far better behavioral specifications.
although you can also apply pre- and postconditions to concrete classes, Design by Contract is playing its full benefits when applied to interfaces.
once an interface is annotated with such a behavioral specification, all implementors have to comply to the stated effects and all clients of that interface have to adhere to the described constraints.
that said, it’s valid to call an interface a contract, if it’s not only defining a set of relating methods by syntactical formalities but also includes at least pre- and postconditions of that methods (and of course some invariants that may describe the nature of the interface).

to make things clear, let’s see how to extend the accounts interface about its intended behaviour (in the meantime, there are many good java libraries for Design by Contract out there. i will use the notation of SpringContracts because i’m most familiar with it. secondly i’m not sure if other solutions support the abbility to annotate interfaces beside classes):

@Invariant( condition = "this.balance >= this.maxOverdraft" )
public interface Account{

	public Currency getCurrency();

	@Postcondition( condition = "return <= 0" )
	public BigDecimal getMaxOverdraft();

	public Balance getBalance();

	@Precondition( condition = "credit.currency == this.currency" )
	@Postcondition( condition = "this.balance.amount == old:this.balance.amount + credit.amout" )
	public Balance deposit( Money credit );

	@Precondition( condition = "debit > 0 and this.balance.amount - debit >= this.maxOverdraft" )
	@Postcondition( condition = "this.balance.amount == old:this.balance.amount - debit" )
	public Money withdraw( BigDecimal debit) throws NegativeAmountException;
	...
}

as you hopefully have seen, adding invariants, pre- and postconditions to interfaces can enhace them with richer semantics that far better matches the contract metaphor. now we have a contract that specify the essential part when it comes to collaboration: behaviour!