Cedric is still not getting it
Me neither. Sort of.
While Cedric is wrong about the XML refactoring (Eclipse and IDEA both will attempt to modify class names in XML files), his point is still very valid. I like strongly typed languages, and the idea of putting class names and method names in an XML file doesn’t sound appealing. While IDEA does refactor class names, it won’t refactor method names (well), and it really never will — it’s just too difficult to pull off safely. Imagine refactoring “setId()”!
XWork’s IoC container only stores basic information: class names of the interface and the “enabler” (FooAware). Beyond that, the rest is determined via the interface signatures, meaning refactoring is easy.
In the end, I actually like IoC when used mildly for loose coupling of components. However, it is far from a paradigm shift. It just forces you to identify your dependencies and lifecycles much more cleanly than you otherwise might. There certainly is some power to simply calling dispose() or reset() and knowing that all the dependent objects will also get their dispose() or reset() methods called.
on Mar 30th, 2005 at 11:07 am
To me the value of an IoC container doesn’t really come from the inversion of control. Spring’s value is all the resuable business objects it provides out the box, like daos, it’s incredibly useful Hibernate integration and all that.
But by standardizing on java bean convetions, like getter/setter Ioc, it makes it easier to plug those components into your project. IoC is just a convience, which is why things like PicoContainer, which are ‘just IoC’ are of little interest to me.
on Mar 31st, 2005 at 1:44 am
Haven’t used IDEA, but I know that Eclipse handles method-renames really well. It’s smart enough to distinguish between methods with the same name but belonging to different classes.