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?

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.

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? )

Best Regards

Mario

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 )), even no AI is needed.

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

Greetings

Mario

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.

“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.

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