Randolph Kahle wrote:
[...]
So has anyone actually read the article yet? :-)
Yes; I skimmed it.
It seems that IoC has entered the "Ooops, maybe it doesn't do what we really need unless we make it much more complex" phase of adoption.
IoC is just a way of abstracting that which has been implemented many, many times before in your code: configuration factories. Spring, HiveMind, PicoContainer, Avalon (RIP) et al seek to allow you to use POJOs in a composeable fashion without the need to static factory lookups, JNDI lookups, etc. This allows for a nice plugability of one object for another; simple construction of a driver-based data source, for example, can be replaced by a JNDI lookup of a data source from a container without having to change the code one bit. The "change the code" is the thing that makes IoC attractive; I can layer declarative transactions onto plain Java objects without polluting my objects with transaction-handling code. I can plug Mock objects into strategic places for testing.
OO programming itself has similar goals of reducing complexity in this fashion. It had much more hype in the beginning as the savior of humanity; it has since proven to be a solid concept that we all use and enjoy. But, as we all know, there is good design and bad design. IoC is the same way; if used properly and with good judgement it can make your job simpler. If you go overboard and just throw stuff into the configuration willy-nilly with no design or plan then it will be "complex".
I have seen sophisticated systems that are easy to understand because the design was very good; I have also seen the "big glob of code" for projects that was impossible to comprehend and needlessly complicated. The different between the two is *how* the frameworks and tools were used, not inherently in the tools themselves. The former had Spring configuration files separated logically into sections and a plan for where things go, layered into the discrete parts; Spring autowire, autoproxy factories and custom property configurers are used to reduce the amount of configuration and external Java code needed to do the setup. The latter project attempts to put everything into one Spring config file, makes "target" objects soley for the purpose of proxy targeting, etc. The config file is impossible to understand yet it is simpler in the amount of stuff it's doing than the first project I mentioned.
I'm going to lump Hibernate in here with my critique because it is part of a trend toward using POJOs (that conform to "idiomatic Java") as much as possible with no "framework intrusion". This trend is vital to the next stage of Java development, I think. Java has reached a point that there are so many APIs and frameworks in any decent-sized project that having to carry around code that works with them all is quite burdensome - I'd rather carry around configuration files that know how to assemble working parts for me and I override a few key methods that implement the guts and allow me to forget about the setup/teardown/configuration details.
My entire point here: it's all in the usage of the tool. I believe that Spring and Hibernate allow you to do things the right way. There will be a shakeout of best practices, but that's a very good thing for everyone. There will be "bad Spring" and "good Spring" and eventually all of the bad Spring will be filtered out as people learn and disseminate best practices.
- Drew
-- +---------------------------------+ < Drew Davidson | OGNL Technology > +---------------------------------+ | Email: [EMAIL PROTECTED] / | Web: http://www.ognl.org / | Vox: (520) 531-1966 < | Fax: (520) 531-1965 \ | Mobile: (520) 405-2967 \ +---------------------------------+
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
