In a strategy pattern the main value is in being able to switch out different algorithms for different situations.

Imagine that you had an application component that renders graphs for a website depending on what kind of device made the request. The application code could detect the type of browser and then use the strategy pattern to determine how to render the graphs. By implementing the strategy pattern, the application handles the “choice” in way that is extensible.


When several algorithms (ways to perform an operation) exist and the application should decide the specific way based on parameters.

Some examples:

  • A user registration may need to decide between different profile types.
  • A component that renders graphs depending on the requesting source
  • A CMS may need to create different content types.
  • An application may take payment in different ways.

How SOLID is the strategy Pattern?

[S] The Strategy Pattern permits each subclass to focus on a single responsibility.

[O] If the application was build with TTD (Test Driven Design) or at least involved a reasonable degree of Unit testing, then it is open to extension while remaining closed to modification.

[L] Because the strategize subclasses are implementing an interface, they satisfy the Liskov Substitution Principle.

[ I ] Although by design, the Strategy Pattern should promote the Interface Segregation Principle, it is up to the developer to make sure that is maintained.

[D] The Strategy Pattern quite intentionally decouples the algorithms involved with handling specific situations and their lower lever concerns from the higher level logic that originally “decided” to implement a given component.

How to implement the Strategy Pattern?

Create a well tested interface the meets all the requirements of the application while remaining wide open to extension. Since this interface will be the basis for future logic, it is important to make sure to include the minimum requirements needed by all situations. Do not try to cover all the bases here. Instead leave room for addition interfaces if needed. If you try to cover all the bases, you end up forcing a method where it may not be needed – violating the Interface Segregation Principle.

namespace Pkl\Strategies\Profiles;

interface ProfileStrategy
	public function setUser(User $user);
	public function getUser();
	public function getType();

Create classes that implement the interface and handle more specific situations. These are the classes that will be implemented once the application logic make a “decision” on which one is appropriate.

Create logic, preferably iterative logic with a good naming convention, to handle application “choices” of which strategy to implement.

Use iterative logic

If your decision making logic has used iterative logic with a good naming convention, the coding footprint will remain small. Using iterative logic when possible instead of if statements or switch statements will keep the code from growing with every additional extension of the strategy. Everyone likes nice neat code, right?

Well documented code tells the story

A good documentation style is important to keeping the code readable. Well documented code will help make the iterative logic handling the strategy routing easier to work with. Be sure to use classnames and method names that “tell the story”. Making your coding style communicate to yourself or other developers can save a lot of time. In the future, you or another developer, can further create classes that extend the original strategic interface to handle other more specific situations.

Leave a Reply

Your email address will not be published. Required fields are marked *