MOST of the design-to-code translation is direct. Work through it systematically. A CLASS → A CLASS DEFINITION Application → public class Application { … } One public class per file, named identically. AN ATTRIBUTE → A FIELD - status : Status → private Status status; - appliedOn : LocalDate → private final LocalDate {immutable} appliedOn; THE `final` COMES FROM THE `{immutable}` CONSTRAINT. Every property string in the design has a code consequence, and skipping them loses design information. A METHOD SIGNATURE → A METHOD DECLARATION + issue(no : LicenceNo, o : OfficerId) : Licence throws NotIssuableException → public Licence issue(LicenceNo no, OfficerId officer) throws NotIssuableException { … } VISIBILITY MARKERS → ACCESS MODIFIERS + → public - → private # → protected ~ → package-private (no modifier in Java) A DERIVED ATTRIBUTE → A METHOD, NOT A FIELD / feeDue : Money → public Money feeDue() { return district.rateOn(appliedOn) .forCategory(category); } THE `/` IS AN INSTRUCTION NOT TO STORE IT. Storing it reintroduces the drift defect the design was avoiding. If the computation is expensive, cache it — but that is a separate, deliberate decision with invalidation to think about. AN ENUMERATION → AN ENUM «enumeration» Status → public enum Status { RECEIVED … RECEIVED, UNDER_REVIEW, APPROVED, REJECTED, ISSUED } AN «interface» → AN INTERFACE «interface» ApplicationRepository → public interface ApplicationRepository { Application find(String no) throws ApplicationNotFound; void save(Application app); } GENERALISATION → INHERITANCE Officer ◁── CounterOfficer → public class CounterOfficer extends Officer { … } An ITALIC class name means `abstract class`. REALISATION → IMPLEMENTS PostgresApplicationRepository - -▷ ApplicationRepository → class PostgresApplicationRepository implements ApplicationRepository { … } A DEPENDENCY ARROW → A PARAMETER OR LOCAL VARIABLE It is NOT a field. That is the whole distinction between a dependency line and a navigable association, from the visibility topic.

AN ASSOCIATION WITH NAVIGABILITY becomes a FIELD, and the MULTIPLICITY AT THE FAR END decides the field's type. This is the most mechanical and most frequently mis-executed mapping. Application ──▶ 1 District private final District district; // never null Application ──▶ 0..1 Payment private Payment payment; // may be null → and the design should say what null means. Prefer Optional<Payment> as a RETURN type; a nullable field is acceptable internally where the class controls it. Application ◆──▶ 1..* StatusChange {ordered} private final List<StatusChange> history = new ArrayList<>(); → {ordered} → List, not Set. The constraint chose the collection type. Application ──▶ * Endorsement (unordered, unique) private final Set<Endorsement> endorsements = new HashSet<>(); Register [applicationNo] ──▶ 0..1 Application private final Map<String, Application> byNumber = new HashMap<>(); → a QUALIFIED association maps directly to a Map, which is why the qualifier notation is worth knowing. THE THREE RULES that keep association mapping honest: 1. MULTIPLICITY 1 MEANS THE FIELD IS NEVER NULL, and the constructor must enforce it: public Application(ApplicationNo no, District district) { this.district = Objects.requireNonNull(district); } A `1` multiplicity that permits null in code is a design assertion the code does not keep. 2. A COLLECTION FIELD IS FINAL AND NEVER EXPOSED: ✗ public List<StatusChange> getHistory() { return history; // caller can mutate it } ✔ public List<StatusChange> history() { return List.copyOf(history); } ✔✔ public boolean wasEverRejected() { … } The third is best — expose the question, not the data, per the visibility topic's collection-leak trap. 3. COMPOSITION (◆) MEANS THE WHOLE CREATES AND OWNS THE PART. In code that means the part is created inside the whole and never handed in from outside: ✗ app.addStatusChange(externallyCreatedChange); ✔ // inside Application private void recordChange(Status from, Status to, OfficerId by) { history.add(new StatusChange(from, to, by, clock.instant())); } The second form makes it impossible to add a history entry that does not correspond to a real transition — the invariant is structural rather than hoped for. A BIDIRECTIONAL ASSOCIATION, if the design genuinely needs one, requires a single owning side that maintains both: // in Application, the owner void attach(Payment p) { this.payment = p; p.setApplication(this); // package-private } And `setApplication` must not be public, or the two sides can be made inconsistent from outside. THIS IS WHY THE VISIBILITY TOPIC ADVISED AGAINST BIDIRECTIONAL ASSOCIATIONS: they cost a hand-maintained invariant.

Three translations are NOT mechanical, and knowing which they are is the point of this topic. 1. OBJECT TO RELATIONAL — the impedance mismatch. THE MISMATCHES, each with a real consequence: IDENTITY objects have identity by reference; rows have identity by primary key. Two objects loaded separately from the same row may be distinct objects representing one entity — hence the identity-map pattern. INHERITANCE tables have no inheritance. Three standard strategies, each with a real cost: SINGLE TABLE per hierarchy — simple, fast, but nullable columns for every subclass's fields JOINED tables — normalised, but a join per level on every read TABLE PER CLASS — no joins, but queries across the hierarchy need a union ASSOCIATIONS a bidirectional object reference is one foreign key, so the object model has two things to keep consistent where the database has one GRANULARITY a value object like Money is two columns, not a table — so the mapping is not one-class-one-table NAVIGATION objects navigate by following references, which in a database means a query per reference — the N+1 SELECT PROBLEM: for (Application a : findAll()) // 1 a.getDistrict().getName(); // + N 100 applications become 101 queries. At 2 ms each that is 202 ms instead of the ~4 ms a single join would take — a 50× difference from a mapping detail, and the single most common performance defect in ORM-based systems. THE DESIGN RESPONSE: keep persistence behind the repository interface (the pure fabrication from the GRASP topic), so that the mismatch is confined to one layer and the domain never contains a query. 2. INTERACTION DIAGRAM TO METHOD BODY — mechanical in outline, judgemental in detail. The next topic covers it: the messages give you the statements, but the loops, conditionals, local variables and error handling are inferred from the use case, not read off the diagram. 3. CONCURRENCY — invisible in every design diagram. No class diagram or sequence diagram shows that two threads may execute the same method simultaneously. The design's `version` field records that the simultaneity question was ASKED; making it work requires code the diagram cannot express: · which methods must be synchronised or made immutable · where the transaction boundary sits · whether the collection needs to be concurrent · what happens on an optimistic-lock failure — retry, or report to the user? THIS IS WHERE UNSPECIFIED DESIGN BECOMES A DEFECT THAT APPEARS ONLY UNDER LOAD. From the use case elaboration topic: question (d) produces the field; only implementation produces the behaviour. THE PRACTICAL CONCLUSION: expect the structural mapping to be quick and the persistence, concurrency and error-handling mappings to take most of the time. A plan that budgets implementation as "the easy part because the design is done" has mis-estimated by exactly the size of these three.