THE DESIGN SAID `Officer ◁── CounterOfficer`. Whether that should actually be inheritance in code is a separate question, and the default answer is no. WHAT INHERITANCE ACTUALLY COSTS: · THE SUBCLASS DEPENDS ON THE SUPERCLASS'S IMPLEMENTATION, not merely its interface. A change to a protected method can break every subclass — the FRAGILE BASE CLASS problem. This is the strongest coupling any two classes can have. · IT IS FIXED AT COMPILE TIME. An object cannot change its class, so behaviour that varies over an object's lifetime cannot be modelled by subtyping. · IT IS SINGLE (in most languages), so you get one axis of variation. Two independent axes — payment method and notification channel — cannot both be inheritance hierarchies without a combinatorial explosion of classes. · IT BREAKS ENCAPSULATION between the two classes: `protected` is a promise to every future subclass. WHEN INHERITANCE IS RIGHT: when the relationship is genuinely IS-A and satisfies the LISKOV SUBSTITUTION PRINCIPLE — anywhere the supertype is expected, the subtype must work without the caller knowing. THE CLASSIC VIOLATION: class Rectangle { setWidth(w); setHeight(h); } class Square extends Rectangle { … } A Square must keep width and height equal, so `setWidth(5)` then `setHeight(3)` behaves differently for a Square than the Rectangle contract promises. Code written against Rectangle breaks when handed a Square. THE MATHEMATICAL "IS A" IS NOT THE PROGRAMMING "IS A" — a square is a rectangle in geometry and not a subtype of a mutable Rectangle in code. COMPOSITION — the default alternative: ✗ class PriorityApplication extends Application { // overrides half of Application's behaviour } ✔ class Application { private final ProcessingPolicy policy; // composed Duration targetTurnaround() { return policy.turnaroundFor(category); } } Now the policy can differ per instance, can change at run time, and can be tested alone. That is the Strategy pattern, and it is what "favour composition over inheritance" means concretely. THE PRACTICAL RULE: USE AN INTERFACE for "can be used as" — a contract with no shared implementation USE COMPOSITION for "is configured with" or "varies by" USE INHERITANCE only for genuine specialisation where the subtype adds to rather than replaces the supertype's behaviour, and where LSP holds AND CONSIDER `final` on classes not designed for inheritance — permitting it accidentally is how fragile hierarchies form

PACKAGE STRUCTURE — the code-level realisation of the layering from ACtE0805, and a decision the class diagram does not make. TWO COMPETING SCHEMES: PACKAGE BY LAYER com.nec.controllers — every controller com.nec.domain — every entity com.nec.repositories — every repository ✔ mirrors the architecture diagram ✘ a single feature is spread across every package, so a change touches four directories; and nothing can be made package-private, because collaborators live elsewhere — so everything is public and the layering is advisory PACKAGE BY FEATURE com.nec.licensing.issue — handler, policy, tests com.nec.licensing.payment — handler, Payment, gateway com.nec.reporting — … ✔ a change lives in one directory ✔ genuinely allows package-private members, so a class can be internal to a feature and INVISIBLE to the rest of the system — real enforcement rather than convention ✘ shared domain concepts need a home, and the layering is less visible at a glance → MOST CURRENT PRACTICE FAVOURS BY FEATURE, with layering enforced inside each feature package and by architecture tests. The decisive argument is the package-private one: by-layer packaging makes it impossible to hide anything. CONSTRUCTION — what to do when a constructor has too many parameters: THE PROBLEM new Application(no, date, district, category, clock, null, null, null, null, 0) unreadable, and adding a field changes every call site. OPTION 1 — SEVERAL CONSTRUCTORS (telescoping). Works for two or three; becomes unreadable beyond that, and cannot distinguish two optional parameters of the same type. OPTION 2 — A STATIC FACTORY METHOD with a meaningful name: Application.newSubmission(no, date, district, category) Application.rehydrate(snapshot) // from storage ✔ the name says what kind of construction this is, which a constructor cannot ✔ can return a subtype or a cached instance OPTION 3 — A BUILDER, for genuinely many optional fields: Application.builder() .number(no).appliedOn(date) .district(d).category(c) .build(); // validates the invariants HERE ✔ readable, order-independent, and `build()` is the single validation point ✘ more code; unnecessary below about four or five parameters OPTION 4 — A PARAMETER OBJECT, when the parameters form a concept: `new Application(ApplicationDetails details)`. Often the best answer, because the new type turns out to be a domain concept nobody had named. THE RULE THAT MATTERS WHICHEVER IS CHOSEN: THE INVARIANTS MUST STILL BE VALIDATED IN EXACTLY ONE PLACE. A builder whose `build()` does not validate has merely moved the problem and lost the constructor's guarantee. LANGUAGE IDIOM — the same design, different code: CONCERN JAVA / C# PYTHON ───────────────────────────────────────────────────────────── private field `private` `_name` by convention; enforced not enforced interface `interface` a Protocol, or duck typing value object a record a frozen dataclass null safety Optional<T> `| None` with type hints enum `enum` `enum.Enum` package-private default access no equivalent; `__all__` and convention ───────────────────────────────────────────────────────────── THE POINT IS NOT THE TABLE BUT ITS CONSEQUENCE: a design that relies on compiler-enforced encapsulation must be implemented differently in a language that has none. In Python the discipline is carried by convention, review and tests rather than by the compiler — so the same design needs MORE test coverage of its invariants, not less. Choosing to ignore that is how "we implemented the design" produces a system whose invariants are unenforced.

THE SAME SYSTEM NEEDS THREE KINDS OF CLASS, and treating them alike is a common error. 1. A VALUE OBJECT — immutable, equality by state, no identity public record Money(BigDecimal amount, Currency currency) { public Money { requireNonNull(amount); requireNonNull(currency); if (amount.scale() > 2) throw new IllegalArgumentException( "money has at most 2 decimal places"); } public Money plus(Money other) { if (!currency.equals(other.currency)) throw new CurrencyMismatchException(); return new Money(amount.add(other.amount), currency); } public boolean isNegative() { return amount.signum() < 0; } } · a record: equals/hashCode/toString generated, fields final · validation in the compact constructor, so an invalid Money cannot exist · `plus` RETURNS a new instance — no aliasing defects · NO identifier, because two equal amounts ARE the same value 2. AN ENTITY — mutable through guarded methods, equality by id public final class Application { private final ApplicationNo applicationNo; // identity private Status status; // lifecycle // … as written in the earlier topic @Override public boolean equals(Object o) { return o instanceof Application a && applicationNo.equals(a.applicationNo); } @Override public int hashCode() { return applicationNo.hashCode(); } } · identity is the business identifier, and it is final — otherwise the object escapes its own HashSet · state changes only through methods that validate · NOT a record: records are for values, and an entity's whole purpose is to change while remaining the same thing 3. A SERVICE — stateless, no identity, no state to compare public final class IssueLicenceHandler { private final ApplicationRepository repository; private final LicenceNumberPool pool; // dependencies only; NO request state public Licence handle(String no, OfficerId officer) { … } } · dependencies injected in the constructor, all final · NO per-request fields, so one instance serves every request concurrently — the statelessness argument from the visibility topic · equals/hashCode not overridden: there is no meaningful equality for a service, and needing one is a sign it is holding state it should not THE DIAGNOSTIC TABLE: question value entity service ────────────────────────────────────────────────────── has an identifier? no YES no mutable? no yes* no equality state id none may be shared freely? YES no YES holds request state? n/a n/a NEVER ────────────────────────────────────────────────────── * only through methods that enforce the invariants MOST DESIGN-TO-CODE MISTAKES ARE A CLASS IMPLEMENTED AS THE WRONG ONE OF THESE THREE: a mutable value object (aliasing bugs), an entity compared by state (two loads of one row are unequal), or a service holding request state (fails under concurrency, and only under concurrency).