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!

Advertisements

25 Responses to “Why interfaces are poor contracts”

  1. Alex Miller Says:

    Nice article. While it’s not a replacement by any means for design by contract, you might be interested in JSR 305, which will provide a standard set of annotations to give you more specificity on parameters and types.

    Here’s a talk by Bill Pugh.

    This lets you be more precise, but doesn’t address (to my knowledge) the ideas of invariants and pre/post conditions.

  2. Greg M Says:

    Also, contracts are poor interfaces. They break at runtime which can be too late, but also they conflict with encapsulation. So as much as can be expressed in an interface should be, and the rest as a contract (which is just runtime data-checking at function boundaries, so it can and should be done with or without language support). Know how expressive your type system is, and move towards more expressive systems where you can.

  3. Laird Nelson Says:

    With respect, Greg, I don’t think it’s possible for me to disagree more. Of course they break at runtime–how would you compile-time-check an incoming Integer, for example? And the author isn’t arguing that a contract is an interface. He’s providing suggestions to reduce the amount of code one must type, while exposing details about the interface so annotated to tools and auditing systems–something that isn’t easy to do in documentation.

    Best,
    Laird

  4. AkitaOnRails Says:

    Nothing new here: everybody knows Protocols are way more efficient than Interfacees in all regards. The reason the Web is a success? That’s because of the web ‘protocols’ like HTTP. Text based, loosely coupled, no-rigid-formal-static-interface. Tweak it, extend it, twist it, plug SOAP in, make it do REST, attach binaries in Base64, whatever you want.

    How sad would the Internet be if it followed strict Interface-like concepts. Languages like Smalltalk, Ruby are nice because they don’t call methods upon an strict Interface: they send arbitrary messages to an object and it will handle how it responds, no matter what. You will never have 100% compile time assessment of dynamic types, but you don’t really need to in practice. That’s a good compromise, we call it ‘Duck Typing’ and we call people who wants to statically validate a dynamic language structure a ‘Chicken Typing’.

  5. prashant Says:

    Mario Gleichmann,

    Very good article and yes completly agree with the author.

    Thanks
    Prashant Jalasutram

  6. Michael B Says:

    A contract doesn’t (en)force anything, a law doesn’t (en)force anything. (Your off here with respect to a contract) Unenforced there both meaningless.

    Unitest’s or the more convenient Annotations or the costly certification can all be more strict and arguably less hazardous/better then something as easily violated as commented code.

    The title is misleading, ‘contracts should be enforced’ or ‘comments are too lenient’ have a much better fit(although sounding less exciting)

    An interface sounds like a perfectly fine place to define rules / define your contract. Even you end up with a annotated interface(the fact that its annotated doesn’t change the fact that it’s still an interface). Yes checking is stricter, fail-fast and coupled with ide-support pretty darn excellent overall. But thats just the enforcing bit and that isn’t part of the contract.

  7. naikrovek Says:

    is this not what documentation and unit tests are for?

    If your class/interface has special requirements that can’t be described in code, then you document them. During unit tests, you pass in purposefully incorrect parameters to make sure that your method/constructor fails as per the doc.

    If you don’t have documentation that describes exactly how the method behaves given situations such as these, then you have problems that are more significant than whether an interface is actually a contract.

    An Interface in Java is a contract up to and including the point that is possible using the syntax of the Java language. Are you saying that the contract should be further defined than that? That is documentation.

  8. Mario Gleichmann Says:

    Alex,

    thank you very much for your interesting hint to JSR 305!

    it seems that some of the proposed annotations are very light kinds of preconditions (Nullness annotations, Signs annotations) and postconditions (Annotations to check return value and for purity) but as you’ve allready said not a replacement for design by contract, since they seem to be restricted to a fixed set of ‘use cases’ and therefore less flexible in expressing arbitrary constraints and effects.

    though, a very interesting JSR – i’m anxious to see its further development.

    Thanks again!

    Mario

  9. Mario Gleichmann Says:

    Greg,

    i’m not sure what you mean by ‘contracts are poor interfaces’ – could you please elaborate on that.

    as Laird mentioned – yes, most of those ‘contract constraints’ that are not fullfilled by implementors or clients will break at runtime, since most of them refer to state that result at runtime (although there’s some research on the field of static analysis).

    i don’t see that pre- or postconditions will break encapsulation – the opposite is the case: without an instrument to express behaviour on a semantical level (that’s part of the public interface of a module), you might be forced to inspect the implementation in order to find out how that supplier object will behave precisely. if i first have to see some code in order to gain insight to the detailed behaviour of a module in order to check if i can rely on that module than ‘information hiding’ is lost.
    granted, a type system can support expressivenes, but as mentioned in the post not to a full extend in most cases.

    Regards

    Mario

  10. Mario Gleichmann Says:

    AkitaOnRails,

    thanks for your remarks. i think there was a nice article on infoQ recently about quite the same topic (see http://www.infoq.com/news/2007/11/protocols-for-ducktyping).

    regarding ‘contracts’, the question is not about ‘method calls on a strict type system vs. message sending without regarding a type system at all’. its more about the question how you ‘can rely on a certain functionality if you don’t have control or insight to it’s implementation.
    speaking about contracts, they should be an instrument for specifying and ensuring that a module, component, service (or whatever unit of functionality) behaves the way you asume it should behave for your own needs (the post is firstly a demonstration that ‘contract’ is an inappropriate label for interfaces).

    taking a look at some of the known protocols like http, they play on a different level of granularity. looking at ‘put’ or ‘get’, they say absolutely nothing about the constraints and effects of the underlying functionality. you absolutely don’t know what goes in and what get’s back by looking at that mesage level – so in order to collaborate with an service, that level of protocol is useless in regard to the ‘behaviour’ of that service.

    of course you are right – a static type system isn’t the solution to all domains of problems! in case of high flexibility or the demand of a higher responsiveness to changes or recombination, the idea of duck typing might be a better choice. but there may be other problem domains, where duck typing might not be the right solution – when calling plane.open_air_deflector it might by quite displeasing when the call gets answered with open_air_deflector? or NoMethodError … :o)

    Greetings

    Mario

  11. Mario Gleichmann Says:

    Michael B,

    i’m not quite sure, but i think you missed the point.
    Design by Contract isn’t just about enhancing an interface with nice annotations. if so – than you’re right – they would be nothing more than a more or less formal kind of documentation.
    but Design by Contract is also about checking and therefore ensuring that the stated constraints are observed and adhered by supplier and clients. if not, than an exception is thrown (you might take a look at Eiffel, where this is a build in mechanism of the language or SpringContracts, were you can configure the behaviour when a contract is violated)

    i think the title of the post mostly hits the point: interfaces are oftentimes labeled as contracts and since they lack the mentioned characteristics of a contract, they are only poor ones (of course we could now argue about the definition of contract).

    again – of course – rules of a game, a business contract or laws are meaningless without a surrounding ‘environment’ that watches over the rules and intervents when necessary – but that’s exactly what Design by Contract offers!

    Regards

    Mario

  12. Mario Gleichmann Says:

    naikrovek,

    good points. i will elaborate on that on a blog entry of its own. watch out … :o)

  13. Michael B Says:

    I guess I wasn’t as clear as I had hoped.

    “but Design by Contract is also about checking and therefore ensuring that the stated constraints are observed and adhered by supplier and clients.”
    -(but) a contract isn’t about checking at all it’s ‘merely’ a collection of rules and expectations. As a point, a location, to define those rules interfaces fit nicely in this picture.

    Now why is all not well? As you hint at in your article, a documented method signature doesn’t cut it. It leads to errors, bugs and other because of sloppy programmers. And they are allowed to be sloppy because nothing is enforced: rules aren’t checked. This brings about the conclusion that ‘any form of a contract is meaningless UNLESS it is enforced’.

    To be able to enforce rules, they need to be specific and formal(unambiguous). If you specify pre and post conditions((part of) design by contract) you come a long way in fulfilling these requirements. To allow it to be automaticly enforced a computer needs to understand it. Since the artificial intelligence guys don’t seem to have come quite far enough yet(to be able to interpret human text). We help it along by using annotations.

    1 rules/expectations, 2 checking, 3 penalty
    1, the contract, captured by an interface
    2. compile-time or run-time checks
    3. bugs/errors/exceptions

    these are distinct area’s to me and problems occur due the lack of the second the contract(1) is usually there and the third is undeniable. Design by contract principles add value to the 3 by chancing some results into handleable specific errors/exceptions. Ok, so perhaps, I am, arguing over the what is a contract definition.

    However with the above in mind the java tutorial is quite correct. Alas also oblivious and unrealistic; you can leave enforcing/checking to humans, but in real life it’s far to costly and time consuming.

    an unenforced rule/contracts breaks the system; it’s a incomplete; a ‘poor’ system vs a meaningless(unenforced) contract is a poor contract. -> Its all a matter of which perspective one takes

    I hope that made any sense.

  14. Markus Says:

    Choosing annotations over Java Code (concrete implementations) to enrich interfaces, seems not right for me.

    You have introduced a proprietary language to make code smaller but at what price?
    Annotation rules
    – can’t be refactored,
    – can’t be debugged,
    – are limited in language possiblities,
    – and same rules will be repeated all over the code.

    Fullfilling a contract can be very demanding an complex, please leave it in Java.

  15. Mario Gleichmann Says:

    Michael B,

    thanks for your quick response!
    now it’s me who may not get your point: do you want to emphasize again that an annotation alone doesn’t buy you much? right so – i thought to make clear in my last answer that there of course have to be an ‘appropriate environment’ that investigates and checks those contract elements.

    of course – an annotation alone is useless without the ‘environment’ that ‘cares’, just as well as declaration of transaction demarcation, resp. transaction attributes (be it by using a kind of @Transaction annotation or by using external declaration within a deployment descriptor) or declaring a bean to be a persistent one (again by using some kind of @Entity annotation or mapping files) is useless if there’s no environment or container that evaluates and processes those declarations!

    same is true for contract elements. i thought to make clear that there IS such an environment that detects and evaluates those conditions. in particular there is no need for artificial intelligence or ‘human care’, since all those statements are expressed in a formal language (EL – Expression Language in the posts example) and result to a boolean expression that can be easily evaluated.

    to make things clear: SpringContracts for example offers such an evaluating ‘environment’ that uses AOP to intercept method calls to instances of classes that may implement a ‘contracted’ interface and checks the contract’s statements (the invariants and the pre- and postconditions of the method that gets called) at runtime. since they represent a boolean expression they result to true or false (using an EL-Evaluator that evaluates the expression in our specific case). in case that the stated expression evaluates to false, that means the statement isn’t fullfilled (one of the contracts conditions are violated) a ContractViolationException is thrown by default. as you can see – nothing magic needed to enforce such a contract (or do we now have to argue about the definition of enforcement :o)), even no AI is needed.

    Hope that migth clarify some misunderstandings – if i’m not hitting your point – please let me know.

    Greetings

    Mario

  16. Mario Gleichmann Says:

    Markus,

    as always – thanks for your feedback!
    i fully understand your concerns and will respond to them in a minute.

    first of all, the core of the post tries to deliberate on the concept or metaphor of a contract and the widely accepted term of interfaces as contracts. while there are surely some solutions of DBC that have their specific shortcomings (SpringContracts is no exception), the post is more about the idea of a contract and in respect to that metaphor about Design by Contract as a principle.

    now to your concerns – i share those in the main. thus, i want to give some of my thoughs:

    – “Choosing annotations over Java Code”
    it’s most relevant to see invariants, pre- and postconditions as a part of the public interface! if you declare those conditions within a class, than they loose connection to the public interface (for me it’s kind of hiding the contract, so clients (and even implementors) can’t see what’s the intended behaviour at first sight. that said, pre- and postconditions stay on the same informational level than the declared types of a methods arguments.

    – “introduced a proprietary language”
    that must not be true for all kind of implementations of dbc. take a look at Eiffel, where you specify invariants, pre and postconditions in the terms of the language itself (with some additional keywords like ‘require’ (introducing preconditions), ensure (introducing postconditions) or ‘old’)

    – “Annotation rules”
    unfortunately they are the most appropriate instrument to annotate classes and methods nowadays (sadly, there aren’t such keywords like ‘require’ or ‘ensure’).

    – “can’t be refactored”
    i think you want to say that they can’t be automatically refactored by IDE support. of course you could refactor those conditions manually. i see your point – since you can’t put code inside annotations (a kind of closure for example) you are limited when it comes to refactoring the underlying interface or classes.

    – “can’t be debugged”
    that’s again specific to the implementation. You could debug SpringContracts as work simply by adding a breakpoint to the aspects code that intercepts the method calls and evaluates the conditions (admitted – debugging the evaluation of the condition itself might be harder)

    – “are limited in language possiblities”
    that belongs to all kind of solutions where you have to express your intention. if you’re using a dsl and want to express a condition that wasn’t foreseen by the ‘language’ you’re in trouble.
    but as said before the language you’re using to express the contracts conditions are specific to the solution. SpringContracts for example allows you to switch to another language (maybe groovy or even java itself) simpy by configuring the underlying evaluator.

    – “and same rules will be repeated all over the code”
    i’m a little bit irritated about that. for me, dbc is JUST about NOT to repeat the ‘rules’ all over the code!
    let’s see how this will look if you directly include the ‘rules’ inside your code – you may will use assertions or guard clauses to check the preconditions and again assertions or some other routines to check the postconditions and invariants:
    – you can only apply those checks to classes, not interfaces
    – you have to apply invariant assertions to all of your methods (seems like a kind of pollution resp. violation of the DRY principle to me). and if you add a new method – don’t forget to insert the invariants checks.
    – assertions are NOT inheritet. if you extend a class and overwrite a method, the assertions of the superclass are lost, otherwise you have to repeat the assertions in all your subclasses.
    not so with dbc: you declare the contract to an interface and all implementors and even subtypes of that implementors automatically inherit the contract and also gets checked automatically without further effort.
    now what strategy will have more repeated code? :o)

    Best Regards

    Mario

  17. John "Z-Bo" Zabroski Says:

    Many programmers are capable of programming without knowing the details of a contract. As a trivial example, open and close operations on a file require a contract that specifies the ability to map a file on persistent storage to a stream. Without this assumption, file manipulation must be stateless. As an example, NSF’s RESTful commands do not support stream abstraction, and NSF is stateless. For reading an entire file into memory, the client is therefore responsible for keeping track of what parts of the file have already been scanned. The client can manipulate the file through a client-side interface that implements the Scanner pattern, protecting and hiding state-process related to advancing the iterator (a byte off-set indicating how far into the file client has read) and how large a token is (a number indicating how many bytes to scan past and retrieve). In doing so, the client can support stream I/O principles, but there is still no synchronization between client and server. The client is merely manipulating shadows, not a contract.

    The notion of a Protocol pattern therefore makes sense in the context of REST as an implementation pattern for protecting and hiding state-process and creating a domain-specific language on top of an initial set of devices capable only of stateless operations. On top of these stateless operations, we can synthesize arbitrarily complicated devices using primitive elements. This gives us a bootstrapping technique for extending the usefulness of a primitive initial set of stateless devices.

    Locating contracts at interface boundaries comes from Floyd’s work with flow charts and Dijkstra’s ensuing weakest precondition. However, it doesn’t matter where the contracts are located so long as contracts are enforced. There is a clear separation of concerns with regards to defining rules and enforcing rules. As an example, the SQL Standard attempts to separate entering rules into the database (through a Data Definition Language) from enforcing those rules (through role-based execution of a Data Manipulation Language).

    “Chicken typing” seems like more programmer slang I can do without. The bigger picture is not best captured through slang but simple concepts like data correctness and data independence. For the same reason, the notion of “hard” duck typing and “soft” duck typing seems misguided. All of these ideas — “chicken typing”, “soft” duck typing, “hard” duck typing, &c. — are based on the more general engineering principle Pursuit of Simplicity through Constraint. Sometimes, our goal as programmers is to build a family of devices whose information processing characteristics can be specified as simple I/O procedures. Let’s not forget that goal.

  18. John "Z-Bo" Zabroski Says:

    One more comment I forgot to mention… Type systems provide confidence, not certainty. There is always the human element; Fred Brooks calls it conceptual integrity. Simple point, but easy to overlook. It’s why I don’t care for blog entries about “chicken typing” and such stuff. They’re examining problems at too specific detail, and taking focus away from concepts like data correctness and data integrity.

    Also, since I am unfamiliar with SpringContracts, can someone provide an example? It seems like the goal is to use reflection to determine if the weakest precondition is satisfied, but how is state handled when it turns out a precondition is not met?

  19. TDD, Contracts, and Reading the Fine Print - Dave Laribee Says:

    […] more-robust contracts? Sifting through a quick Google search on the subject yields a nice post by Mario Gleichmann exploring the idea that interfaces all by themselves are poor contracts. Published Sep 18 2008, […]

  20. TDD, Contracts, and Reading the Fine Print - Mirrored Blogs Says:

    […] more-robust contracts? Sifting through a quick Google search on the subject yields a nice post by Mario Gleichmann exploring the idea that interfaces all by themselves are poor […]

  21. TDD, Contracts, and Reading the Fine Print - Dave Laribee Says:

    […] more-robust contracts? Sifting through a quick Google search on the subject yields a nice post by Mario Gleichmann exploring the idea that interfaces all by themselves are poor contracts. Published Sep 18 […]

  22. 網站製作學習誌 » [Web] 連結分享 Says:

    […] Why interfaces are poor contracts […]

  23. Christiane Withey Says:

    Thank you very much for another helpful post. I have been a big fan for a few months, and I have been enjoying ever second of it With so many autogenerated blogs out there, its refreshing to find a real one. I run a blog that is very similar, is there any way you would write a guest post on it? Shoot me an email if you are interested!

  24. Marina Says:

    This is really attention-grabbing, You are an excessively professional blogger.
    I’ve joined your feed and stay up for in search of more of your magnificent post. Additionally, I’ve shared your web site in my
    social networks


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: