25-Comp-B11 Advanced Software Design · December 2018
Question 8 of 28: Pros and Cons of Design by Contract vs. Defensive Programming
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)
PART II — Design by Contract (answer any 3 of 5)
Question 8: Pros and Cons of Design by Contract vs. Defensive Programming (Part II)
Both approaches aim to keep an operation's behaviour correct in the presence of possibly-invalid input, but they place the RESPONSIBILITY for ensuring validity on opposite parties.
Design by Contract (DbC). Makes the CALLER responsible for satisfying an operation's precondition (Question 10). Pro: no redundant runtime checks in production code once a precondition is proven satisfied by construction, and a violation is unambiguously the caller's bug, sharply localizing fault assignment. Con: if assertions are compiled out in production (a common practice for performance), an actual precondition violation goes completely unchecked at runtime and can propagate silently. Example (Stack.pop()): the precondition is !isEmpty(); the implementation does not re-check emptiness in the production build, only via an optional debug assertion.
Defensive programming. Makes the SUPPLIER responsible: it validates and sanitizes every input itself, at every call, regardless of what the caller was "supposed" to guarantee. Pro: robust at a trust boundary where the caller genuinely cannot be trusted (public APIs, user input, external systems) — the check runs in every build, always. Con: duplicated, wasted validation when applied to internal, tightly-coupled code where the caller's obligations are already documented and enforced by contract, adding both runtime cost and code bulk with no added safety. Example: the same pop() explicitly checks isEmpty() first and, if true, throws a documented EmptyStackException every single time, in every build.
When each is appropriate. Defensive programming is essential at a system's trust boundary; DbC is more appropriate for internal, tightly-coupled code within one team/module. Good practice combines both: defend rigorously at the boundary, and rely on documented, assertion-checked contracts internally.
