What?

The strategy pattern is a design pattern designed to accommodate situations when there are multiple ways of doing some/similar thing(s). For instance this might be something along the lines of, if you are designing a media player - you would have different algorithms for playing the different media types. You could use the strategy pattern, as it deals with a common problem of playing a media file, except there are multiple ways it could be done (which algorithm depends on the media type).

How?

Each strategy is made into its own class, in our example above they may be classes like:

Class PlayWAV;
Class PlayMP3;

Each of the above class would implement the IStrategy interface (defined below):

Interface IStrategy {
// This is the function that is called to execute this strategy
public function execute();
}

A pseudo-code (may look similar to PHP code) implementation would look like this:

class PlayWAV implements IStrategy {
// Constructor: Information needed to execute the strategy may be passed through the constructor
public function PlayWAV(File fileObject);
// This needs to be implemented to satisfy the interface; this is the function that would be called to execute the strategy
public function execute();
}

class Context {
public function main() {
...
if (filetype(...) == "WAV") {
$strategyA = new PlayWAV(...);
$strategyA->execute();
} else {
$strategyB = new PlayMP3(...);
$strategyB->execute();
}
...
}
}

Why?

Why the heck would you do this? and not just code everything using an if/else? Well, this provides a clean separation - each strategy is its own entity - this reduces any tight coupling that may be formed knowingly or unknowingly. Since this is build with loose-coupling, you can change each without worrying about affecting the other, and new strategies may be developed independent of the application code and be integrated into the application with ease.

Example

This whole post was explained using an example, another great one can be found here. This one uses the strategy pattern for form validation in PHP.

And now with that I will end this post. Ciao.

Labels: patterns

Observer Pattern: When objects have a one to many relationship, i.e. many objects need to be updated when one object changes, and the number of these objects is not known ahead of time, this pattern can be used to implement it.

We begin by implementing 2 interfaces:

• IObservable: This is the object that gets observed - whose change would affect other objects
  
• IObserver: This represents objects that are the observers

Here is a pseudo-code implementation of the interfaces:

Interface IObservable {
// The attachObserver function adds the passed object to an array
public function attachObserver(obj);
// The detachObserver function removes the passed object from the array
public function detachObserver(obj);
// Notify all the objects in the array - loop through the objects and call the update method
// Note: All the elements in the array implement the IObserver interface and hence
// support the "update" method
public function notify();
// Function would be called by the Observers to get state information about the object
public function getState();
}

Interface IObserver {
// The method that performs the action that needs to be done on change of the observable
public function update();
}

The actual observer and observable classes would implement these interfaces.

Two examples of where you might be using this:

• In a web application, you may register screens with your business model objects (representing underlying data) - hence when the model gets updated, the screens get updated automatically.
• Another example may be, say you are making a game - and you when 1 object performs a task - such as a commander issuing a fire order, all units within the commanders range should fire (they would have registered with the commander object - and as they observed a change, they perform an action).

We have covered what the observer pattern is, how it is coded, and two examples of where it may be used. The answer for the why is the same as why use design patterns (see the post on Design Patterns in general). With that I will end this post. I hope someone, someday, somewhere (may be myself) will find this useful. :)

Labels: patterns

Design patterns: are general solutions to commonly occurring software design problems.

Why patterns? Some problems occur often is software design, and these general solutions avoid having to reinvent the wheel over and over again. The patterns have been looked at by so many people and has been refined well that when they are understood and implemented correctly they can save time, will work efficiently and enable more effective/productive discussions among developers.

I have been exploring patterns recently and I thought I would post about them here

Labels: patterns