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

Friday, January 16, 2015

Class Factories and Factory Scopes

Misko Hevery seems to favor factories that perform the manufactoring process for all objects within an object lifetime. See http://misko.hevery.com/2009/03/30/collaborator-vs-the-factory/
This leads to aggregate factories for different scopes such as Application, servlet, Request, etc. I consider these to be equivalent to the IoC container as in Spring's ApplicationContext which is a  factory i.e. a BeanFactory.

But what about "small lifetime" objects which are the factories we usually think of as in the Factory Method pattern which create objects on the fly? This is broached to Misko by Giorgio Sironi at http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/ regarding the creation of a TagFactory as "an example of creation of non-newables (Song example) in the application logic, that is simply delegation to the TagFactory" - alluding to http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/.

Surprising Misko didn't have much to say on it other than "I think you are on the right track."

Mocks Shouldn't Return Mocks

It appears to be a code smell when a mock returns a mock. See hints of why from this thread: http://programmers.stackexchange.com/questions/232442/unit-testing-factories-and-the-law-of-demeter which point to here which shows how application of LoD quickly fixes the problem.

Misko Hevery says the mocked item, e.g. the factory, should actually be returning a "newable" -- the exception being when returning third party objects such as java.io.File. See response to Tom at http://misko.hevery.com/your-suggestions/

Middle Ground between 'Newable' and 'Injectable'?

As noted previously, Misko Hevery asserts that every objects should be either an "injectable" or a "newable."

The question is: why does then Spring support prototype scoped objects which can be injected with well injectables? The condensed and recently supported alternative (through this initiative) to creating a prototype scope object -- which requires access to the ApplicationContext through ApplicationContextAware or BeanFactoryaware (not good* because it becomes a Service Locator "DI Catch 22") -- i.e. the @Lookup or lookup-method with parameters supported is really just syntactic sugar for a prototype scope object, IMO.

On the other hand, the fact that Spring does the wiring under the covers may make @Lookup-with-parameters okay. However, if one tried to do the same in code it would probably violate Misko's rule stating you should not inject an injectable into a newable, where the newable is the prototyped scoped object.


*Note: it may be more nuanced than black and white whether usage of an injected ApplicationContext is or is not good IoC. e.g. see comments by Alex Worden regarding enabling a sort of polymorphism where you "dynamically create new bean instances based on a bean name that is unknown at compile time but matches one of the implementations defined in my spring.xml file" - http://stackoverflow.com/questions/812415/why-is-springs-applicationcontext-getbean-considered-bad this might be a valid use of 'ContextAware. Commenters note that this is not really IoC but rather ordinary factory or Service Locator but pap notes that "Spring is about more than just IoC."

Similar question raised here.

Found this problem is similar to the question of how to do DI and the Command Pattern at the same time. Turns out they may be incompatible. see and see

Monday, January 5, 2015

DI - When to 'new'

Misko advises to keep "newables" separate from "injectables" - so newing things up are okay if they are value objects. http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

I go to that article via a comment in http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/  where he's emphatic about doing the DI. The "newable" exception is very important to consider. Specifically, a newable is an object a DI container would have NO WAY of know how to instantiate -- like a User() or PhoneNumber.

Continued...