When the previous lesson closed, a crack was left open in BiblioTech: Material is still an instantiable class. Nothing stops you writing new Material("Something", "REF-1", true) and getting an object that is not a book, nor a magazine, nor a DVD; an object with no author, no number and no duration, which answers "Material" when you ask for its type. It is an object that should not exist, and its existence is an accident of the design, not a decision.

The abstract class closes that door. It is a class that explicitly declares itself incomplete: it serves as a common base — with fields, constructor and shared code — but it cannot be instantiated, and it can force its subclasses to implement the methods only they can decide. Where the interface says "this is what you must know how to do", the abstract class says "this is what is already done, and this is your part". By the end of this lesson, Material will be abstract, calculateFine will be written once only for the whole system through the Template Method pattern, and you will be able to choose with judgement between interface, abstract class or — the most frequent option in professional design — both at once.

1. abstract on classes: what it means and what it prevents
2. Abstract methods: the obligation that is inherited
3. An abstract class WITH state: fields, constructor and concrete methods
4. What is the constructor of a class that is never instantiated for?
5. An incomplete subclass must also be abstract
6. Interface versus abstract class: the full table
7. A practical decision rule
8. The Template Method pattern
9. Combining the two: AbstractXxx
10. BiblioTech: Material becomes abstract
11. Refactoring Book, Magazine and Dvd
12. Common Mistakes and Tips
13. Exercises

The abstract modifier applied to a class declares that the class is conceptually incomplete: it represents a general idea of which no concrete specimens exist.

With that single word, this stops compiling:

It is important to understand what is forbidden and what is not:

That last point is surprising: a class can be abstract without a single abstract method. It is perfectly valid and sometimes useful: you mark it abstract simply to declare that instantiating it makes no sense, even though it is technically complete.

The immediate gain is in modelling. "Material" is an abstraction: in the Nexus Software library there are books, magazines and DVDs, but there are no plain "materials". The code starts telling the truth about the domain, and the compiler enforces it.

An abstract method is a method declared without a body, ending in a semicolon, which the class promises will exist but refuses to implement:

The rules are strict and it is worth having them all together:

• An abstract method can only exist inside an abstract class (or an interface). If you put an abstract method in a normal class, the error is missing method body, or declare abstract.
• Every concrete subclass must implement them all. If one is missing, it does not compile.
• abstract is incompatible with private, static and final. With private because the subclass would not see it; with static because static methods are not polymorphic (03-06); with final because final forbids exactly what abstract demands.

The difference from the previous design is one of guarantees. Compare the two versions of getLoanDays:

With the first, if tomorrow you add AudioBook extends Material and forget its term, the program compiles and silently applies 15 days. The error is not detected until an employee complains about a miscalculated fine. With the second, it does not compile: the error arrives at second zero, with the method name and the line number.

This is the difference between a default value and a contract. The default value hides the oversight; the contract reports it.

Here is the essential difference from an interface: an abstract class can store data. And therefore it can write genuinely shared code, not just code that leans on calls to the contract.

The five numbered sections sum up the split: the abstract class provides what is common (2, 3, 4), and delegates what varies (5). No interface can offer points 2 and 3.

It is the direct answer to a question you may have asked yourself in 04-01: if a default method can have a body, why do I need an abstract class? Because lend() needs the available field. A default cannot have it: it would have to call isAvailable() and a hypothetical setAvailable(), widening the contract with a mutator that breaks the encapsulation you looked after so carefully in 03-07. The abstract class stores the field, keeps it private and exposes only the business operations.

It is the classic doubt: if new Material(...) is forbidden, what is the point of that constructor?

The answer lies in the initialisation chain you studied in 03-04: a subclass constructor always invokes its superclass's constructor first, explicitly with super(...) or implicitly. That constructor does run, it simply never runs on its own.

So the constructor of an abstract class has three very concrete jobs:

1. Initialising the common state the subclass must not touch (the fields are private).
2. Centralising validation. The title and reference checks are written once and applied by Book, Magazine and Dvd, with no way to skip them.
3. Guaranteeing the invariants of the common part from the object's first instant of life.

And there is a design decision in the signature: declaring it protected instead of public. In an abstract class, public on the constructor is misleading — it suggests someone can call it from outside, and they cannot — whereas protected says exactly the truth: this constructor exists for the subclasses. It is the convention the JDK itself follows.

What happens if a subclass implements only some of the abstract methods? It remains incomplete, and Java forces you to say so:

If you removed the abstract from ReferenceMaterial, the compiler would say:

The obligation is inherited downwards until somebody fulfils it. This allows multi-level hierarchies where each level solves what it knows and leaves the rest pending:

Atlas is the first concrete class in the branch: it implements the only thing still pending and can now be instantiated.

This is the table announced in 04-01. Study it in full: it covers the six dimensions that really decide.

Three rows deserve extra comment:

API evolution. It is asymmetric and often confused. In an interface, adding an abstract method breaks all implementers, but a default breaks nobody. In an abstract class, adding a concrete method is safe (all subclasses inherit it), but adding an abstract one breaks all concrete subclasses. Each has its own safe way to grow.

Coupling. It is the decisive argument and often the forgotten one. If you force your users to extend your abstract class, you spend their only inheritance slot and they will not be able to extend anything else. An interface costs nothing in that respect. That is why the professional recommendation is: the public type is the interface; the abstract class is optional help.

protected members. An abstract class can offer its subclasses tools the rest of the world does not see. An interface cannot: everything it declares is public. When you need that "private channel" towards the subclasses, the abstract class is the only option.

And in three memorable sentences:

• Interface when you define what can be done and you want classes that share no family to sign it. It is the default option: always start here.
• Abstract class when you share state, constructor and real code between classes that do form a genuine family.
• Both when you want the two things: the interface as the public type and the abstract class as an optional base implementation. It is what the JDK does and what you will do in BiblioTech.

Now comes one of the most powerful uses of abstract classes. Look at this method, which has existed in your Material since module 3:

The interesting thing is its structure: it defines the invariable skeleton of the algorithm — compute the delay, multiply it by the rate, apply the cap — but delegates to getDailyRate(), which each subclass implements its own way. The skeleton is written once; the variable steps, as many times as there are formats.

That is exactly the Template Method pattern: a concrete method in the base class defines the sequence of steps, and the steps that vary are abstract methods the subclasses fill in.

And there is a key detail that makes the pattern solid: the template method is declared final.

Why final? Because the €20 cap and the formula are Nexus Software policy, not a decision for each format. Without final, a Dvd could override calculateFine and skip the cap. With final, the compiler prevents it: subclasses can only influence the result through the gaps the template offers them.

Splitting responsibilities this way has a name in the literature: the Hollywood principle — "don't call us, we'll call you". The subclass does not control the flow; it merely fills in the gaps the base class reserves for it.

This pattern is formally named because it is one of the classic design patterns. Here you have discovered it naturally, by writing the class that was needed; in lesson 12-02 you will see it formalised alongside Strategy, Factory, Observer and the rest, with its full description and its alternatives.

You almost never choose between interface and abstract class: you use both, in layers.

• The interface is the public type. What variables, parameters and return values declare.
• The abstract class implements the interface and offers a partial base with the repetitive work already solved.
• The concrete classes extend the base and only write their own part.

And whoever does not want the base implements the interface directly. The help is optional, and that is the whole point.

The JDK is built this way, and the naming convention gives it away:

ArrayList is an AbstractList and is a List. But you can write your own List without touching AbstractList. All these classes arrive in module 5; what matters today is recognising the structural pattern.

In BiblioTech the split works out exactly the same:

MeetingRoom implements Lendable without going through Material: it does not want the base, and it does not need it. It is the proof that the help is optional.

This is the final state of the class after applying everything you have learned.

Four changes that deserve attention:

1. abstract class: new Material(...) no longer compiles.
2. protected constructor: it tells the truth about who can call it.
3. getType(), getLoanDays() and getDailyRate() are abstract: the filler constants LOAN_DAYS = 15 and DAILY_RATE = 0.25 disappear from Material. Each format declares its own and nobody can forget them.
4. calculateDaysLate, calculateFine and classifySeverity are final: they are company policy, not negotiable per subclass.

And notice describe(): it now calls getType(), an abstract method. A concrete method of the base class invoking a method that does not exist yet. It works thanks to the dynamic dispatch of 03-06: at run time, this is always a concrete object, and its getType() is implemented.

Now each format declares its three decisions, and none can be omitted.

Testing the result:

A single calculateFine, written once only, producing three different and correct results. And the commented-out line is the main improvement: the meaningless object can no longer be created.

Putting an abstract method in a non-abstract class. The error is missing method body, or declare abstract. If a method cannot be implemented in the base class, the base class is abstract. There is no middle ground.

Trying new on the abstract class. Material m = new Material(...) does not compile. What is legal, and confuses many people, is Material m = new Book(...): the abstract class is a perfectly valid type to declare.

Declaring the constructor public in an abstract class. It compiles, but it lies: it suggests an access that does not exist. Use protected.

Combining abstract with final, static or private. All three combinations are contradictory and the compiler rejects them. abstract means "it must be overridden"; final means "it cannot be", static means "it is not polymorphic" and private means "it is not visible".

Forgetting that a partial subclass must remain abstract. If you implement two of three abstract methods, the resulting class is still incomplete.

Choosing an abstract class out of habit. It is the most expensive design trap in the module. By forcing extends, you spend your users' only inheritance slot. Always start with the interface and add the abstract base only if there is state or real code to share.

Calling an abstract (or overridable) method from the base constructor. It is a subtle and serious mistake: when the Material constructor runs, Book's fields are not yet initialised. If Material called in its constructor a describe() that uses author, you would get null. Rule: from a constructor, invoke only private, static or final methods.

Tip: final on the template method. That is what turns a hierarchy into a real Template Method. If the skeleton is not final, any subclass can bypass the policy.

Tip: document the contract of every abstract method. The Javadoc of an abstract method is the only place where you can tell whoever implements it what is expected: what it must return, what ranges are valid, whether it may return null. It is design by contract (03-08) applied at the exact point where it is needed most.

Add to BiblioTech a format AudioBook extends Material with its own field durationHours (double) and a method getNarrator(). Term: 10 days. Rate: €0.15/day. Notice channel: "email" (the inherited one). Check that the compiler forces you to implement the three abstract methods, and integrate the new format into the catalog array without touching the loop that walks it.

Create an abstract class MaterialReport in the presentation package with:

• A method public final String generate(Material m, int elapsedDays) returning header() + body(m, days) + footer().
• header() and footer() as concrete methods with a default implementation.
• body(Material, int) as an abstract method.

Create two subclasses: BriefReport (one line with title and fine) and DetailedReport (title, type, term, delay, fine and severity, one per line). Check that the skeleton is written once only.

For each case, decide whether you would use an interface, an abstract class or both, and justify it in one sentence:

1. Every BiblioTech object that can be exported to a text file.
2. The common base of three employee types (Internal, External, Intern) that share name, identifier and the loan limit, but with a different maximum.
3. The ability to compare two materials in order to sort them.
4. A loan catalogue with different future implementations: in memory, in a file and in a database.

Solution 1

If you leave out, for example, getDailyRate():

And the integration:

The loop has not been touched. A new format costs one class and one line of data: zero modifications to the existing logic. And what is new compared with module 3 is that the compiler has guaranteed that you declared term, rate and type. With the old version of Material, forgetting the rate would have silently charged €0.25/day.

Solution 2

Four design details: generate is final (the structure is not negotiable); body is protected because it is an extension point for the subclasses and not part of the public API; header and footer are concrete and protected, so a future subclass can override them without being forced to; and the variable is declared MaterialReport, not BriefReport, so switching reports costs one word.

Solution 3

Case 4 is the professional archetype and the one you will see again and again from module 5 onwards: the interface defines the type, the abstract class offers optional help, and the concrete classes choose.

You have completed the pair that holds up design in Java. You know that abstract on a class declares it conceptually incomplete and that it prevents new, without preventing you from using it as the type of variables, parameters and arrays. You know that an abstract method is an obligation passed downwards until a concrete subclass fulfils it, and — most importantly — why that obligation is worth more than any filler implementation: it turns a silent oversight, which surfaces weeks later as a miscalculated fine, into an instant compilation error.

You understand what an abstract class offers and an interface never will: instance fields, a constructor and protected members. You know what the constructor of a class that is never instantiated is for — it always runs via super(...), centralises the common validation and guarantees the invariants of the shared part — and why it is declared protected. You have the full comparison table between interface and abstract class, including the row that weighs most in practice: the abstract class consumes the only inheritance slot of whoever uses it, and that is why the professional path always starts with the interface.

And you have discovered the Template Method by writing it, not by reading it: a final method that fixes the skeleton of the algorithm and delegates the variable steps to abstract methods. That is what lets the fine formula — delay times rate, capped at €20 — exist once only in the whole of BiblioTech and produce different, correct results for a book, a magazine, a DVD and any format you add tomorrow. That pattern is formalised in 12-02. Finally, you can recognise the JDK's AbstractXxx pattern, where interface and abstract class do not compete but share the work: the former is the public type, the latter optional help.

BiblioTech is left with an honest hierarchy: Material is abstract and signs Lendable and Notifiable; Book, Magazine, Dvd mandatorily declare their type, their term and their rate; and MeetingRoom proves that you can sign the contract without joining the family.

But look at a piece you have been carrying since 03-07 and which is still unsatisfying: the incidents of a Loan are a String[] of loose texts. A real incident has a day, a reason and a severity, and deserves to be a type of its own. Now then, a top-level class, in its own file, for something that only makes sense inside a loan? In lesson 04-03, Inner Classes, you will see the four kinds of nested class Java offers, you will learn when each one is the right choice — including the one that causes real memory leaks in production — and you will turn those loose strings into a Loan.Incident with a name, a structure and encapsulation of its own.