Mock Exams — the Real Papers, Self-Marked

Abstraction is about exposing what an object does while hiding how it does it. The cleanest example in this domain is an abstract Vehicle (or an IParkable interface) that declares the essential behaviour every vehicle must offer — GetSize(), CalculateFee(Duration d) — without committing to any one concrete vehicle. Car, Motorcycle and Bus are concrete realisations that fill in the detail.

The relationship that carries the abstraction is the dependency of ParkingLot on the Vehicle abstraction: ParkingLot.ParkVehicle(Vehicle v) is written entirely against the abstract type. The lot "knows" only the contract — that any vehicle can report its required spot size — and is deliberately ignorant of engines, wheel counts or passenger capacity. That ignorance is the abstraction: it lets the lot reason about a bus and a motorcycle through one simplified concept. A future ElectricVehicle slots in without the lot changing, which is the payoff of abstracting at the right seam. See the four pillars and object relationships.

Encapsulation means the field is private because there is a rule about it that outsiders must not be able to break. Three good choices, each with its invariant:

• private bool isOccupied — occupancy must only ever flip through Assign() / Release(). If it were public, two vehicles could be parked in one spot by careless code setting the flag directly; the class could no longer guarantee its own consistency.
• private SpotSize size — the size is fixed at construction and determines which vehicles fit. Making it private and read-only stops anyone mutating a "large" bus bay into a "small" one at runtime, which would corrupt allocation logic.
• private Vehicle? occupant — the spot must reference at most one vehicle, and only while occupied. Hiding it prevents external code from pointing a spot at a vehicle that never parked there, keeping isOccupied and occupant in agreement.

The theme in every justification is the same: private + methods = the class enforces its invariants instead of trusting every caller. See encapsulation.

The two functions should be the only doors into the private state, and each should validate before it mutates:

• public bool Assign(Vehicle v) — checks the invariant first: if the spot is already occupied, or v.RequiredSize > this.size, it refuses and returns false; otherwise it sets occupant = v and isOccupied = true together. External code can never leave the two fields inconsistent because it cannot set either directly.
• public void Release() — clears occupant = null and isOccupied = false as one atomic operation, so the spot cannot end up "free but still pointing at a car". A caller asks the spot to release; it does not reach in and null a field.

Protection comes from the fact that both methods are gatekeepers: they run validation and keep related fields in step, so the object's rules hold no matter who calls. This is the behavioural half of encapsulation — private data plus a controlled public API.

The discipline here: an attribute belongs on the subclass only if it makes no sense on every vehicle. Assumption stated up front: Vehicle already holds the common data (see Q3·B), so these are the genuinely type-specific extras.

• Car: numberOfDoors, hasChildSeat, bootCapacityLitres.
• Motorcycle: hasSidecar, engineCc, requiresHelmetStorage.
• Bus: passengerCapacity, numberOfAxles, isDoubleDecker.

Each of these would be meaningless or wasteful if pushed up to Vehicle (a motorcycle has no boot; a car has no axle count worth modelling), which is precisely the test for "belongs on the subtype". See inheritance and where inheritance is appropriate.

A field belongs on Vehicle when every subtype needs it and none would define it differently. Two clear cases:

• licensePlate (string) — every vehicle entering the lot is identified this way; the ticket and exit lookup both rely on it.
• requiredSpotSize (enum Small/Medium/Large) — every vehicle reports the size of spot it needs. Note this is declared on the base but its value is set per subtype, which is what makes the polymorphic allocation in Q3·D work.

entryTime is an equally valid answer. The reasoning that earns the marks: placing shared state once on the base avoids duplication and lets ParkingLot treat all vehicles uniformly. See inheritance and shared state.

A method is worth overriding only when the subtypes genuinely do it differently:

• CalculateFee(TimeSpan duration) — a bus is charged at a higher hourly rate than a car, a motorcycle lower. Same signature, different arithmetic per subtype. This is the override that Q3·E asks you to exploit.
• GetRequiredSpotSize() — returns Large for Bus, Medium for Car, Small for Motorcycle. The lot calls it without knowing the concrete type.

Both are declared virtual/abstract on Vehicle and override in each subclass, so a Vehicle reference dispatches to the right body at run time. See polymorphism.

The method parameter is typed as the abstraction, Vehicle, so at compile time parkVehicle knows only the contract. When it calls vehicle.GetRequiredSpotSize(), the runtime looks at the actual object — a Bus, say — and dispatches to Bus.GetRequiredSpotSize(). This is dynamic dispatch (late binding): the object carries its own behaviour, so the method behaves differently for each subtype while its code is written once.

That is exactly why no instanceof ladder is needed. A switch on type would force parkVehicle to be modified every time a new vehicle is added (an OCP violation); polymorphism pushes the per-type decision into the subclasses, so adding ElectricVehicle means adding a class, not editing the lot. The decision lives with the data that knows the answer. See polymorphism and OCP.

At exit, the lot holds a Vehicle reference and simply calls vehicle.CalculateFee(duration). Because CalculateFee is overridden per subtype, a Bus object runs the bus rate, a Car the car rate — the billing code never asks "what kind of vehicle is this?" It relies on each object knowing its own pricing. Adding ElectricVehicle with a discounted rate requires no change to the exit/billing path at all.

A stronger answer notes the design tension: baking the fee into the vehicle subtype couples pricing policy to the vehicle hierarchy, so introducing surge pricing or long-term discounts (Part 2, Q2) would multiply subclasses. The more flexible variant is to give Vehicle an injected IFeeStrategy and delegate: polymorphism then varies the strategy, not the vehicle class. Either answer earns full marks if the dispatch argument is clear; the Strategy remark shows top-band judgement. See Strategy and OCP.

The deciding test throughout is lifetime ownership, not merely "does A hold a reference to B".

• ParkingLot — ParkingSpot: Composition. The spots are an intrinsic, permanent part of the lot; they are created with it and have no meaning outside it. If the lot is demolished, its spots cease to exist. Strong ownership + shared lifetime = composition (filled diamond at the ParkingLot end, multiplicity 1..*).
• ParkingSpot — Vehicle: Association (temporary). While occupied, a spot references the vehicle in it, but neither owns the other and the link is transient — it exists only for the duration of the stay, then breaks on exit. This is a plain association (a "uses/occupies" link), 0..1 on each side. It is not composition — the vehicle lives on after leaving — but note that alone wouldn't rule out aggregation too (aggregation is independent lifetime by definition); the real reason it isn't aggregation either is that a spot doesn't have a vehicle as a part, it just temporarily references one — there's no whole-part semantics here at all.
• ParkingLot — Vehicle: Association. The lot deals with vehicles that pass through it; a vehicle exists entirely independently of the lot and is shared with the outside world. A transient "manages/parks" association, not aggregation of owned parts — the lot never owns the vehicles.

(If you argued ParkingLot–Vehicle as aggregation on the grounds that the lot holds a collection of currently-parked vehicles, that is defensible and earns the marks provided you make the independent-lifetime argument — the examiner rewards the justification, not the label.) See association / aggregation / composition.

What a full-marks diagram shows: a filled diamond at the ParkingLot end of the lot–spot line (composition) with 1..* multiplicity; plain association lines (no diamond) for both links to Vehicle, the spot–vehicle one labelled 0..1; and hollow-triangle inheritance arrows from Car/Motorcycle/Bus up to the abstract Vehicle.

The SRP test is "one reason to change". ParkingLot currently has four:

• Fee calculation — changes when pricing policy changes (surge, discounts). A distinct reason to change.
• Report generation / formatting — changes when the report layout or output format changes. Nothing to do with parking rules.
• Payment processing — changes when a payment provider or gateway changes.

Each of these is an independent axis of change entangled in one class today, which is why a change to the report format risks breaking parking logic. The core responsibility that stays in ParkingLot is allocation/occupancy (parking and unparking). See SRP.

• FeeCalculator (behind an IFeeCalculator) — owns pricing. Now a new fee rule is a change in one small class the parking logic doesn't touch, and the calculator can be unit-tested in isolation with no lot involved.
• ReportGenerator — owns formatting/output of reports. Changing to PDF or a new layout affects only this class; it can be reused by other subsystems that need the same reports.
• PaymentProcessor (behind an IPaymentProcessor) — owns the payment gateway interaction, so swapping providers or mocking payments in tests never disturbs allocation.

ParkingLot retains only allocation and collaborates with these via interfaces. The improvement to state explicitly: each class now has one reason to change, so changes are localised, the pieces are independently testable, and they become reusable. This is SRP feeding straight into DIP (the lot depends on abstractions).

Principle: the Open/Closed Principle (OCP) — software entities should be open for extension but closed for modification.

Vehicle hierarchy. Keep Vehicle abstract with the stable contract (GetRequiredSpotSize(), and a fee hook). A new type — ElectricVehicle, Bicycle — is a new subclass that supplies its own behaviour. Crucially, ParkingLot.ParkVehicle(Vehicle v) is written against the abstraction, so it is never edited when a type is added: the new class plugs in and dynamic dispatch does the rest. That is "closed to modification" — the core allocation logic is sealed against change — while remaining "open to extension" through subclassing.

Fee structure. Do not fold pricing into the vehicle subtypes (that would explode into SurgeCar, LongTermBus…). Instead extract an IFeeStrategy with decimal Calculate(TimeSpan duration, Vehicle v), and implement HourlyFeeStrategy, DayPricingStrategy, SurgeFeeStrategy, LongTermDiscountStrategy. A new rule is a new strategy class; the parking and billing code that holds an IFeeStrategy reference never changes. This is OCP realised through Strategy and injected via DIP.

The unifying argument: both hierarchies push the point of variation behind an abstraction, so extension means adding a class and the existing, tested core logic is untouched — fewer regressions, safer growth. See OCP.

A concrete violation. Suppose Vehicle declares virtual decimal CalculateFee(TimeSpan d) with the implied contract "returns a non-negative fee for any positive duration". Now Motorcycle overrides it to throw for stays over 24 hours ("bikes can't stay overnight"). The billing loop iterates a List<Vehicle> and calls CalculateFee on each; when it reaches a long-staying motorcycle it crashes, even though the code was correct against the Vehicle contract. The subtype broke a promise the supertype made — a textbook LSP failure. Another example: a Bicycle subclass whose GetRequiredSpotSize() returns null/none, so ParkVehicle — which assumes every vehicle needs some spot — dereferences it and fails.

Guidelines to preserve substitutability:

• Don't strengthen preconditions. A subclass must accept every input the base accepts (a motorcycle can't reject durations the base allows).
• Don't weaken postconditions. It must still deliver everything the base promised (return a valid fee, a valid spot size) — no surprising nulls.
• Don't throw new exceptions the base contract didn't sanction, and don't silently do nothing where the base does something.
• Honour invariants of the base type; keep the behaviour a caller would reasonably expect.
• If a would-be subtype genuinely can't fulfil the contract, it isn't a subtype — model the capability separately (composition / a narrower interface) rather than forcing the inheritance.

Follow these and any Vehicle reference can hold a Car or Motorcycle interchangeably, which is what lets the lot's polymorphic code (Q3·D/E) stay correct. See LSP.

The problem with the monolith. A single ParkingLotInterface bundling ProcessPayment(), StreamCamera(), UpdateDisplay(), RecordEntry()… forces every client to depend on methods it doesn't use. The DisplayBoard must "implement" payment methods (throwing or leaving them empty), and — worse — any change to the payment part of the fat interface forces the display and camera implementers to recompile and be re-tested even though nothing about them changed. ISP says: no client should be forced to depend on methods it does not use.

The segregated design — small, role-focused (client-specific) interfaces:

• IPaymentProcessor { ProcessPayment(); Refund(); } — implemented by PaymentGateway.
• ISurveillance { StartRecording(); CaptureSnapshot(); } — implemented by SecurityCameraSystem.
• IDisplay { ShowAvailability(); ShowMessage(); } — implemented by DisplayBoard.

Each component implements only the interface for its role; ParkingLot depends on the specific abstractions it actually needs for a given collaboration.

Benefits (state at least one clearly): (1) implementers are no longer burdened with irrelevant methods or forced to write empty/throwing stubs; (2) changes are isolated — altering IPaymentProcessor doesn't ripple into the camera or display code, so there's less coupling and fewer needless recompilations/re-tests; (3) each interface is easier to mock and test in isolation. See ISP.

The three categories are organised by what aspect of a design the pattern is concerned with:

• Creational — object creation. These abstract the instantiation process, so client code doesn't hard-wire concrete classes or complex construction. They answer "how and when is an object made, and by whom?" Examples: Factory Method, Builder, Singleton.
• Structural — object composition. These concern how classes and objects are assembled into larger structures while keeping them flexible — the shape of the relationships. They answer "how are objects composed/related?" Examples: Adapter, Composite, Decorator.
• Behavioural — object interaction and responsibility. These concern how objects communicate and distribute responsibility at run time — the flow of control and messages. They answer "how do objects collaborate and who does what?" Examples: Observer, Strategy, Template Method.

The clean one-line contrast that earns the marks: creational is about making objects, structural about arranging them, behavioural about how they interact.

Fundamental difference: Factory Method defers the creation of one product to a subclass via a single overridable method; Abstract Factory provides an interface for creating a whole family of related products that are guaranteed to be consistent with one another, via several such methods on one factory object.

The choosing rule to state explicitly: use Factory Method when there is one product whose concrete type varies; reach for Abstract Factory when you need several related products created together and guaranteed to match (a Windows checkbox must never pair with a Mac button). Abstract Factory is often built from several factory methods. See Factory Method, Abstract Factory, and the factories comparison.

Pattern: Builder. The telling symptoms — many optional parts, a telescoping constructor, "Gaming PC vs Office PC vs Workstation" presets, and the desire to add a component without breaking every caller — are the textbook cue for Builder. It separates the construction of a complex object from its representation, so the same step-by-step process can assemble different configurations.

Roles:

• Computer — the Product being assembled (holds cpu, ram, storage, gpu, os, peripherals).
• IComputerBuilder — the Builder interface declaring the steps: SetCpu(), SetRam(), SetStorage(), SetGpu(), SetOs(), AddPeripherals(), Build().
• GamingPcBuilder, OfficePcBuilder, WorkstationBuilder — ConcreteBuilders, each supplying the parts for that configuration.
• ComputerDirector — the optional Director that knows the recipe (the order of steps) and drives a builder to produce a standard preset, e.g. Construct(IComputerBuilder b).

Relationships: the concrete builders realise (implement) IComputerBuilder; the Director holds an association to IComputerBuilder (it is configured with one and calls its steps); each builder creates a Computer (a dependency, drawn dashed); the Computer composes its parts.

A student answer typically also shows the fluent usage: new GamingPcBuilder().SetCpu("i9").SetGpu("RTX").Build(), and notes that adding a new component means adding one step to the interface/builders, not editing every caller.

Pattern 1 — Decorator (dynamic feature addition). Decorator wraps an object in another object of the same interface to add behaviour at run time, stackably. Applied to Computer: after assembly you need to add optional post-build enhancements — an extended warranty, pre-installed software bundle, RGB lighting, overclock profile — in any combination. Rather than a subclass per combination (GamingPcWithWarrantyAndRgb… — a combinatorial explosion), wrap: new RgbDecorator(new WarrantyDecorator(gamingPc)). Each decorator implements IComputer, forwards to the wrapped computer, and augments the result (e.g. adjusts GetPrice()/GetDescription()). The concrete problem solved: enhancing a built machine without touching its class or exploding the hierarchy.

Pattern 2 — Composite (hierarchical composition). Composite lets clients treat individual objects and compositions of objects uniformly through one interface. Applied to Computer: a corporate order is a tree — a "server rack" contains several workstations, each of which is itself a Computer; or a Computer is composed of components that themselves contain sub-components. You want GetTotalPrice() or GetPowerDraw() to work identically whether called on a single machine or a whole rack. A ComputerBundle (composite) and a leaf Computer both implement IComputerComponent, and the composite recurses over its children. The concrete problem solved: aggregating over an arbitrarily deep part-whole structure without the client special-casing leaves vs groups.

Conceptual difference & choice:

Choose Decorator when the requirement is "add optional features to an assembled computer"; choose Composite when it is "manage internal parts / groups of computers as a single unit". Both keep the same interface (unlike Adapter, which changes it). See the Composite vs Decorator comparison.

Problem 1 — Adapter. The legacy module and the new service have incompatible interfaces: one expects an XML string, the other returns a list of JSON maps, and the legacy side can't change. Adapter is the exact fit: write a TransactionServiceAdapter that implements ILegacyDataSource (the Target the legacy module already speaks) and internally calls retrieveTransactionsJson() on the new service (the Adaptee), translating the JSON maps into the XML string the legacy module expects. The adapter's whole job is interface translation so two things built to different contracts can work together without modifying either.

Problem 2 — Proxy. The concerns are lazy loading, caching, and authorisation on the same interface — a surrogate that controls access to the real object. Proxy covers all three of its classic variants at once: a virtual proxy defers the expensive retrieveTransactionsJson() call until data is genuinely needed; a caching layer stores the result so repeat calls in a short window don't hit the costly service again; and a protection proxy checks the caller is authenticated/authorised before forwarding. The TransactionServiceProxy implements the same interface as the real service and stands in front of it, so clients are unaware they're not talking to the real thing.

Fundamental difference:

In this scenario: the Adapter exists because the shapes don't match; the Proxy exists because access must be governed. Different problems, hence different patterns — even though both are "wrappers". See the wrapper-family litmus.

Pattern: Iterator. The problem is "traverse heterogeneous collections uniformly without exposing their internal structure" — the definition of Iterator.

Core purpose & decoupling: Iterator provides a way to access the elements of an aggregate sequentially without exposing its underlying representation. Each supplier's catalog exposes a standard GetIterator() returning an IIterator<Product> with HasNext() / Next(). The Product Display Module programs against that interface only, so it walks an array-backed, a linked-list-backed, and a tree-backed catalog with identical code. The traversal logic lives inside each concrete iterator, not in the client, which is what breaks the coupling: when a supplier changes its internal structure, only that supplier's iterator changes; the display module is untouched (Open/Closed).

Component mapping:

Benefits: (1) the display module is decoupled from every internal structure — one traversal code path for all suppliers; (2) adding a new supplier with a novel structure means adding a concrete iterator, with zero change to the display module (extensibility / OCP); (3) traversal, filtering and totalling are written once; (4) multiple simultaneous traversals are possible since each iterator holds its own position. See Iterator.

Define an abstraction — abstract class Payment or interface IPayment — declaring processPayment(). Each method is a subclass/implementer overriding processPayment() with its own logic. The order-processing code holds the abstraction: void Checkout(IPayment payment) => payment.processPayment(); — it depends only on the contract, never on a concrete type.

Because of that, adding CryptocurrencyPayment means writing one new class that implements IPayment; the checkout code, being coded against the interface and dispatching polymorphically, is not touched, recompiled logic-wise, or re-tested. The module is open to extension (new payment classes) and closed to modification (existing, tested payment-processing code stays sealed). Contrast the anti-pattern: a switch(payment.Type){ case Crypto: … } would force an edit to working code for every new method — precisely what OCP prevents. See OCP and polymorphism.

DIP has two clauses: high-level modules should not depend on low-level modules — both should depend on abstractions; and abstractions should not depend on details — details depend on abstractions. Here the high-level module is the order/checkout service; the low-level modules are the concrete payment classes. Left alone, checkout would new CreditCardPayment() and be welded to it.

DIP inverts that: introduce IPayment as the abstraction that both sides depend on. Checkout depends on IPayment; CreditCardPayment also depends on (implements) IPayment. The concrete payment is then injected into checkout (constructor or method parameter) rather than constructed inside it. Now the direction of the source-code dependency points towards the abstraction, not towards a detail: checkout can be tested with a fake IPayment, and swapping providers never edits the high-level policy. This is exactly what a DI container's constructor injection provides. See DIP.

• (i) Restaurant — MenuItems: Aggregation. A menu item is defined by the restaurant, but it is a reference-able catalogue entry that can exist and be reasoned about independently of any single order, and conceptually could be shared/duplicated across menus. The restaurant is a "whole" that groups items it doesn't destroy-on-delete in the strong sense. (Composition is also defensible if you argue a menu item has no meaning outside its restaurant and dies with it — award marks for either with a lifetime argument.)
• (ii) Order — MenuItems: Aggregation / Association. An order refers to menu items the customer selected; those items (the catalogue entries) outlive the order and are shared with the restaurant's menu. The order does not own them — deleting the order must not delete the menu item — so this is aggregation, not composition. (If you model the order as holding its own OrderLine copies, those lines would be composition; the catalogue MenuItem reference is aggregation.)
• (iii) Customer — Order: Composition, if you make the lifetime assumption explicit. This is the expected exam answer, but "the order exists for that customer" is not by itself a lifetime argument — composition requires you to actually assume the order's lifecycle is bound to the customer's, i.e. deleting the customer deletes their orders too. State that assumption and composition is defensible: strong ownership, and an order arguably has no meaning without the customer who placed it. Be aware, though, that most real systems keep orders around after a customer account is deleted, for auditing and legal reasons — under that (arguably more realistic) assumption the order outlives the customer, which makes this association or aggregation instead. Either answer earns marks, provided you state the lifetime assumption you're relying on rather than asserting the label.

Across all three the examiner is marking the lifetime/ownership justification, not the label alone. See association / aggregation / composition.

• abstract class MenuItem — shared: Name (string), Price (decimal); declares abstract string GetDescription() and maybe virtual decimal GetPreparationTime().
• FoodItem : MenuItem — specific: SpiceLevel (enum), IsVegetarian (bool); overrides GetDescription() to include spice/dietary info and GetPreparationTime() (cooking takes longer).
• DrinkItem : MenuItem — specific: Volume (ml), IsCarbonated (bool); overrides GetDescription() to include size, and might override GetPreparationTime() to near-zero.

The design point to state: common state lives once on the abstract base; the subtype-specific attributes and the differing behaviour (GetDescription) justify the inheritance. See inheritance.

Full marks: abstract MenuItem (italic/«abstract») with the two concrete subclasses joined by hollow-triangle inheritance arrows, and Order linked to MenuItem by an aggregation (open diamond at the Order end) with 1..* — Order interacts with the abstraction, not the concrete subclasses.

Use a Factory — Factory Method (or a Simple Factory) — producing an abstract LibraryResource. Define abstract class LibraryResource (or IResource) with the common contract, and a ResourceFactory.Create(ResourceType type) (or a CreateResource() factory method) that returns the right concrete Book/Journal/DVD behind that abstraction. The Librarian and CatalogManager call the factory and receive a LibraryResource reference — they never name a concrete class. See Factory Method.

The factory centralises and encapsulates the instantiation decision, so the knowledge of which concrete class to build lives in exactly one place instead of being scattered across the Librarian and CatalogManager. Because those clients depend on the abstract LibraryResource and delegate creation to the factory, they are decoupled from the concrete types.

OCP link: adding an EBook or Audiobook means writing a new subclass and registering it with the factory — the client code that uses resources is not modified. The system is open to extension (new resource classes) and closed to modification (existing catalogue/lending code untouched). A pure Factory Method goes further: a new resource can arrive via a new creator subclass with no edit to the factory's existing branches at all. Contrast the naive approach — a switch(type){ new Book()… } pasted wherever resources are created — which must be edited in many places for every new type, the OCP violation the factory removes. See OCP and Factory Method.

Composite. This is a part-whole hierarchy where a container (Section, Shelf) can hold both leaves (individual Resources) and other containers, arbitrarily deep — the defining shape of Composite. Define interface ILibraryComponent { Display(); GetItemCount(); }; Resource is a leaf, while Shelf and Section are composites holding a list of ILibraryComponent and recursing into their children. The client then treats a single book and a whole section uniformly — GetItemCount() works the same on either, with the composite summing over its children.

Observer. One-to-many "notify interested parties when state changes" is exactly Observer. The Book (or a BookAvailability wrapper) is the Subject; users who requested it are Observers (implementing IObserver.Update()) that subscribe via Attach(). When the book's status flips to available, the subject iterates its observer list and calls Update() on each, pushing a notification. The subject knows only the IObserver interface, so users can be added/removed at run time without the book changing — decoupled one-to-many notification.

Template Method. A fixed sequence of steps where the order is invariant but some steps vary by resource type is the signature of Template Method. The base abstract class ResourceLoan defines the public void BorrowResource() — the template — which calls CheckEligibility(), VerifyAvailability(), UpdateStatus() in that order. The skeleton is written once and sealed; the steps that differ (e.g. a DVD has a shorter loan period, a reference book can't be borrowed) are abstract/ virtual hooks overridden by BookLoan, DvdLoan, etc. The base controls the algorithm's shape; subclasses fill in the variable steps — inversion of control ("don't call us, we'll call you").

Full marks: the diagram must make all three patterns legible at once — the ResourceFactory creating an abstract LibraryResource (creational); a Section/Shelf composite over ILibraryComponent with resources as leaves (structural); and a Book subject notifying User observers plus an abstract ResourceLoan template (behavioural) — with correct notation for inheritance (hollow triangle), realization (dashed triangle), composition/aggregation (diamonds) and association.

Inheritance-only here is workable for the simplest case but reveals classic weaknesses as the hierarchy grows:

• Combinatorial explosion / rigidity along a second axis. The moment a second dimension appears — e.g. payment method × currency, or method × fraud-check policy — pure subclassing multiplies: CreditCardUsdWithFraudCheck, PayPalEurNoFraud… The tree balloons.
• Tight coupling to the base class. Every subclass inherits the base's implementation; a change to PaymentMethod ripples into all subclasses (the fragile base class problem), and behaviour is fixed at compile time — you can't change how an object pays at run time.
• Weak reuse / duplication. Behaviour shared by some but not all methods has nowhere clean to live — it gets duplicated across subclasses or forced up into a bloated base.
• LSP risk. If a future "method" can't honour part of the base contract (e.g. a store-credit method that can't refund), forcing it under PaymentMethod invites Liskov violations.

The through-line: inheritance binds behaviour statically and along a single axis, so it doesn't flex as requirements grow in more than one direction. See composition vs inheritance and LSP.

Design: define interface IPaymentStrategy { Result Pay(decimal amount); }. Each method — CreditCardStrategy, PayPalStrategy, DigitalWalletStrategy — implements it. A high-level PaymentProcessor (or the Order) holds an IPaymentStrategy and delegates: _strategy.Pay(total). The concrete strategy is injected, so it can be chosen — and changed — at run time (Strategy pattern). The processor "has-a" payment behaviour rather than "is-a" payment.

Why more flexible/maintainable (address the maxim directly): composition assembles behaviour from interchangeable parts instead of freezing it in a class hierarchy. (1) Run-time flexibility — a customer can switch from card to wallet on the same order by swapping the strategy object; inheritance would need a different subclass instance. (2) Open/Closed — a new method is a new strategy class the processor never knows about; nothing existing is modified. (3) No base-class coupling / no explosion — a second axis (currency, fraud policy) becomes another injected collaborator, not a multiplied subclass. (4) Testability — inject a fake strategy to test the processor. Composition keeps the pieces small, independent and recombinable, which is precisely why the GoF advise favouring it over inheritance. See composition over inheritance and DIP.

Any three of the following, each named as a principle with lines cited:

• Function does too many things (SRP for functions / low cohesion). One function validates, sums, does file I/O, mutates a status record and prints — at least four jobs (lines 11–13 validation/sum, 17–20 I/O, 22–26 status update, 28/31/34/37 printing). A clean function does one thing.
• Deep nesting / arrow anti-pattern. Nested if/if/try drive the code four levels deep (lines 7, 11, 16, and the trailing elses at 33/36). Guard clauses (early return on empty/invalid) would flatten it.
• Poor / vague naming and a misleading name. process_data_and_save announces it does two things (the "and" is a smell); log_status, data_list are vague; the docstring even admits "updates a global status" (lines 2, 5, 26).
• Long parameter list. Four parameters, one of them an output parameter (lines 2, 26) — hard to call correctly and a sign the function should be split or take an object.
• Dead / unreachable code & wrong scope. The "Example usage" (lines 40–45) is indented inside the function body after all branches return, so it can never run — it also calls the function recursively-looking at module level but sits in the wrong scope. Confusing and dead.
• Magic values / booleans-for-errors. Returning True/False to signal outcomes (lines 29, 32, 35, 38) instead of raising exceptions mixes control flow with error handling.

See clean functions (do one thing, small, few arguments) and naming/structure.

Where: line 26 — log_status.update(global_status_record) (built up on lines 22–25). This mutates the log_status dictionary that was passed in by the caller. (Writing to the file, lines 17–20, and the prints are also side effects; but the "significant" one the question targets is the hidden mutation of the caller-owned argument.)

Why it's a side effect: a function's observable output should ideally come through its return value. Here the function also reaches out and modifies state that lives outside its local scope — an object owned by the caller — as a hidden consequence of being called. The function's name promises "process and save"; nothing signals that it will silently rewrite the caller's dictionary. Its result is not conveyed solely by what it returns.

Problems it introduces:

• Hidden coupling & surprise. Callers who don't read the body won't know their dictionary changed — a source of bugs at a distance.
• Harder to test & reason about. The function isn't referentially transparent: the same inputs also depend on and alter external state, so you must set up and inspect that state to test it. Order of calls now matters.
• Concurrency hazards. Shared mutable state touched as a side effect is unsafe if two callers share the dictionary.
• Reduced reusability. The mutation entangles this function with the caller's data model.

The fix: return the status record and let the caller decide whether to merge it — keep the function free of hidden state changes. See side effects.

Red → Green → Refactor, for the password-validator example:

• Red — write a failing test. Goal: specify the next tiny piece of behaviour before any production code. The developer writes a test for one rule (e.g. "rejects a password under 8 characters"), runs it, and watches it fail — proving the test actually exercises missing behaviour (and isn't a false pass).
• Green — make it pass. Goal: get to passing as quickly as possible. The developer writes the minimum production code needed to satisfy that one test — no more — and runs the suite until it is green. Resisting the urge to over-build is the discipline.
• Refactor — clean up. Goal: improve the design now that tests protect you. The developer removes duplication and improves names/structure in both test and production code, re-running the tests to confirm nothing broke. Behaviour is unchanged; quality improves.

Then repeat for the next rule. See the TDD cycle.

Two design-level benefits (not just "fewer bugs"):

• Testability pressure forces good structure (modularity + loose coupling). To write a test first, the unit must be instantiable and its dependencies substitutable — which pushes you towards small classes, single responsibilities, and dependency injection (depending on interfaces so you can pass fakes). Hard-to-test code is a design smell TDD surfaces immediately, so the design comes out more modular and decoupled almost as a by-product.
• A safety net that enables fearless refactoring (maintainability). The growing test suite captures intended behaviour, so you can restructure and clean up continuously without fear of silent breakage. That keeps the design from rotting over time — maintainability is preserved because change is cheap and safe. The tests also serve as executable documentation of how each unit is meant to be used.

A third, if you have room: YAGNI/minimalism — writing only enough code to pass keeps the design lean, avoiding speculative complexity. See TDD.

One-line summary worth stating: MSA is essentially SOA taken to a fine-grained, decentralised extreme — small independently-deployable services, private data, dumb pipes. See microservices vs SOA and SOA.

The mapping (with a key caveat):

Which tier MVC primarily focuses on: the Presentation tier. MVC is fundamentally a presentation-layer pattern — its concern is organising how a request is received, how logic is invoked, and how output is rendered. The View and Controller live entirely in presentation; the Model is MVC's link to the business/data tiers but MVC itself doesn't prescribe how those deeper tiers are built.

Why the distinction matters for web apps: the two are different kinds of decomposition, not rivals — 3-Tier is a physical/deployment layering (presentation ▸ logic ▸ data, often on separate hosts for scalability), while MVC is a logical organisation within the presentation tier. Recognising that MVC sits inside the presentation tier means you don't mistake "the Model" for the whole business/data tier: for a responsive, scalable web app you still layer the system into tiers (so the data and logic tiers scale independently) and apply MVC in the presentation tier to keep UI, input-handling and view rendering cleanly separated. Conflating them leads to fat controllers stuffed with business logic that should live in a separate tier. See MVC, 3-tier, and the MVC vs 3-tier comparison.

The essence: RMI trades interoperability for simplicity within Java; CORBA pays extra complexity (IDL + ORB) to buy genuine language/platform independence. See distributed objects / RPC.

• (i) Driver accepting a trip — One-to-one, Synchronous (request/response). Trip Management sends a request to a single Driver service and blocks for an immediate accept/decline. The need for one specific recipient and a prompt reply that gates the next step is the definition of synchronous request/response.
• (ii) Customer requesting a ride — One-to-many, Asynchronous (publish/notify). The system must notify multiple nearby drivers simultaneously and does not need an immediate reply from all — a broadcast/publish. Asynchronous one-to-many (e.g. publish/subscribe) fits: fire the notification to all nearby drivers and let acceptances arrive later, without blocking.
• (iii) Trip completion — One-to-one, Synchronous for the payment; then notify. Trip Management must charge Payment and know it succeeded before proceeding — that ordering/confirmation requirement demands a synchronous one-to-one request/response to the Payment service. Only after the success confirmation does it send the customer notification (which itself can be asynchronous fire-and-forget). The "must confirm before continuing" phrase is the tell for synchronous.

The deciding questions throughout: one recipient or many? and do I need the answer before I can continue? "Need an immediate/confirmed response" ⇒ synchronous; "notify many, don't wait" ⇒ asynchronous one-to-many. See event-driven / async messaging and microservices communication.

(i) The three states. Closed — requests flow normally and failures are counted; when the failure count/rate crosses the threshold the breaker trips to Open. Open — requests fail immediately without any network call being attempted, so no connection or thread is held; after a cooldown period elapses the breaker moves to Half-Open. Half-Open — exactly one trial request is admitted: if it succeeds the breaker returns to Closed and counters reset, if it fails the breaker returns to Open and the cooldown restarts.

(ii) Three defects. (1) The state is global. One flaky dependency trips the breaker for every other dependency in the process, so a failing payment provider also blocks calls to a perfectly healthy inventory service. Breaker state must be per-dependency. (2) There is no half-open state and no cooldown — once open, always open, so a two-second outage becomes a permanent one and the implementation contradicts the pattern it claims to implement. (3) The counter is cumulative, not windowed. Five failures spread over a month trip it exactly as surely as five in a row; real breakers track a failure rate over a rolling window and reset on success.

Creditworthy extras: no thread-safety around the shared counter; no fallback, so the caller still has no answer for the user; hand-rolling it at all when Microsoft.Extensions.Http.Resilience/Polly provides per-client policies. See Chapter 11 · Circuit Breaker and Chapter 9.

Orchestration. A central Order Saga Orchestrator issues commands (VerifyPrescription, ChargePayment, Dispatch) and drives the compensations (RefundPayment, CancelOrder) when a step fails. Justification tied to this scenario: (1) The compliance requirement is decisive. Orchestration persists the saga's state per order, so "which step did order 7781 reach?" is a single row to query; under choreography the answer only exists as a trail of events across four services' logs. (2) Verification takes minutes. A long-running step needs the saga's progress to survive restarts and deploys, which means persisted saga state and something that resumes it — exactly what an orchestrator provides. (3) Compensation ownership is explicit. When Dispatch reports the medicine unavailable, the orchestrator's saga state records which steps ran and therefore which undos are owed. Under choreography both Payment and Order subscribing to that failure event and each running its own compensation is perfectly correct — but nothing writes down who owns which undo, so with at-least-once redelivery and a growing workflow it is easy for a compensation to run twice or be dropped.

Disadvantage. The orchestrator is an additional service to build, deploy and monitor; it is a single point of failure for placing new orders, and a change bottleneck because every new business rule edits it. (Choreography's opposite trade — no new component, loose coupling — is what you are giving up.)

(i) An operation is idempotent if calling it more than once with the same input has no additional effect beyond the first call. This matters because distributed messaging is at-least-once, not exactly-once: brokers redeliver, and clients whose request timed out retry even when the server processed the original perfectly and merely lost the response. A GET changes nothing, so repetition is harmless. A POST … /charge creates a new effect each time — two deliveries charge the customer twice — so it needs a key that carries the caller's intent: "this is the same request, not another one."

(ii) The workflow. ① Check — is this key already in the store? ② Executing — if it is new, claim it with status "Processing" and run the business logic. ③ Finished — store the response body against the key with status "Completed" (typically with a TTL). ④ Replay — if the same key arrives again, return the stored response without running the logic again.

(iii) One mistake (any of these). Implementing steps ① and ② as separate operations — "check whether it exists, then insert" is a race that two simultaneous duplicates both win, so both charge; the claim must be atomic (a unique-constraint insert, or Redis SET NX). Alternatively: letting the claim, the side effect and the stored response commit separately, so a crash between "charged" and "recorded" strands the key half-finished and refuses every retry while the money has already moved; not scoping keys per caller, so two tenants collide; storing only "done" instead of the status code and the response body, so the retrying client gets a different answer from the original; or keys with no expiry, so the store grows forever.

CQRS separates the model used to change state (commands: create/update/delete, returning success or an id rather than data) from the model used to read state (queries, returning data and changing nothing). The two jobs want opposite things: writes want normalisation, validation and enforced invariants; reads want denormalised, pre-joined shapes tuned for one screen — and reads usually outnumber writes by orders of magnitude.

Benefit: each side can be modelled, optimised and scaled independently — for example a relational write store with real transactions alongside a document store or cache tuned purely for read speed. Cost: the read model is kept up to date by a projector consuming events, so it is only eventually consistent, and there are now two stores plus a projector to build and monitor. The user-visible problem is read-your-own-writes: a user saves a change, the query hits a read model that has not caught up, and they are shown the old value — "I saved it and it didn't appear." Standard fixes are to return the new state directly from the command, or to serve that user's own recent reads from the write model.

Creditworthy: noting that CQRS does not require event sourcing, and that a separate read database is an optional escalation rather than part of the definition.

(i) A sidecar is a helper component deployed alongside the main service — in the same pod/deployment unit, sharing its lifecycle and local network — that takes over peripheral, cross-cutting concerns so the service contains only business logic. Typical responsibilities: mutual TLS between services, retries and timeouts on outgoing calls, metrics and distributed tracing, service discovery and load balancing. It is provided at the infrastructure level (Envoy, Istio) rather than written into the application, and the main benefit is that changing, say, the retry policy is one configuration change rather than a library bump and a redeploy of every service in every language.

(ii) A failing liveness probe means "this process is broken beyond recovery — restart it." So during the 30-second database outage every pod fails liveness simultaneously and the platform restarts all of them at once, turning a brief dependency blip into a full application outage — and the restarted pods still cannot reach the database, so they may crash-loop. Dependency checks belong in the readiness probe, which means "don't send me traffic right now": failing it removes the pod from the load balancer and puts it back automatically once the database recovers, with no restarts. Liveness should check only that the process itself is functioning.