Question 14 of 27: Two Variants of the Adapter Design Pattern
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
98-Comp-B11 Advanced Software Design — National Exams, May 2015. 3 hours, closed book exam with one aid sheet allowed (written on both sides), no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any four (4) questions in Part I, any three (3) in Part II, any three (3) in Part III, any two (2) in Part IV, and any four (4) in Part V — only the first questions answered, in each part, as they appear in the answer book are marked. All questions carry equal weight, so the 16 questions actually marked (4+3+3+2+4 of 27) each count for 100/16 ≈ 6.25% of the paper. All 27 questions are answered below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, agile methods, design principles, dependability; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — structural/behavioural pattern catalogue (Adapter, Bridge, Strategy, Observer, Template Method, Composite, etc.); Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, inheritance and language-level object semantics; Bertrand Meyer, Object-Oriented Software Construction — design by contract, preconditions/postconditions/invariants, the open–closed principle; Barbara Liskov's 1987 substitutability paper for Question 11; Rogers, Sharp & Preece, Interaction Design, and Nielsen, Usability Engineering, for Question 21's HMI-specific non-functional requirements.
PART I — General Principles (answer any 4 of 7)
Question 14: Two Variants of the Adapter Design Pattern (Part III)
Adapter converts the interface of an existing class (the Adaptee) into the interface a client expects (the Target), letting classes with otherwise-incompatible interfaces collaborate without modifying either the client or the Adaptee. GoF documents two structurally distinct ways to implement it.
Class Adapter (inheritance-based). The Adapter class INHERITS from Adaptee and implements the Target interface, translating each Target call into the (already-inherited) Adaptee operations. This requires multiple inheritance in the general case (inherit implementation from Adaptee, inherit type from Target) — directly available in C++, and approximated in Java by extending the concrete Adaptee class while implementing the Target interface.
Object Adapter (composition-based). The Adapter HOLDS a reference to a separate Adaptee instance (composition) and implements Target by forwarding/delegating each call to that held instance — the same composition-over-inheritance mechanism examined in Question 26.
Pros/cons — Class Adapter. Because the Adapter IS-A Adaptee, it can override specific inherited Adaptee behaviours directly if needed, and needs only a single object at runtime (no separate Adaptee instance to hold and forward to). Against this: it requires multiple inheritance (unavailable or awkward in single-inheritance languages), and it binds the Adapter to ONE specific concrete Adaptee class at compile time — it cannot transparently adapt any of Adaptee's subclasses as well, since inheritance is fixed to the exact class named.
Pros/cons — Object Adapter. Because it only holds an Adaptee-TYPED reference, a single Object Adapter implementation works polymorphically with Adaptee AND any of its subclasses, and it needs no multiple inheritance, so it works in any OO language (including Java). Against this: every call carries one extra level of delegation indirection, and because the Adapter does not inherit Adaptee's implementation, it cannot override or hook into Adaptee's internal behaviour — it can only call Adaptee's existing public operations, exactly as any other client would.
Left: Class Adapter inherits Adaptee's implementation directly. Right: Object Adapter holds and delegates to an Adaptee instance (works with any subclass).
