Wednesday, January 21, 2015

Modified Command Pattern

There's some support for a sort of split Command Pattern where the data lives in one object called the "Command" while the behavior resides explicitly in another object e.g. "handler" or implicitly as in the case of Spring MVC (see example code).

As mentioned it appears in Spring MVC and more recently adopted by CQRS developers.

see http://stackoverflow.com/questions/6617976/dependency-injection-when-using-the-command-pattern and https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91

It has benefits for testing because the runtime data is separated from the compile time behavior. This separation is discussed  in the context of dependency injection by Misko Hevery.

I wonder though what OO proponents like Martin Fowler would say to this; i.e. would they deem the artifacts, the commands, to make up an anemic domain model?

On the other hand, according to some the trend seems to be toward separating behavior from objects in certain respects. E.g. I recall Coplien (of DCI) saying "good objects are dumb" implying albeit that the behavior can be injected at runtime. So maybe that's not the best example. But here's a quote from 'User' on Stackoverflow for what it's worth. It's on the example of where should 'validate()' go:
I think in the past CreditCard.Validate() would have been considered good object oriented design but the trend seems to be away from that towards many separate classes.
http://stackoverflow.com/questions/3117800/dependency-injection-when-the-class-created-also-needs-runtime-values

However, Ayende Rahien asserts the opposite is (or should be) taking place (i.e. to move toward putting data and behavior back together?): http://ayende.com/blog/4503/component-oriented-design-and-why-it-be-retired

Notes
The author of this Command/Handler pattern also demonstrated the Query/Handler analog which is extremely telling and revolutionary with regard to deconstructing the Repository pattern as it's commonly implemented: https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92

No comments:

Post a Comment