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 (Very Large Scale Integration) chip, bridge, engine…) without a spec. No professional engineer would even consider the idea.
~ Bertrand Meyer (1950 age:67), creator of design by contract and the Eiffel language. Description of Design By Contract

Book referral for Object-Oriented Software Construction

	recommend book⇒Object-Oriented Software Construction
	by	Bertrand Meyer	978-0-13-629155-8	paperback
	birth	1950 age:67	978-0-13-629049-0	hardcover
	publisher	Prentice Hall
	published	2000-03-21
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.
Online bookstores carrying Object-Oriented Software Construction abe books anz abe books.ca abe books.de amazon.ca amazon.de Chapters Indigo amazon.es Chapters Indigo eBooks iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Nook at Barnes & Noble amazon.it Kobo junglee.com Google play abe books.co.uk O’Reilly Safari amazon.co.uk Powells other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

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, jContractor, Jass, JML and JPP. Starting with Java version 1.4, Java has a weak built-in assertions mechanism. It is a far cry from design by contract.

Learning More