|
Since the topic of Design-by-Contract keeps popping up, I thought an article in the latest JavaWorld might be of interest. iContract uses a preprocessor technique to extract the terms of the contract from the comments. Using comments is not an optimal approach, but as long as you're diligent it can be a workable solution.
Of course, the hardest part of implementing contracts into a language is the rules of inheritance. Theoretically, subclasses can replace a precondition with a weaker one, while postconditions and invariants must be as strict (if not stricter). iContract seems to only allow stricter conditions - preconditions can not be relaxed.
Another problem is in the interfaces. Java (and Eiffel#) do not allow implementation within the interface declarations. Instead, the contract is enforced within the instances of the interface implementation. This means that the contract is not part of the interface abstraction. Seems to me that interfaces are the best place for defining the contract since the contract is really part of the abstraction (not the implementation).
Posted to OOP by Chris Rathman on 2/18/01; 10:48:18 AM
|
|
iContract: DbC for Java
