This thread got me thinking about alternatives to dependency
injection. The only credible alternative I can think of for Cocoon is
a Service Locator. One of the things I liked about Avalon was its
combination of dependency injection and service locator. This
combination made sense for a general purpose framework. The drawback
is that there is a great deal of complexity due to its use of
interface injection. (probably the real reason Carsten started this
thread) To simplify this all one need do is remove the interface
injection. Once the injection is removed each component is
responsible for constructing its self. The drawback of using a
service locator is the dependency on the locator itself. Cocoon is a
coherent framework that provides its own locator so this is a minimal
stumbling block.
There are two ways we could proceed using a service locator. One
would be to add a static method to a SeviceManager implementation
public static ServiceManager getServiceManager()
The other would be to use constructor injection
public MyComponent(ServiceManager m)
No reflection, no tricks, no jumping through hoops and a simple
contract.
This also provides a way to move away from Avalon while providing the
benefits of life-cycle management by allowing a component to request
its parameters, disposer, etc. by creating other locators. I don't
believe it would be to difficult to keep backwards compatibility
using this technique and all future components will be greatly
simplified.
WDYT?
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
