25-Comp-B11 Advanced Software Design · Undated paper
Question 16 of 28: State vs. Strategy
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
17-Comp-B11 Advanced Software Design — National Exams, May 2019. 3 hours, closed book exam with two 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, testing, dependability, reuse; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/metrics/quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — pattern-language structure, the GoF pattern catalogue, and the "favor object composition over class inheritance" / "program to an interface, not an implementation" principles; Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, visibility, encapsulation, interfaces; Bertrand Meyer, Object-Oriented Software Construction — design by contract, preconditions/postconditions/class invariants; Barbara Liskov's 1987 substitutability paper for Question 12; Stroustrup, The C++ Programming Language, for friend/access-control semantics (Question 25).
Question 12 prints “Liskpv substitution principle”, a typo in the paper; it is answered as the Liskov substitution principle.
State and Strategy have almost IDENTICAL class diagrams — a context holds a reference to an interface, with concrete implementations of that interface providing the varying behaviour — but they differ in INTENT and in WHO controls the current implementation.
State example. A TrafficLight context holds a reference to a LightState interface, with concrete states RedState, GreenState, YellowState. Each concrete state itself decides and triggers the transition to the NEXT state (e.g. GreenState.handle() switches the context's current state to a new YellowState instance). State is used when an object's behaviour depends on which of a finite set of internal states it is in, and the STATES THEMSELVES are aware of the transition graph — replacing a large, error-prone switch-on-state-flag with one small class per state.
Strategy example. A Sorter context holds a reference to a SortStrategy interface, with concrete strategies QuickSortStrategy and MergeSortStrategy. The CLIENT chooses and injects the concrete strategy once (e.g. at construction), and the strategy does not transition itself to a different strategy on its own initiative. Strategy is used to make a family of interchangeable ALGORITHMS pluggable, where the choice is external to the algorithm objects themselves.
The structural diagrams are nearly the same drawing; the difference is behavioural: State objects participate in and often drive transitions among themselves, while Strategy objects are inert, interchangeable algorithms selected from outside.
