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."
Showing posts with label Dependency Injection. Show all posts
Showing posts with label Dependency Injection. Show all posts
Friday, January 16, 2015
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/
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
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...
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...
Thursday, October 2, 2014
From Singleton to AOP (And Everything in Between)
This article on game development touches on the nuances faced and the angst developers face when dealing with complex systems and still adhering to best practices ala IoC. The highest voted answer seems to favor neither the service locator pattern nor the singleton, but seems to lean toward dependency injection ("passing around the instances"). Nevertheless the OP appears to settle on Service Locator.
http://gamedev.stackexchange.com/questions/84197/how-can-i-avoid-having-many-singletons-in-my-game-architecture
An alternative to all three could be AOP as shown in this old article: http://blogs.msdn.com/b/simonince/archive/2008/06/30/dependency-injection-is-dead.aspx
But if you think that DI is hard, DI via AOP is certainly an order of magnitude harder -- which is probably why it's not spoken of much.
http://gamedev.stackexchange.com/questions/84197/how-can-i-avoid-having-many-singletons-in-my-game-architecture
An alternative to all three could be AOP as shown in this old article: http://blogs.msdn.com/b/simonince/archive/2008/06/30/dependency-injection-is-dead.aspx
But if you think that DI is hard, DI via AOP is certainly an order of magnitude harder -- which is probably why it's not spoken of much.
Subscribe to:
Posts (Atom)