The strategy design pattern is another commonly used design pattern.

It is used when you might have multiple ways (different implementations) to do a task.

An example

for example if you have files or data that you need to save you might have the option of saving them to a database, to the local filesystem or upload it to a 3rd party cloud storage provider such as Amazon S3.

You could write a long winded if/elseif/else function like this, letting you decide where to store each item:

But don't write something like this! This is just to show what you could do...
  1. function save_data($input, $whereTo='db')
  2. {
  3.     if ($whereTo == 'db') {
  4.         var_dump(__FUNCTION__ . " Saving '$input' to database");
  5.     }
  6.     elseif ($whereTo == 'filesystem') {
  7.         var_dump(__FUNCTION__ . " Saving '$input' to local filesystem");
  8.     }
  9.     elseif ($whereTo == 'amazons3') {
  10.         var_dump(__FUNCTION__ . " Saving '$input' to amazon s3");
  11.     }
  12.     else {
  13.         throw new \Exception;
  14.     }
  15. }
  16.  
  17. $data_to_save = "foo";
  18. save_data($data_to_save,'db');

Which would output string(34) "save_data Saving 'foo' to database". But this code is really messy

(this is a very simplified example - in reality, there would be big chunks of messy code for a function like this).

It is much better to use the strategy design pattern. Here is how it would look:

Define an interface

Each way of doing a task will be its own class (so one class for DBSaver, one for LocalFileSaver, one for AmazonS3Saver). Each of these tasks (for this example) must have a save($input) method. So there should be an interface:

  1. interface Saver
  2. {
  3.     public function save($input);
  4. }

This is a very simple interface, with just one method. In the real world, you might have something a bit more complicated.

Now we need the 3 example classes for the different ways of doing this task (of saving)
  1. class DBSaver implements Saver
  2. {
  3.     public function save($input)
  4.     {
  5.         var_dump(__METHOD__ . " Saving '$input' to DB table");
  6.     }
  7. }
  8. class LocalFileSaver implements Saver
  9. {
  10.     public function save($input)
  11.     {
  12.         var_dump(__METHOD__ . " Saving '$input' to local filesystem");
  13.     }
  14. }
  15. class AmazonS3Saver implements Saver
  16. {
  17.     public function save($input)
  18.     {
  19.         var_dump(__METHOD__ . " Saving '$input' to amazon s3 (cloud) storage");
  20.     }
  21. }
And now let's save a file

Maybe this data was submitted by a user, and they can select where it should be saved.

(I'm using a function here to keep things quicker to explain, rather than set up a whole class for this)

  1. $user_submitted_data = "foo"; // the data to save
  2. $user_submitted_where_to_save_to = 'local';  // where to save it
  3.  
  4. // so we can get the class to use, from the user submitted value
  5. // I will assume some validation has already occurred and we know that $user_submitted_where_to_save_to is one of these keys
  6. $savers = [
  7.     'db'=>DBSaver::class,
  8.     'local'=>LocalFileSaver::class,
  9.     's3'=>AmazonS3Saver::class,
  10. ];
  11.  
  12. // create the required object -
  13. $saver_object = new $savers[$user_submitted_where_to_save_to]; // i.e. new $savers['local'] which is the same as new LocalFileSaver();
  14.  
  15. // and send that object (and the submitted data) to some function that will save it.
  16. save($user_submitted_data, $saver_object);
  17.  
  18. // notice that the 2nd param for this function is an object that implements the Saver interface
  19. function save($data, Saver $saver)
  20. {
  21.     return $saver->save($data);
  22. }

The function at the end isn't needed in this simple example, but I wanted to just show that you can type hint the interface

Some notes on the strategy pattern

  • I've used just interfaces here. But you can also use abstract classes, if they will be sharing common code.

Real life examples of the strategy pattern

If you use Laravel then you are probably used to the config options, such as in config/logging.php you have this line:

  1. 'default' => env('LOG_CHANNEL', 'stack'),

You can set it to various options such as 'stack', 'stderr', 'single' - each of these will load a different logging class - this uses the strategy pattern.

The same for encryption - you might have a main function (or method) to encrypt things. But in the config options, you might be able to define what encryption method to use. A strategy pattern will be used, with each encryption method being its own class that implements a common interface.

Design pattern type: Behavioural design pattern