The Strategy Design Pattern organizes a family of algorithms behind common interfaces. A client selects interchangeable strategies at run time, so each algorithm can change independently of the client that uses it. section 8.2 section 8.2.3
A Strategy-based design typically provides:
- A client class that aggregates strategy objects through interfaces rather than depending on concrete implementations. section 8.2.3
- Separate strategy families when one client coordinates different variable behaviors, such as player recruitment and venue reservation. section 8.2 section 8.2.3
- Runtime replacement of an algorithm, reducing hardcoded behavior and limiting changes when algorithms are added or modified. section 8.2 section 8.2.3
Sports teams and venues
Sport stores PlayerStrategy and VenueStrategy objects. Baseball supplies BaseballPlayers and Stadium; Football supplies FootballPlayers and Stadium; Volleyball supplies VolleyballPlayers and OpenField. Calling recruit_players() or reserve_venue() delegates to the selected strategy. Volleyball can later replace OpenField with Stadium without changing the Sport superclass. section 8.2.3
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() member function. The Baseball, Football, and Volleyball subclasses are now much simpler, and each one sets the player_strategy and venue_strategy member variables of the Sport superclass.
Use the class-and-interface diagram to trace the client, strategy interfaces, concrete strategies, and their has-a relationships. section 8.2.3
