Question 14 of 28: The Three Types of the Proxy 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 2016. 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 five (5) questions in Part I, any three (3) in Part II, any four (4) in Part III, any two (2) in Part IV, and any five (5) 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 19 questions actually marked (5+3+4+2+5 of 28) each count for 100/19 ≈ 5.26% of the paper. All 28 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 — creational/structural/behavioural pattern catalogue (Singleton, Proxy, Template Method, Observer, 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; Myers, The Art of Software Testing, for Question 28's boundary value analysis.
PART I — General Principles (answer any 5 of 7)
Question 14: The Three Types of the Proxy Design Pattern (Part III)
Proxy provides a surrogate object that controls access to a "real subject" object, implementing the same interface so a client is unaware whether it holds the proxy or the real object. Besides the given Remote Proxy, the other two classic GoF situations are the Virtual Proxy and the Protection Proxy.
Remote proxy (given). Represents an object living in a different address space or on a different machine (an RMI/CORBA stub). The proxy marshals the method call's arguments, sends them across the network to the real object, waits for the reply, and unmarshals the result — hiding all networking and serialization detail so the client's code looks exactly like a local method call.
Virtual proxy. Defers creation of an EXPENSIVE real object until it is actually needed (lazy instantiation). A document editor containing large embedded images can display a lightweight stand-in proxy for each image immediately on open, and only load the full bitmap from disk the first time that image is actually scrolled into view or rendered — saving startup time and memory for images the user never actually views.
Protection proxy. Controls access to the real object based on the caller's permissions. The proxy checks the current caller's access rights before forwarding (or refusing) a request to the real subject, centralizing authorization logic in one place without modifying the real subject's own code — e.g., a proxy placed in front of a sensitive document object checks the current user's role before allowing a read or write call to reach the real document.
All three share the same structural shape: Proxy and RealSubject both implement a common Subject interface, and the client holds only a Subject-typed reference, so it never needs to know which one it actually has — the reason Proxy is itself classified as a structural pattern (Question 15).
