design by contract : Java Glossary

“One should not write a class without a specification — a contract. The contract lists the internal consistency conditions that the class will maintain (the invariant) and, for each operation, the correctness conditions that are the responsibility of the client (the precondition) and those which the operation promises to establish in return (the postcondition).

Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI chip, bridge, engine…) without a spec. No professional engineer would even consider the idea.”
~ Bertrand Meyer, Description of Design By Contract

	recommend book⇒Object-Oriented Software Construction
		paperback	hardcover
	ISBN13:	978-0-13-629155-8	978-0-13-629049-0
	ISBN10:	0-13-629155-4	0-13-629049-3
	publisher:	Prentice Hall
	published:	2000-03-21
	by:	Bertrand Meyer
This is the classic text on object-oriented programming. This is the best-written computer textbook on any subject I have yet encountered. If you ever plan to write a book, look at this to see how it should be done. He uses the Eiffel language for his examples. This could be confusing if you don’t already have little Java under your belt. This is not a book on coding, but rather on the general object-oriented principles behind the languages.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com abe books anz

	recommend book⇒Design By Contract
		paperback
	ISBN13:	978-0-13-088921-8
	ISBN10:	0-13-088921-0
	publisher:	Prentice Hall
	published:	2001-06-15
	by:	Bertrand Meyer
Difficult to find. Try Chapters.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com abe books anz

You can also have invariants on the non-public parts. Only the invariants involving purely public features (methods and variables) are in themselves public.

Eiffel lets you talk about both the old and new values of variables in your assertions. In Eiffel, these conditions are a formal part of the language and may optionally be checked at run time. The beautiful part is that the contract is inherited. A subclass may have a tighter, but not looser contract. None of the Java assertion schemes can do this.

Speaking more precisely, in a subclass, preconditions for an inherited method can only be equal to or weaker than that of the original precondition; and postconditions for an inherited method can only be equal to or stronger than that of the original postcondition. In other words, the precondition cannot be modified in the subclass to require more from the client than what is required in the parent class.

Another form of assertion is called the loop invariant, something that must be true each time through a loop. These assertions are not considered part of a method’s or class’s contract with the rest of the world, however. Similarly, there are assertions to ensure a loop eventually terminates.

In Java there are various ways of kludging design by contract and assertions including: iContract, JMSAssert, jContractor, Handshake, Jass, JML and JPP. Starting with Java 1.4, Java has a weak built-in assertions mechanism. It is a far cry from design by contract.

Learning More