25-Comp-B11 Advanced Software Design · December 2014
Question 6 of 26: The Open–Closed Principle
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
98-Comp-B11 Advanced Software Design — National Exams, December 2014. 3 hours, closed book, no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any three (3) questions in Part I, any four (4) in Part II, any four (4) in Part III, any two (2) in Part IV, and any two (2) 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 15 questions actually marked (3+4+4+2+2 of 26) each count for 100/15 ≈ 6.7% of the paper. All 26 questions are answered below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, agile methods, design principles; 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 (Proxy, Bridge, Strategy, Observer, Template Method, Composite, etc.); Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, inheritance and language-level object semantics (also underpins the Java/C++ discussion in Part V); Brown, Malveau, McCormick & Mowbray, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis — anti-pattern catalogue (Question 18). Bertrand Meyer's Object-Oriented Software Construction is cited by name where the paper's own vocabulary (design by contract, open–closed principle) originates there; Barbara Liskov's 1987 substitutability paper is likewise cited by name for Question 11.
The open–closed principle (OCP, Bertrand Meyer) states that a class or module should be open for extension (new behaviour can be added) but closed for modification (its existing, already-tested source code is never edited to add that behaviour).
The two halves must hold simultaneously, not one alone. "Open" without "closed" — freely editing the class every time new behaviour is needed — means every extension risks re-breaking existing, already-verified clients, and regression risk grows unbounded as the system accumulates features. "Closed" without "open" — a frozen, unmodifiable class with no extension point — would simply be useless once requirements evolve, since nothing could ever be added. Achieving both together is what lets a class be trusted while the system as a whole keeps evolving: the mechanism is abstraction plus polymorphism, so client code and existing subclasses depend only on a stable interface, and new behaviour is added purely by writing new implementations of that interface.
Example. Java's collection-sorting facility takes a Comparator interface: Collections.sort(list, comparator). The sort algorithm's own source code is never touched to support a new ordering — a caller wanting to sort employees by salary instead of by name simply writes a new class implementing Comparator and passes it in. The framework (the sort routine) is closed — nobody edits it — yet open, because arbitrarily many new orderings can be plugged in without ever recompiling it. The benefit is direct: the sort algorithm's own correctness, once verified, is never put at risk by a new sorting need, and new orderings can be developed, tested, and shipped independently of the sort routine itself.
