Using a strategy pattern and a command pattern

design-patterns encapsulation strategy-pattern command-pattern
Extrakun picture Extrakun · Oct 7, 2010 · Viewed 37.7k times · Source

Both design patterns encapsulate an algorithm and decouple implementation details from their calling classes. The only difference I can discern is that the Strategy pattern takes in parameters for execution, while the Command pattern doesn't.

It seems to me that the command pattern requires all information for execution to be available when it is created, and it is able to delay its calling (perhaps as part of a script).

What determinations guide whether to use one pattern or the other?

Answer

Huperniketes picture Huperniketes · Oct 9, 2010

I'm including an encapsulation hierarchy table of several of the GoF design patterns to help explain the differences between these two patterns. Hopefully it better illustrates what each encapsulates so my explanation makes more sense.

First off, the hierarchy lists the scope for which a given pattern is applicable, or the appropriate pattern to use to encapsulate some level of detail, depending on which side of the table you start at.

design pattern encapsulation hierarchy table

As you can see from the table, a Strategy Pattern object hides details of an algorithm's implementation, so the use of a different strategy object will perform the same functionality but in a different way. Each strategy object might be optimized for a particular factor or operate on some other parameter; and, through the use of a common interface, the context can safely work with either.

The Command Pattern encapsulates a much smaller level of detail than an algorithm. It encodes the details needed to send a message to an object: receiver, selector and arguments. The benefit to objectifying such a tiny part of the process execution is that such messages can be invoked along different points of time or location in a general way without having to hard-code its details. It allows messages to be invoked one or more times, or passed along to different parts of the system or multiple systems without requiring the details of a specific invocation to be known before execution.

As is typical for design patterns, they do not require all implementations to be identical in detail to bear the pattern name. Details can vary in implementation and in what data is encoded in the object versus as method arguments.

Related questions

What is encapsulation? How does it actually hide data?

Searching turns up a simple definition: data hiding. But, consider the following two examples: 1) First Example: Class Employee { public int age; } 2) Second Example: Class Employee { private int age; public int getAge(){return age;} } Question: In both the above specified examples, …

Read More
Pattern for Creating a Simple and Efficient Value type

Motivation: In reading Mark Seemann’s blog on Code Smell: Automatic Property he says near the end: The bottom line is that automatic properties are rarely appropriate. In fact, they are only appropriate when the type of the property is …

Read More
What is dependency injection?

There have been several questions already posted with specific questions about dependency injection, such as when to use it and what frameworks are there for it. However, What is dependency injection and when/why should or shouldn't it be used?

Read More