The OBJECT-ORIENTED IMPLEMENTATION phase takes the design artefacts and expresses them in a programming language. THE INPUTS, all produced in ACtE0804 and ACtE0805: DESIGN CLASS DIAGRAM → class definitions, fields, method signatures, visibility INTERACTION DIAGRAMS → method BODIES: the sequence of messages a method sends OPERATION CONTRACTS → preconditions as guards, postconditions as what the method must achieve USE CASE EXTENSIONS → exception handling and the test cases DOMAIN MODEL → the vocabulary; the class and method names SUPPLEMENTARY SPEC → transaction boundaries, timeouts, logging, security A WELL-SPECIFIED DESIGN MAKES IMPLEMENTATION LARGELY MECHANICAL. That is the claim, and it is substantially true for the structural parts — a class diagram maps to class definitions almost line for line. It is LESS true for the algorithmic interiors, which is why implementation still requires judgement. THE ITERATIVE REALITY, and the important point of this topic: IMPLEMENTATION FEEDS BACK INTO DESIGN. Writing the code reveals things the diagrams could not: · a method that turns out to need information nobody gave it → a visibility decision was wrong · a class that grows to 400 lines while its siblings are 40 → a responsibility was misassigned · a test that requires six doubles to write → the fan-out is too high, per the collaboration topic · duplicated logic in three classes → a missing abstraction · an interaction that cannot be made transactional → a boundary is in the wrong place NONE OF THESE IS A CODING PROBLEM. Each is a DESIGN DEFECT that only became visible in code, and the correct response is to change the design — which is why the phases are activities within an iteration rather than stages in a sequence. THE TWO WRONG RESPONSES to design/code divergence: (a) FORCE THE CODE TO MATCH THE DIAGRAM, accepting a design you now know is wrong because it was signed off. This produces working code that fights itself. (b) IGNORE THE DIAGRAM and let the code diverge silently. The model becomes stale, which the modelling topic established is worse than having no model. THE CORRECT RESPONSE: update the design, or delete the part of it that is no longer true.

WHICH CLASS DO YOU WRITE FIRST? The answer follows the dependency structure, not the diagram's layout. THE PRINCIPLE: implement classes from LEAST-COUPLED to MOST-COUPLED, so that when you write a class, the things it depends on already exist. A DEPENDENCY-ORDERED PLAN for the licence issuance subsystem from ACtE0805: STEP 1 — VALUE OBJECTS AND ENUMERATIONS (no dependencies) Money, ApplicationNo, LicenceNo, OfficerId, PaymentMethod, Status These depend on nothing but the language. They are also the easiest to test — a pure function of their inputs — and getting Money right early prevents the currency defect appearing in ten places. STEP 2 — SIMPLE DOMAIN ENTITIES (depend only on step 1) Payment, StatusChange, Licence Each holds value objects and has little behaviour. STEP 3 — THE AGGREGATE ROOT (depends on 1 and 2) Application — which holds Payments, StatusChanges and a Licence, and enforces the invariants This is where the real behaviour lives, and where the interesting tests are. STEP 4 — INTERFACES (depend on 1–3 for their signatures) ApplicationRepository, LicenceNumberPool, EventPublisher Declared in the domain package, per dependency inversion. STEP 5 — HANDLERS / CONTROLLERS (depend on 1–4) IssueLicenceHandler, RecordPaymentHandler Testable with in-memory doubles for the step-4 interfaces, and needing no database at all. STEP 6 — INFRASTRUCTURE IMPLEMENTATIONS (depend on 4) PostgresApplicationRepository, SequenceNumberPool, InProcessEventPublisher STEP 7 — PRESENTATION (depends on 5) the HTTP endpoints or screens WHY THIS ORDER PAYS: at every step, everything you need already exists and is tested. You never write a class against a collaborator that does not yet compile, and you never need a stub for something you are about to write anyway. A USEFUL PROPERTY OF THIS ORDER: steps 1–5 are the whole business behaviour, and none of them requires a database, a web server or a network. THE ENTIRE DOMAIN AND APPLICATION LAYER CAN BE BUILT AND TESTED BEFORE ANY INFRASTRUCTURE EXISTS — which is the hexagonal-architecture payoff from the analysis-to-design topic, realised as a work plan. THE ALTERNATIVE ORDER — OUTSIDE-IN (starting from the use case and letting each layer's needs drive the next) is also legitimate and pairs naturally with test-driven development: write the failing acceptance test, then the handler, then discover what the domain must offer. Both orders converge; the dependency order is easier when the design is already detailed, and outside-in is better when the design is still being discovered.

CODING STANDARDS are the product standards of the SQA topic, applied at the source level. Their purpose is not tidiness but COMPREHENSIBILITY: the reader of a line of code is usually not its author, and often not its author's colleague. WHAT A CODING STANDARD SHOULD COVER: NAMING classes are nouns in PascalCase; methods are verbs in camelCase; constants in UPPER_SNAKE; no abbreviations that are not domain terms LAYOUT indentation, line length, brace placement — the parts a FORMATTER should enforce, so that no human argues about them COMMENTS what to comment (WHY, not WHAT) and the documentation-comment format for public APIs ERROR HANDLING which exceptions to use, what never to swallow, whether to check or unchecked FILE STRUCTURE one public class per file; member ordering LANGUAGE which features are permitted — no raw SUBSET types, no mutable statics, no reflection in business code TESTS naming and structure of test methods THE RULE FROM THE SQA TOPIC APPLIES HERE MOST OF ALL: A STANDARD ENFORCED BY A TOOL COSTS NOTHING TO FOLLOW; A STANDARD IN A DOCUMENT COSTS AN ARGUMENT IN EVERY REVIEW. Formatting belongs to a formatter, naming and structure to a linter, and only the genuinely judgemental parts to human review. NAMING FROM THE DOMAIN — the practice with the highest return. The glossary of ACtE0804 is the source of names: ✗ `ApplicationDTO`, `AppMgr`, `procData()`, `flag2` ✔ `Application`, `IssueLicenceHandler`, `recordPayment()`, `isReconciled` Every name taken from the domain reduces the representational gap; every invented technical name widens it. A method called `procData` obliges every future reader to read its body. COMMENTS — the discipline that is most often got wrong: ✗ // increment i by one i++; ✗ // set status to issued this.status = ISSUED; ✔ // The licence number is allocated BEFORE the status // change so that a failed allocation leaves no // half-issued application (use case UC-05, ext. 5a). A comment restating the code is noise that will fall out of date. A comment explaining WHY — a non-obvious ordering, a workaround for an external system's behaviour, a reference to the requirement — is the most valuable text in a codebase, because it is the only place that information exists. THE PRACTICES THAT DISTINGUISH IMPLEMENTATION QUALITY: TEST-FIRST OR TEST-ALONGSIDE from the test automation topic: written after the fact, tests get skipped under pressure SMALL COMMITS from the change management topic: review effectiveness collapses with diff size REFACTOR CONTINUOUSLY the design concept from ACtE0802 — improve structure without changing behaviour, under the protection of the tests REVIEW EVERY CHANGE the highest-return SQA activity, at 57.8× in the worked example STATIC ANALYSIS IN CI catches the defect classes a human reviewer reads past THE ONE-LINE SUMMARY: implementation quality is decided less by cleverness than by whether the feedback loops — tests, reviews, static analysis, small changes — are short enough to catch mistakes while they are still cheap.