The Strategy Design Pattern encapsulates a family of algorithms and makes them interchangeable at run time. A client delegates behavior to strategy objects instead of hardcoding algorithm variants. section 8.2
Inheritance-based designs place recruiting and venue algorithms in each Sport subclass, creating duplicated code, weak reuse, hardcoded behavior, and change leaks. Composition moves those algorithms into separate strategy families. section 8.2.2 section 8.2.3
A practical Strategy design uses the following structure:
- Define interfaces such as PlayerStrategy and VenueStrategy, each exposing a strategy() operation. section 8.2.3
- Implement interchangeable algorithms such as BaseballPlayers, FootballPlayers, VolleyballPlayers, Stadium, and OpenField. section 8.2.3 section 8.2.4
- Give the client has-a references to strategy objects, then delegate operations such as recruit_players() and reserve_venue(). section 8.2.3
- Select or replace strategies at run time when behavior must vary without changing the client. section 8.2 section 8.2.3
Sports, players, and venues
A Baseball object can use BaseballPlayers and Stadium, while Volleyball can use VolleyballPlayers and OpenField. Replacing volleyball.venue_strategy with Stadium changes its venue without modifying Volleyball or Sport. Shared Stadium behavior is implemented once and reused by baseball and football. section 8.2.3
Use the architecture figure to compare the client, strategy interfaces, concrete algorithms, and has-a relationships. section 8.2
Strategy favors composition over inheritance: the client remains loosely coupled to complete algorithms, which can be added, removed, or updated independently. Template Method instead uses inheritance to preserve an algorithm skeleton while subclasses redefine selected steps. section 8.3
