Category: Designing Contracts

There is more and more support for pre- and post-condition checks, even in languages like Java. For instance, IntelliJ, a famous Java IDE, offers the @Nullable and @NotNull annotations. You can annotate your methods, attributes, or return values with them, and IntelliJ will alert you about possible violations. IntelliJ can even transform those annotations into proper assert checks at compile time. In addition,…

In a way, assertions, pre-conditions, post-conditions, and invariant checks test the production code from the inside. Do we also need to write (unit) tests for them? To answer this question, let me again discuss the difference between validation and pre-conditions. Validation is what you do to ensure that the data is valid. Pre-conditions explicitly state…

Understanding when not to use a practice is as important as knowing when to use it. In this case, I may disappoint you, as I cannot see a single good reason not to use the design-by-contract ideas presented. The development of object-oriented systems is all about ensuring that objects can communicate and collaborate properly. Experience…

We saw that a possible way to simplify clients’ lives is to make your method return a “soft value” instead of throwing an exception. Go back to listing 4.5 for an example. My rule of thumb is the following:

Java does not offer a clear mechanism for expressing code contracts. Only a few popular programming languages do, such as F#. The assert keyword in Java is okay, but if you forget to enable it in the runtime, the contracts may not be checked in production. That is why many developers prefer to use (checked or unchecked)…

Developers are aware of how important input validation is. A mistake in the validation may lead to security vulnerabilities. Therefore, developers often handle input validation whenever data comes from the end user. Consider a web application that stores products for an online store. To add a new product, a user must pass a name, a…

A very important design decision when modeling contracts is whether to use strong or weak contracts. This is a matter of trade-offs. Consider a method with a weak pre-condition. For example, the method accepts any input value, including null. This method is easy for clients to use for the clients: any call to it will…

Let me close with some pragmatic tips on how to use design-by-contract in practice.

Defining clear pre-conditions, post-conditions, and invariants (and automating them in your code via, for example, assertions) helps developers in many ways. First, assertions ensure that bugs are detected early in the production environment. As soon as a contract is violated, the program halts instead of continuing its execution, which is usually a good idea. The…

We mostly use Java for the examples and Java is an object-oriented language, so I must discuss what happens when we use inheritance. Figure 4.2 shows that the TaxCalculator class has many children (TaxCalculatorBrazil which calculates taxes in Brazil, TaxCalculatorNL, which calculates taxes in the Netherlands, and so on). These child classes all override calculateTax() and change the pre- or post-conditions…