Ideally, clients should rely only on the contract for information, and not the implementation of the method. This is emphasized by having accompanying tool support that generates method documentation (similar to conventional API documentation) that describes the API and contract for a method but omits its implementation. In realistic development, this enables the implementation of the method to be changed without invalidating properties of the method that clients are relying on. In multi-vendor development contexts, it enables, e.g., a prime contractor to specify via method contracts important properties that they ethey expect subcontractors to deliver. In this particular example, this all may seem a bit silly since the example is so small and the contract itself is longer than the source code. More convincing uses of the approach are given later.