25-Comp-B11 Advanced Software Design · December 2018
Question 11 of 28: Implementing the Liskov Substitution Principle Without Knowing Subclasses
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
17-Comp-B11 Advanced Software Design — National Exams, December 2018. 3 hours, closed book exam with up to 2 aid sheets 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, 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 and the "program to an interface, not an implementation" / "favor object composition over class inheritance" principles; 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; Barbara Liskov's 1987 substitutability paper for Question 11; Karl Wiegers, Software Requirements (3rd ed.) — the functional/quality/process/implementation/business requirements taxonomy of Question 2; Kruchten, The Rational Unified Process: An Introduction, for Question 1; Myers, The Art of Software Testing, for Questions 6 and 28.
PART I — General Principles (answer any 5 of 7)
Question 11: Implementing the Liskov Substitution Principle Without Knowing Subclasses (Part II)
The Liskov Substitution Principle (LSP, Barbara Liskov, 1987) requires that any future subclass be substitutable for its superclass without breaking client code — formalized (Question 10) as: a subtype's precondition must be no STRONGER than the supertype's, its postcondition no WEAKER, and its invariant preserved.
Since the superclass designer cannot know every future subclass, LSP compliance must be engineered into the SUPERCLASS's own contract, defensively, rather than verified against subclasses that do not yet exist:
Keep preconditions as weak as the operation genuinely requires, never stronger "just in case" — every extra restriction in the superclass's precondition is a restriction every future subclass inherits and must not strengthen, so an unnecessarily strong precondition needlessly narrows what future subclasses may safely do.
State postconditions and invariants precisely and completely, including behaviour a careless subclass might accidentally violate (the classic Rectangle.setWidth leaving height unchanged is an IMPLICIT postcondition that, left undocumented, is easy for a Square subclass to break without realizing it violates anything).
Document the invariant and contracts explicitly, not just informally in comments, so a subclass author has an unambiguous, checkable specification of what must be preserved, rather than having to infer it from the superclass's implementation.
Favor final/sealed methods for behaviour subclasses must not be allowed to alter, and expose only well-defined extension points (abstract methods with a clearly documented contract, as in Question 17's Template Method) for behaviour that legitimately varies — this prevents an unanticipated subclass from overriding something the invariant depends on.
In short, since the superclass author cannot verify LSP against subclasses that do not exist yet, the only available strategy is to make the superclass's OWN contract narrow enough to leave room for extension, but precise and complete enough that any subclass honestly satisfying that written contract is automatically LSP-compliant by construction.
