Design Patterns
Author
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
Wikipedia describes the differences pretty well: Command pattern, Strategy pattern, State pattern. What, specifically, are you having trouble understanding?
Author
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
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.
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.
Author
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
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.
The difference is in the semantics, not the syntax.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
