Designing classes well

You can now write every kind of class Java offers: abstract classes, interfaces, enums, records, sealed families and lambdas. This lesson is about fitting them together. Two programs can print exactly the same thing, yet one takes a minute to extend and the other takes an afternoon of careful edits. The difference usually comes from a few design habits, and you will try each one on a small program you can run. At the end you will learn the standard way to draw a design on paper.

Has-a: building objects from other objects#

A real car is built from parts: an engine, four wheels, seats, a steering wheel. Nobody says a car is an engine. A car has an engine, and when you press the accelerator, the car hands the hard work to it.

In Java, “has” means a field. A class that keeps other objects in its fields and builds its own behavior out of theirs is using composition. Press Run and watch the Engine object living inside the Car.

It prints Engine: vroom and Swift is moving twice, then Engine started 2 times. The car never starts anything itself. Its drive() method calls engine.start() and then does its own part. Handing a piece of a job to an object you hold is called delegation. The engine keeps its count in a private field, and the car can only read it through getStarts().

The classic mistake: a stack that is a list

Some cases are harder to spot, and this one has caught experienced programmers, including the people who wrote Java's own library. A stack is a pile where you only touch the top, like plates in a canteen. You push a plate onto the top, and you pop the top plate off, so the last plate in is the first one out.

An ArrayList already keeps items in order and can add and remove at the end, so it is tempting to extend it and add push and pop:

Step through it and watch the memory view: the PlateStack object carries a whole ArrayList inside it. It prints green plate and then [sneaky plate, red plate].

The pop worked. The two lines before it are the problem. Because PlateStack extends ArrayList, it inherited every public list method. add(0, ...) slipped a plate in at the bottom, and remove(1) pulled the blue plate out of the middle of the pile. A stack that allows that is no longer a stack. Once a class extends ArrayList, all of its public methods come along, and there is no way to remove one.

With composition, the list becomes a private part, and the class offers only what a stack should do:

It prints green plate, red plate and 2 plates left. Code outside the class can push, pop, peek and ask the size, and nothing else. plates.add(0, "sneaky plate") would not even compile, because this PlateStack has no add method. The class could later store its plates in something other than an ArrayList, and no caller would notice.

Key idea

Prefer has-a. Use extends only when the child really is a kind of the parent and can keep every promise the parent makes.

One class, one job#

Composition builds a class from parts. The next question is how much each part should do. This report card class works:

It prints Emailing parents of Asha and then Report for Asha: average 82.0. Now picture the next few months. The school decides the average should leave out each student's lowest mark. The office wants the report laid out differently. Parents ask for a text message instead of an email. Each request comes from a different person for a different reason, and every one of them means opening ReportCard. An edit for one job can break the others, because they all live in one class.

The single responsibility principle says a class should have one job. To test a class, ask how many different reasons could make you change it. If the answer is more than one, split it, one class per reason:

The output is exactly the same. What changed is where each decision lives. Grades works out the average and knows nothing about text. ReportFormatter decides the layout and knows nothing about email. ReportSender handles delivery. When parents want text messages, you change ReportSender and leave the other two alone, and main wires the three together.

Ask for what you need#

A shop sends a message when an order ships. The first version of its notification service creates its own email sender:

That new EmailSender() welds the two classes together. If the shop wants text messages, someone has to edit NotificationService. There is also no way to check the service without sending a real email, so every test run would land in somebody's inbox.

The fix has two parts. Describe what the service needs as an interface, something that can send a message, and let whoever creates the service hand one in through the constructor:

It prints Email to asha@example.com: Your order is on its way and then Text to 07700 900123: Your order is on its way. NotificationService mentions only MessageSender. Whether a message goes by email, by text or by carrier pigeon is decided in main, and the service never finds out.

An object that a class needs to do its job is called a dependency: the sender is a dependency of the service. Giving a class its dependencies from outside, instead of letting it create them, is called dependency injection. Passing them to the constructor, as here, is constructor injection, the most common form. Behind the long name is a plain idea: the dependency is a constructor parameter.

Notice that the field and the parameter have the interface type, MessageSender, and never EmailSender. That habit is called programming to an interface. You can use it anywhere a variable is declared: List<String> names = new ArrayList<>(); promises only some kind of list, so switching to a different kind later changes one word.

Key idea

Ask for what you need through the constructor, typed as an interface. Let the caller decide which real object to pass in.

Checking the service with a fake

Now the service can be checked without sending anything. A fake is a stand-in written for checking: it implements the same interface, and instead of sending a message it writes down what it was asked to send. The check below has the usual shape of an automated test: arrange the objects, act by calling the method, then assert that the result is what you expected.

It prints PASS, and no email left the building. The service ran its real code, and the fake caught exactly what it tried to send. With JUnit the if would become an assertEquals. Either way, the design is what made the check possible: the first version, the one that built its own EmailSender, cannot be checked like this at all.

Adding behavior without editing old code#

A shop's checkout gives discounts. The first version picks one with an if/else chain on its name:

It prints Price 400, you pay 400, then 360, then 350. Every new offer means opening ring and adding another branch, for a Black Friday sale or a staff discount. The method keeps growing, each edit puts the branches that already worked at risk, and a typo such as "Student" with a capital S quietly charges full price.

The open/closed principle states the goal: code should be open for extension and closed for modification. In plain words, you should be able to add a discount by adding new code, without editing ring at all.

The usual tool is the strategy pattern. Each way of doing a job (each strategy) goes in its own object behind a shared interface, and the code that needs the job accepts any of them:

The three lines are the same as before. ring now takes a Discount and calls apply, with no idea which discounts exist. A new offer is a new class, and Checkout, PercentOff and AmountOff stay exactly as they are, already tested.

Strategies as lambdas

Discount has exactly one abstract method, so it is a functional interface, and a lambda can be a strategy (enums, lambdas and functional interfaces). A short rule does not need a class of its own:

The 400 order costs 200 at half price, 370 with the loyalty rule and 360 with ten percent off. The 250 order is too small for the loyalty rule and stays at 250. The lambdas half and loyalty sit next to a PercentOff object, and ring cannot tell them apart. Use a lambda when the rule is short and needs no fields. Use a class when it needs fields of its own, or a name you will reuse in many places.

Key idea

When one job can be done in several ways, give each way its own object behind one interface. New ways arrive as new classes or lambdas, and the code that uses them stays untouched.

1public class Main {
2    public static void main(String[] args) {
3        Checkout till = new Checkout();
4        till.ring(400, new BigSpender());
5        till.ring(300, new BigSpender());
6        till.ring(250, new BigSpender());
7    }
8}
9 
10interface Discount {
11    int apply(int price);
12}
13 
14class BigSpender implements Discount {
15    public int apply(int price) {
16        // TODO: 50 off when the price is 300 or more
17        return price;
18    }
19}
20 
21class Checkout {
22    void ring(int price, Discount discount) {
23        System.out.println("Price " + price + ", you pay " + discount.apply(price));
24    }
25}

Patterns for making objects#

The checkout still needs someone to write new PercentOff(10). In a real shop the customer types a coupon code, and some code has to turn "STUDENT" into the right Discount. If that decision is copied into every screen that accepts codes, adding a code means hunting down every copy.

A static factory method

A static factory method is a static method whose job is to create an object, including the decision about which class to create. The caller gets back the interface type and never sees the choice. An interface may contain static methods (since Java 8), and you call them on the interface name, so the factory can live inside Discount itself:

It prints STUDENT -> PercentOff -> 360, WELCOME -> AmountOff -> 350 and BOGUS -> NoDiscount -> 400. The call getClass().getSimpleName() asks an object for the name of its real class, and it shows that the factory chose a different class for each code. An unknown code gets a NoDiscount, so a mistyped coupon charges full price instead of crashing the checkout. The rule that STUDENT means ten percent off now lives in one place, and a new coupon is one new line in forCode.

You have used static factories from the library already. List.of(...) is a static method on the List interface that hands back a list whose class you never name, and String.valueOf(42) makes a String from a number. Compared with a constructor, a factory method can have a name that says what it does, can return any subclass of its return type, and can hand back an object it made earlier instead of a new one. You will see that last trick in the next lesson, with Integer.valueOf in wrapper classes and autoboxing.

A builder

Some objects have many settings, most of them optional. A pizza has a size, maybe extra cheese, maybe a stuffed crust, and any number of toppings. With constructors alone, calls start to look like this:

Which true is the cheese? Swap two of them by mistake and the code still compiles, and someone gets a crust they did not order. The builder pattern fixes this. A helper object collects the settings one named method at a time, and a final build() call creates the real object:

Read main like a sentence: start a large pizza, add extra cheese, add mushrooms, add olives, build it. It prints large pizza with extra cheese, topped with mushrooms and olives and then small pizza. (String.joinglues the toppings together with “ and ” between them.) The chain works because every builder method ends with return this;, handing back the same builder so the next call can follow with a dot. StringBuilder's append works the same way (strings).

Pizza's constructor is private, so the only way to get a pizza is through Pizza.Builder, a static nested class. That makes build() the natural place to check the settings before the object exists, for example refusing a size that is not on the menu. The pizza also copies the toppings list with List.copyOf; the next section explains why that copy matters.

The JDK uses builders where objects have many options. The HTTP client added in Java 11 builds a web request like this: HttpRequest.newBuilder(URI.create("https://example.com")).timeout(Duration.ofSeconds(10)).GET().build(). You will write that for real in talking to the web.

Objects that never change#

A String never changes once it exists: toUpperCase() hands back a new string and leaves the old one alone (strings). You can write classes that behave the same way. An immutable object gets all of its values in its constructor and keeps them for the rest of its life. The recipe:

• Make every field private and final, so nothing can reassign it after the constructor.
• Write no setters, and no other method that changes a field.
• Mark the class final, so no subclass can add methods that change things.
• If a field holds something that can change, such as a list, copy it on the way in, and never hand out a version that others can change.

The last rule is the one people forget. This playlist follows the first three:

It prints Road trip: [Intro, Ocean, Uninvited]. finalstopped the field from being pointed at a different list, but the playlist's field and main's songs variable point at one and the same ArrayList (object references), so a change made through one name shows through the other. This is the subtlety that static and final promised: final freezes the reference, not the object it points at.

The fix is a defensive copy, a private copy that nobody outside can reach:

It prints Road trip: [Intro, Ocean], and then Road trip: [Intro, Ocean, Finale] for the longer playlist. The constructor stores List.copyOf(songs), so adding Uninvited afterwards changes only the caller's list. List.copyOf (Java 10) makes a copy that cannot be changed, like the lists that List.of makes, which is why songs() can return the field itself: calling add on it would stop the program with an UnsupportedOperationException. To “change” a playlist you call withSong, which builds a new Playlist and leaves the old one as it was, the same way toUpperCase() treats a string.

Why immutable objects are easy to share

Nobody can change an immutable object, so you can hand the same one to every part of a program that wants it. No part needs a private copy, and no part has to worry that another will change it behind its back. It works like a printed timetable pinned to a wall: everyone reads the same sheet at once, and it tells all of them the same thing.

That pays off twice later in the course. A key in a HashMap must not change after it goes in, or the map can no longer find it (HashMap and HashSet). And objects shared between threads need no locks when they cannot change (safe sharing).

A record gives you most of the recipe for free: the class is final, its fields are private and final, and it has no setters. It cannot know that a component is a list you meant to copy, though, so the copy goes in a compact constructor:

It prints Playlist[name=Road trip, songs=[Intro, Ocean]] and 2. The song added afterwards never reached the record.

One builder, two pizzas

Back to the pizza builder, trimmed down to its toppings to keep it short. This time one builder is used twice, and the second order adds a topping before building again.