The previous lesson ended with a diagnosis: BiblioTech's domain can no longer be corrupted from outside, but the public surface of its classes has grown out of control. Loan exposes more than twenty methods, among them a getEmployeeDoNotUse() whose very name confesses that it should not exist. Encapsulation answers the question how do I hide what is inside; what is left is the harder one: what deserves to be outside. That is the territory of abstraction, OOP's fourth pillar and, unlike the other three, not a language mechanism but a design discipline: keeping what is essential to the problem being solved and discarding everything else. A metro map is a masterful abstraction —it lies about distances, ignores geography and yet gets you to your destination better than a scale map does—. This lesson teaches you to design like that: to decide what you expose, not to mix levels inside a method, to document contracts and to recognise both leaky abstractions and the opposite vice, abstracting what nobody asked for.

1. Abstraction as a design discipline
2. Abstraction versus encapsulation
3. Levels of abstraction and why they must not be mixed
4. Refactoring: separating the rule from the presentation
5. Design by contract: preconditions, postconditions and invariants
6. The vocabulary of the domain
7. Separating the what from the how
8. Minimal public API and the cost of exposing too much
9. Leaky abstractions
10. Over-abstraction and YAGNI
11. The missing mechanisms: interfaces and abstract classes
12. Common Mistakes and Tips
13. Exercises

To abstract is to keep what is essential and discard what is accidental. The key phrase is "for the problem": there is no absolutely correct abstraction, only the one that is correct for a purpose.

The same physical book is abstracted differently depending on who models it:

None is more "true" than the others. A Book in BiblioTech has no weight because BiblioTech does not care about weight, and adding it "just in case" would pollute the model.

Hence the first question you must ask yourself about any class:

What does this object need to know and do for the problem we are solving? Everything else is surplus.

The two concepts are constantly confused because they collaborate, but they answer different questions:

You can have one without the other, and both failures are real:

• Good encapsulation, bad abstraction: every field private, but with thirty validated getters and setters. Nothing gets corrupted, but the class means nothing; it is a spreadsheet with Java syntax.
• Good abstraction, bad encapsulation: a magnificent public API —lend(), returnItem(), calculateFine()— alongside public fields that let you bypass it. The design is right and it is not enforced.

You need both. Abstraction decides which doors there are; encapsulation guarantees that there are no others.

A program has layers of detail, from the concept to the bit:

The rule, known as the single level of abstraction principle:

Inside a single method, every statement should belong to roughly the same level.

Why? Because reading a method that jumps between levels forces you to switch mental frames on every line. A method that says "register the return, and by the way here is the VAT formula and the receipt's column width" cannot be skim-read: it has to be read in full, every time.

This is what mixing looks like, and you will probably recognise the style because it is exactly that of your module 2 main:

The concrete problems, beyond aesthetics:

1. The rule cannot be reused. If another point in the program needs the fine, it has to copy the formula or call this method and put up with the console receipt.
2. It cannot be tested. To verify the calculation you have to capture standard output (module 11).
3. The channel cannot be changed. If tomorrow the receipt is a web page or a PDF, the business logic has to be rewritten along with the format.
4. The €20 cap is duplicated. It already lives in Material.MAX_FINE, and here it appears as a literal. Two truths for one fact.
5. It violates the Law of Demeter three times with loan.getMaterial().getX().

Let us rewrite the previous method, distributing each line to its level.

Level 3, business rules: they are already in the domain. Loan.registerReturn(int) computes the fine, marks the loan, releases the material and discounts the employee (lesson 03-07). Nothing new needs writing.

Level 1, presentation: a separate class, outside the domain.

Level 4, the use case: it coordinates, it does not calculate or print.

Two lines. And each one at its own level.

Compare before and after:

Note the new package, presentation. BiblioTech's structure begins to reflect its abstraction levels:

This separation is the seed of the layered architecture you will see in full in module 12.

An abstraction is a promise: "call me this way and I will give you this back". The more explicit the promise, the less room for misunderstanding. Design by contract formalises that promise in three parts:

Java has no syntax for contracts (other languages do), so they are documented with Javadoc, which you already know from module 1:

Advantages of writing it:

• The caller knows what they must satisfy without reading the implementation. That is, literally, the definition of abstraction.
• It forces you, as you write it, to think about the edge cases: what happens if it had already been returned? And if the days are negative? Many contracts reveal design gaps before they exist as bugs.
• The IDE shows it when autocompleting, so the contract travels with the code.

And a practical guide about preconditions: there are two strategies, and it is worth choosing consciously.

Checking everything everywhere multiplies the code without adding safety: if a private method is called only by two other methods of the same class that already validated, validating again is noise.

A good abstraction speaks the language of the business. If a Nexus Software librarian read your code over your shoulder, they should recognise the words.

Compare:

The idea of using a single vocabulary shared between the code, the documentation and the conversations with the business is called the ubiquitous language. Its practical rule is simple: if the business says "fine", the code says fine, not penaltyAmount, charge or levy.

BiblioTech's vocabulary, which you have been using since module 1, is exactly this: title, author, isbn, available, daysLate, fine, severity, reference, lend, returnItem. No technical word has crept into the domain, and that is why loan.registerReturn(20) is understandable without opening the class.

The tangible result of a good abstraction is that the caller stops knowing how things are done.

Walk through what has happened to the fine calculation over the course:

The definitive test that the what and the how are separated is this: can you change the implementation without touching the callers? If Nexus Software decides tomorrow that the rate should be progressive —€0.25 for the first seven days and €0.50 from the eighth on—, how many files have to be touched?

One file. Neither main, nor the receipt, nor Loan finds out. That is what abstraction buys, and it is the reason its cost in indirection is worth paying.

A class's public API is everything others can use: public methods and fields, and its constructors. It is its promise to the outside world.

And that promise has a cost that almost nobody calculates while writing the code:

The golden rule:

It is easy to add a public method later; it is extremely expensive to remove one. When in doubt, leave it private.

Applied to Loan, let us review its current API with a severe eye:

With that pruning, Loan goes from more than twenty public members to fourteen, and none of them lets you unbalance the system. Exercise 1 asks you to take it all the way.

A leaky abstraction is one that promises to hide a detail but forces you to know it anyway. The law stated by Joel Spolsky says, with some black humour, that all non-trivial abstractions leak: the point is not to avoid it entirely, but not to make it worse.

Examples you have already seen or will see:

How to reduce leaks:

• Return immutable types or copies instead of internal state.
• Do not expose implementation types in the public signature. If tomorrow you want to change an array for a list, your signature should not force you to break anyone.
• Document what leaks when you cannot avoid it. A documented leak is a contract; a silent leak is a trap.

The opposite vice exists too, and in the hands of somebody who has just discovered OOP it is the more frequent one: abstracting what nobody asked for.

Symptoms of over-abstraction:

• Five-level hierarchies for three concrete cases.
• Classes called AbstractBaseGenericProcessorFactory.
• Configuration parameters that are always the same value.
• Extension points "in case one day" that are never used.
• One interface per class, with a single implementation.

The principle that contains it is called YAGNI: You Aren't Gonna Need It. Formulated as a rule:

Do not add flexibility until you have two real cases that require it. With one, it is guesswork.

Applied to BiblioTech, an honest contrast:

And a warning about balance: over-abstracting is an expensive but visible mistake; under-abstracting produces module 2's two-hundred-line main, which is expensive too. The professional answer is not to pick an extreme, but to refactor when the second case appears. That is exactly what you have done: Material did not exist until magazines and DVDs turned up.

This whole lesson has talked about abstraction as a discipline: what to model, what to expose, how to separate levels. But Java also offers two language mechanisms designed specifically to materialise it, and both arrive in the next module:

Two concrete shortcomings of the current design that those mechanisms will solve:

First: Material can be instantiated. Today nothing stops you writing new Material("Something", "REF-1", true), and that means nothing: the library has books, magazines and DVDs, not "generic materials". An abstract class forbids it at compiler level.

Second: getType() returns "Material" by default. If somebody creates a new subclass and forgets to override it, "Material" will appear in the listings without anyone detecting it. An abstract method turns that omission into a compile error:

Take this away: in module 4 you will learn how they are written; in this lesson you have learned why they exist. The order matters, because whoever learns interface without having understood abstraction ends up creating one interface per class without knowing what for.

• Confusing abstraction with encapsulation. Abstraction is what I expose; encapsulation is how I hide it. The table in section 2 separates them.
• Mixing levels in a method. Business rules and printf in the same block is the most frequent mistake in beginners' code, and the most expensive to undo.
• Putting presentation in the domain classes. A Book that knows how to print its card on the console cannot be reused on a website. Presentation goes in another package.
• Making things public "just in case". Every public method is a permanent commitment. Start private and raise it only when somebody genuinely needs it.
• Generic names. Manager, Processor, Helper, Data, Info, Util. If you cannot give a class a concrete name, you probably do not yet know what it is.
• Documenting the how instead of the what. A Javadoc saying "walks the array and sums" becomes obsolete the moment you change the implementation. Document the contract: what it receives, what it returns, what it guarantees.
• Abstracting without a second case. YAGNI. Wait for the second format, the second database, the second file layout to show up.
• Tip: describe the method in one sentence. If you need "and" or "also", the method does two things and probably mixes levels.
• Tip: read your code as if you were the librarian. If l.registerReturn(20) is understandable and dm.process(i, 20) is not, you know which one is well named.
• Tip: the change test. For every design decision, ask yourself what would have to be touched if the rule changed. The fewer files, the better the abstraction.

This is the lesson's central exercise. Take the Loan class as it ended up in 03-07 and reduce its public surface to the necessary minimum.

1. List all its current public members.
2. For each one, decide: keep, make private or remove, justifying the decision in one sentence.
3. Remove getEmployeeDoNotUse() and replace its uses with appropriate delegations.
4. Write the complete Javadoc, with preconditions and postconditions, of the three methods you consider the class's core.
5. Check that BiblioTechApp and ConsoleReceipt still work with the reduced API.

Refactor this method by distributing each line to its level. It should end up with: the rules in the domain, the presentation in ConsoleReceipt and the use case reduced to three or four readable lines.

For each proposal from a colleague, decide whether it is justified, whether it is over-abstraction (YAGNI) or whether it is a leaky abstraction. Justify it in two or three sentences and, where appropriate, propose the alternative.

1. Creating PhysicalMaterial and DigitalMaterial as intermediate levels between Material and the three current classes.
2. Adding to Material a method public String[] getInternalFields() returning the raw state "for debugging".
3. Extracting the four business constants to a BusinessRules class with static methods.
4. Adding to Loan a boolean silentMode parameter in registerReturn so as not to print warnings.

Solution 1

1 and 2. Member-by-member review:

3. Replacing the two removed getters. Where l.getMaterial().getType() or l.getEmployeeDoNotUse().getIdentifier() used to be written, delegations are added:

They are three trivial methods, and that is the usual objection: "I have swapped one getter for three". The answer is that now the class controls what can be known about the employee, and nobody can call registerLoan() behind its back. One open door has been swapped for three barred windows.

4. Javadoc of the three core methods:

Notice a detail in the third one: documenting "accepts nulls and answers false" is a design decision. Without it, every caller would have to check on their own, or discover the behaviour through NullPointerExceptions.

5. ConsoleReceipt already used only delegations (getMaterialTitle(), getEmployeeName()), so it still compiles unchanged. That is the sign the pruning was right: what was removed was not used by anyone legitimate.

Solution 2

The original method mixes four levels: interaction with the user, rule validation, creation of the loan and presentation of results. It is distributed like this.

Domain. The combined check already exists (Loan.canBeLent) and the due day is computed by the constructor. No new rules need adding, only a method that explains why it cannot be lent:

Presentation. All the text, in ConsoleReceipt:

Interaction with the user. That is presentation too, so the confirmation is isolated:

Use case. It coordinates and nothing else:

Improvements achieved, beyond the length:

Solution 3

1. PhysicalMaterial / DigitalMaterial — over-abstraction (YAGNI). Today the catalog's three materials are all physical, so DigitalMaterial would have no subclass and PhysicalMaterial would contribute neither a field nor a method that Material does not already have. It would add a level to the hierarchy —exactly what 03-05 advises against— in exchange for nothing. Alternative: wait. The day an on-demand video course arrives, with its own access rules, the intermediate level is introduced with a real case in hand.

2. getInternalFields() — a leaky abstraction, and a serious one. A method returning "the raw state" publishes the internal representation as part of the API: as soon as somebody uses it in production "just for a log", you will no longer be able to change the fields without breaking it. It also invites parsing the output instead of using the methods. Alternative: a properly overridden toString(), which is exactly what this is for and is studied in the next lesson. Debugging is done with the debugger (02-05), which sees private fields without needing to expose them.

3. A BusinessRules class with the constants — it depends, and that is why it is the most interesting. As formulated, it is debatable: the constants already live in Material, the class that uses them, and moving them into a separate container would take them away from their meaning; besides, getLoanDays() and getDailyRate() are polymorphic per format, so a single class could not represent them without going back to a switch on the type, that is, undoing what was achieved in 03-06. It would be justified if those values had to be read from a configuration file or vary by site, because then there would be a second real case. Today there is not. Verdict: YAGNI, with a review date.

4. A boolean silentMode parameter — wrong for two reasons. The first is the one from the good-practice section of 03-03: a boolean parameter at the call site says nothing (registerReturn(20, true) is unreadable). The second is deeper: its existence proves the abstraction is broken, because a domain method should not print anything, and therefore there should be nothing to silence. Alternative: have registerReturn write nothing to the console at all and return the information —it does, it returns the fine—, letting the presentation layer decide what to show and when. "Silent mode" disappears because the problem disappears.

A pattern worth recognising in all four answers: proposals 2 and 4 are patches over symptoms; once the abstraction levels are separated, neither of them has any reason to exist.

You have completed the four pillars. Abstraction is not a keyword you type, but the discipline of keeping what is essential to the problem, and that is why the same book is modelled differently in a library, a shop and a printing house. You know how to distinguish it from encapsulation —what I expose versus how I hide it— and why you need both. You have learned to detect and correct the mixing of abstraction levels, the vice that turned your module 2 main into an unreadable block, separating the business rules into the domain, the presentation into its own package and leaving the use case at two lines. You know how to write contracts in Javadoc with preconditions, postconditions and invariants, and to choose consciously between validating defensively or documenting and trusting. You model with the vocabulary of the domain, so that a Nexus Software librarian would recognise your code. You have verified that separating the what from the how pays for itself: changing the fine policy to a progressive rate affects one file. And you have judgement about both extremes: the minimal public API versus the permanent cost of exposing too much, leaky abstractions and the YAGNI that reins in hierarchies invented for cases nobody asked for.

You also know what is missing: the two mechanisms with which Java materialises all of this —interfaces (04-01) and abstract classes (04-02)— arrive in the next module, and now you will know what they are for, which is exactly what is missing from anyone who learns them too early.

One lesson remains to close the module, and it is the one that makes your objects behave as first-class citizens of the language. Right now, printing a Book produces an unreadable Book@1b6d3586, and two copies with the same ISBN are considered different because equals compares memory addresses. In The Object Class: equals, hashCode and toString you will learn the role of the root of the whole hierarchy, the complete equals contract with its five properties, why hashCode must always be overridden alongside it and what breaks if you do not. And you will keep the promise that closes module 2: the three loose variables highestDelay, highestDelayEmployee and highestDelayBook will finally become a single coherent object.