In the 1980s, Bertrand Meyernot surprisingly yet another compiler writer (the OO language Eiffel)started to promote the use of pre- and post-condition assertions as first-class elements within his Eiffel language, to be applied to OOA/D. He contributed to a much wider awareness of formal specifications and operation contracts in his popular book Object-Oriented Software Construction, in which he also proposed the approach as a method called Design by Contract (DBC).

Java Practice says

“Although Design By Contract is a formal part of some programming languages, such as Eiffel, it is not a formal part of Java. Nevertheless, Design By Contract is very useful for designing classes and interfaces. It can both guide the discovery of a more robust design, and allow more effective expression of that design in javadoc.

Requirements are simply any conditions on use, for example

* conditions on argument values
* conditions on order of execution of methods
* condtions on execution in a multi-threaded environment

Requirements must be stated in javadoc, and may be enforced by throwing checked or unchecked exceptions when the stated conditions are violated. Using assertions for enforcing requirements is not recommended.

Promises are stated in javadoc. They can be enforced by assertions at the end of a method. ”

If you are developing a stand-alone application, then you need to think in DBC for your public API and function. DBC in Java could be implemented by AOP, Dynamic Proxy or other frameworks.

Design by contract from wikipedia
Contract enforcement with AOP
iContract: Design by Contract in Java
Implement Design by Contract for Java using dynamic proxies
Defensive programming with AOP