(no title)
AndyDavis3416 | 12 years ago
To address your comments:
While it is true that one of the great features (and frequent motivations) for using the Command pattern is the separation of the creation and invocation, it is not the only motivation. The two big payoffs that we are getting are:
- Separation of invocation from the knowledge of how it is carried out
- Composition of complex commands from smaller, simpler commands
There's no requirement that the invoker is never the same as the creator. It's just that most often it isn't, particularly (as you noted) in a worker queue system. That's really just a feature of the implementation that the command readily enables rather than a fundamental property of the pattern. For us, sometimes it is, sometimes it isn't; that's not the primary payoff that we're going for.
I can't support the characterization of this as an Adapter. This is fundamentally behavioral. I have a class that represents an action that I want to have happen. All of the places that want this action do not need to know what is involved, they only need to create the command and hand it off/invoke it.
FWIW - I have five different places in my software that create an AssignCaseCommand. - One controller
- Three commands that can create this as a sub command
- A utility job
Plus that simple concept is available to any custom implementation code that we write.
tel|12 years ago
This is, of course, a primary advantage of having a static representation of the domain-level demands of your code—you can choose many ways and many environments to execute it within. It's a function I use in real code all the time.