Flexibility is the ability to change software behavior or accommodate new requirements without modifying its core implementation. Hardcoded decisions bind run-time behavior to source code, so changes can require code edits, retesting, and documentation updates. Good design isolates likely-to-change parts so one modification does not leak across the application. section 8.2 section 1.7
Changing a sport’s venue strategy
A sports application initially hardcodes player-recruitment and venue algorithms into sport-specific classes. Refactoring those algorithms into PlayerStrategy and VenueStrategy implementations lets Sport delegate behavior through interfaces. Baseball, Football, and Volleyball can then select their initial strategies, while a Volleyball object can change its venue from OpenField to Stadium at run time. New algorithms can be added or modified independently, although the extra classes may be excessive for a very small application. section 8.2 section 8.2.3
A flexible design typically:
- Encapsulates each variant of a behavior and makes interchangeable choices through an interface. section 8.2
- Uses composition and delegation so a stable class can execute behavior supplied by strategy objects. section 8.2.3
- Balances change tolerance against added complexity rather than pursuing unlimited flexibility. section 1.7
Figure 8.6 This version of the application is modeled from the Strategy Design Pattern for the sport teams and venues. The player family of algorithms implement the PlayerStrategy interface, and the venue family of algorithms implement the VenueStrategy interface. Class Sport uses has-a relationships to aggregate the algorithms. Each player and venue algorithm has a strategy() method. The Baseball, Football, and Volleyball subclasses are now much simpler, and each one sets the _SPORT_TYPE, _player_strategy, and _venue_strategy instance variables of the Sport superclass.
Trace the strategy interfaces, aggregated algorithms, simplified sport subclasses, and replaceable venue behavior. section 8.2.3
