Sign in to follow this  
ak-73

Design Patterns

Recommended Posts

The Command pattern, the Strategy pattern and the State pattern all seem very similar - they delegate functionality out of class and into a class that then becomes a member of the first class. Can somebody explain the actual differences to me? Alex

Share this post


Link to post
Share on other sites
Quote:
Original post by Codeka
Wikipedia describes the differences pretty well: Command pattern, Strategy pattern, State pattern. What, specifically, are you having trouble understanding?


Well, I don't understand where the difference lies. What sets a Command class apart from a Strategy class? In both cases the client has a pointer to the abstract base class and invokes a method of a concrete derived class.

Take the sample code on the wikipedia Strategy pattern page - replace all Substrings 'Strategy' with 'Command' and I would have mistaken it for a Command pattern sample program.

Where's the difference between the two?

Alex

Share this post


Link to post
Share on other sites
Commands tend to be self contained. You take them, pass them around, they're data that represents a method. They're often very small, and are frequently chained together or modified by a decorator.

A strategy tends not to be self contained. It is usually set to complete an object, and left there until replaced. They tend to be actual delegates (where-as commands are more frequently in a different form, like a string to feed to an interpreter, or tokens of an abstract syntax tree). They tend to be longer; customized to a particular 'slot' since they often interact with the data they're providing behavior for.

A state also tends to be self contained. You don't take them and pass them around. The key part of their structure is construction designed to only allow transition to another state via a certain path and no other. They tend to be a lot of ancillary data and a little bit of code. They also tend not to be implemented as delegates, but instead using normal inheritance.


The key point though is that design patterns exist as a common language for developers to communicate to solve problems. The different patterns it could be argued are variants on one practice, but during communication each has its own connotation. Something that's very important to describe the usage and context of the code.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Commands tend to be self contained. You take them, pass them around, they're data that represents a method. They're often very small, and are frequently chained together or modified by a decorator.

A strategy tends not to be self contained. It is usually set to complete an object, and left there until replaced. They tend to be actual delegates (where-as commands are more frequently in a different form, like a string to feed to an interpreter, or tokens of an abstract syntax tree). They tend to be longer; customized to a particular 'slot' since they often interact with the data they're providing behavior for.

A state also tends to be self contained. You don't take them and pass them around. The key part of their structure is construction designed to only allow transition to another state via a certain path and no other. They tend to be a lot of ancillary data and a little bit of code. They also tend not to be implemented as delegates, but instead using normal inheritance.


The key point though is that design patterns exist as a common language for developers to communicate to solve problems. The different patterns it could be argued are variants on one practice, but during communication each has its own connotation. Something that's very important to describe the usage and context of the code.



Ah, got it. The similarity in content was a bit confusing. Perhaps it would have been better to designate it a single pattern and to distinguish between different roles.

Thanks,
Alex

Share this post


Link to post
Share on other sites
The command pattern encapsulates commands. The strategy pattern encapsulates a class of algorithms. The state pattern encapsulates behavior.

The difference is in the semantics, not the syntax.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this