EACH MESSAGE IN AN INTERACTION DIAGRAM BECOMES A STATEMENT IN THE SENDER'S METHOD. The rules, systematically: A MESSAGE TO ANOTHER OBJECT → A METHOD CALL ON THAT OBJECT 1: app := find(no) → Application app = repository.find(no); A MESSAGE'S RETURN VALUE → A LOCAL VARIABLE the name on the left of `:=` is the local variable's name A «create» MESSAGE → A CONSTRUCTOR CALL 2.1: «create»(amt, m, o) → new Payment(amt, m, o) A SELF-MESSAGE → A CALL TO A PRIVATE METHOD OF THE SAME CLASS 2.1: assertPayable(amt) → this.assertPayable(amt); A GUARD → AN `if` [status = APPROVED] 3: issue() → if (status == Status.APPROVED) { issue(); } AN ITERATION MARKER → A LOOP *[for each line] 4: total := subtotal() → for (ApplicationLine line : lines) total = total.plus(line.subtotal()); A NESTED MESSAGE NUMBER → A CALL MADE INSIDE THE METHOD THAT THE PARENT NUMBER NAMES message 2 is `app.recordPayment(...)`, and 2.1, 2.2 are calls made INSIDE recordPayment — so they belong in Application's method, NOT in the handler's THE MESSAGE ORDER → THE STATEMENT ORDER, and this is not merely stylistic: the collaboration topic showed that allocating a licence number before or after the status change changes whether the minimal guarantee holds. THE ORDER IS PART OF THE DESIGN. A RETURN ARROW AT THE END → THE `return` STATEMENT WHAT THE DIAGRAM DOES NOT GIVE YOU, and must be inferred: · local variable TYPES (from the design class diagram) · EXCEPTION HANDLING (from the use case extensions) · TRANSACTION BOUNDARIES (from the supplementary spec) · LOGGING (from the supplementary spec) · null and empty-collection handling · the exact form of loops and early returns THESE ARE THE JUDGEMENTAL PARTS, and they are typically more lines than the messages themselves.

METHOD 1 — the handler, from the collaboration in ACtE0805. THE DIAGRAM: :IssueLicenceHandler 1: app := find(no) ──▶ :ApplicationRepository 2: licNo := allocate() ──▶ :LicenceNumberPool 3: lic := issue(licNo, officer)──▶ :Application 4: save(app) ──▶ :ApplicationRepository 5: publish(event) ──▶ :EventPublisher 6: return lic THE MECHANICAL TRANSLATION: Licence handle(String no, OfficerId officer) { Application app = repository.find(no); // 1 LicenceNo licNo = pool.allocate(); // 2 Licence lic = app.issue(licNo, officer); // 3 repository.save(app); // 4 events.publish(new LicenceIssued(lic)); // 5 return lic; // 6 } SIX MESSAGES, SIX LINES. That is the mechanical part, and it is genuinely mechanical. NOW ADD WHAT THE DIAGRAM COULD NOT SAY, each addition traceable to a specific source: @Transactional // supplementary spec: // money and state must // not diverge public Licence handle(String no, OfficerId officer) throws ApplicationNotFound, NotIssuableException, NumberPoolExhaustedException { Application app = repository.find(no); // find() throws ApplicationNotFound — declared, not // caught: the caller (the UI) decides how to report // a missing application. Use case ext. 2a. LicenceNo licNo = pool.allocate(); // throws NumberPoolExhaustedException. // ORDER MATTERS: allocation happens BEFORE any state // change so that ext. 5a's minimal guarantee holds — // a failed allocation leaves no half-issued // application. See UC-05 ext. 5a. Licence lic = app.issue(licNo, officer); // throws NotIssuableException and // SeparationOfDutiesException, both from the // contract's preconditions. Not caught here. repository.save(app); // throws OptimisticLockException on the concurrent // case, UC-05 ext. 5d. The transaction rolls back; // the caller may retry. events.publish(new LicenceIssued(lic)); // AFTER the save, so no event is published for a // transaction that then fails. Printing, SMS and the // dashboard subscribe — the invariant/reaction split. log.info("licence {} issued for application {} by {}", licNo, no, officer); return lic; } COUNT WHAT THE NON-MECHANICAL PART ADDED: one annotation, three declared exceptions, one ordering constraint with a reason, one logging line, and five comments that each cite a requirement. THE DIAGRAM GAVE SIX LINES; THE DESIGN CONTEXT GAVE THE REST, and the rest is what makes it correct rather than merely plausible. METHOD 2 — the domain method, showing nested messages. THE DIAGRAM, message 3 expanded: 3: issue(licNo, officer) :Application 3.1: assertTransition(ISSUED) [self] 3.2: isPaid() [self] 3.3: «create» :Licence 3.4: changeStatus(ISSUED, officer) [self] 3.4.1: «create» :StatusChange THE CODE — note that 3.4.1 belongs inside changeStatus, not inside issue, because the numbering says so: public Licence issue(LicenceNo licenceNo, OfficerId officer) throws NotIssuableException, SeparationOfDutiesException { assertTransition(Status.ISSUED); // 3.1 if (!isPaid()) // 3.2 throw new NotIssuableException("fee unpaid"); if (officer.equals(reviewedBy)) throw new SeparationOfDutiesException( "issuer must differ from reviewer"); this.licence = new Licence(licenceNo, // 3.3 applicationNo, clock.instant()); this.issuedBy = officer; changeStatus(Status.ISSUED, officer); // 3.4 return licence; } private void changeStatus(Status to, OfficerId by) { history.add(new StatusChange(status, to, by, // 3.4.1 clock.instant())); this.status = to; } THE NESTING RULE IS WHAT KEEPS METHODS SHORT. If 3.4.1 were inlined into issue(), the method would mix two levels of abstraction — "record the issuance" and "append a history row" — which is the SINGLE LEVEL OF ABSTRACTION principle violated. The message numbering already told you where the boundary is.

THE PROPERTIES OF A GOOD METHOD, and how each is checkable: SHORT A method that fits on a screen can be understood as a whole. Long methods are almost always doing several things — which the message-nesting rule would have prevented. A ROUGH GUIDE, not a law: beyond about 20–30 lines, ask what could be extracted. ONE LEVEL OF ABSTRACTION Every statement in a method should be at the same conceptual level. A method that calls `validateApplication()` and then manipulates a character array is mixing levels, and the reader must switch mental gears mid-method. ONE REASON TO CHANGE From the cohesion ladder of ACtE0802: if two unrelated requirements would both edit this method, it has two responsibilities. FEW PARAMETERS Three or fewer is comfortable; beyond four, consider whether the parameters form an object. `recordPayment(amount, method, officer)` is fine; a method taking eight scalars is usually missing a parameter object. AND AVOID BOOLEAN FLAG PARAMETERS: `process(data, true)` is unreadable at the call site and is control coupling from the coupling ladder. Two methods beat one flag. LOW CYCLOMATIC COMPLEXITY From the design heuristics topic, V(G) = decisions + 1, and it is a lower bound on the tests needed. A method with V(G) = 15 needs fifteen tests for basis-path coverage, which is a concrete reason to simplify rather than an aesthetic one. NO SURPRISES A method named `getX` must not modify state. A query that mutates is the defect nobody looks for, because the name promised otherwise. THE COMMAND-QUERY SEPARATION principle: a method either returns a value and changes nothing, or changes something and returns nothing. THE SMELLS, and the design defect each indicates: SMELL THE UNDERLYING DESIGN DEFECT ───────────────────────────────────────────────────────────── long method several responsibilities; message nesting ignored long parameter list a missing parameter object, or too many dependencies a boolean flag parameter control coupling; should be two methods a chain of getters Law of Demeter violation; (a.getB().getC()) the wrong object was asked a type-testing conditional polymorphism was not used (if instanceof / switch on a type code) duplicated code in two a missing abstraction methods a comment explaining WHAT the code is not clear; extract a the code does well-named method instead a method that needs six fan-out too high; the class has doubles to test too many collaborators feature envy — a method the behaviour belongs on the that mostly uses another other class (Information Expert) object's data ───────────────────────────────────────────────────────────── THE PATTERN ACROSS THE WHOLE TABLE: EVERY CODE SMELL IS A DESIGN DEFECT MADE VISIBLE. That is why implementation feeds back into design, and why the correct response to a smell is usually to change the structure rather than to tidy the syntax. REFACTORING is the disciplined response — from ACtE0802, reorganising to simplify the design without changing behaviour. The named moves that address the table above: EXTRACT METHOD long method, comment-explaining-what MOVE METHOD feature envy INTRODUCE PARAMETER long parameter list OBJECT REPLACE CONDITIONAL type-testing conditional WITH POLYMORPHISM HIDE DELEGATE getter chain REPLACE FLAG ARGUMENT boolean flag WITH EXPLICIT METHODS EACH IS SAFE ONLY UNDER TEST COVERAGE, which is the practical reason tests precede refactoring rather than following it.