Software flexibility is the ease with which a system accommodates new features or changed requirements. Good design isolates likely changes so one modification does not force changes elsewhere, while balancing flexibility against added complexity. section 1.7 section 1.3
Recognize flexibility problems and improve them by:
- Encapsulating requirements-sensitive behavior so changing requirements do not destabilize unrelated code. section 3.5.2
- Isolating what varies, coding to interfaces, and keeping stable classes open to extension but closed to modification. section 2.4
- Replacing hardcoded runtime decisions with interchangeable algorithms when behavior must vary during execution. section 8.2
- Checking whether an abstraction earns its cost, because extra classes can make a small application more complicated. section 8.2.3
Sports strategies that change at runtime
A sports application initially assigns each Sport object player and venue strategies. PlayerStrategy and VenueStrategy interfaces let Baseball, Football, and Volleyball use different algorithm implementations. A Volleyball object can later replace OpenField with Stadium without changing Sport or the other strategy classes. The design reduces duplication, supports independent algorithm changes, and demonstrates has-a relationships and polymorphism. section 8.2.3
Ticket enhancements expose inflexibility
A Ticket class that stores party, VIP, and coupon options as fixed members must change whenever an enhancement is added, removed, or modified. Its cost calculation also knows each enhancement’s implementation. This makes the change leak visible and motivates a more flexible design. section 14.3.2
Use the requirements timeline to see why designs must absorb changes even after an intended requirements freeze. section 3.5.2
