2009/10/26 Gili Tzabari <[email protected]> > > Stuart McCulloch wrote: > > 2009/10/26 Gili Tzabari <[email protected] > > <mailto:[email protected]>> > > > > ... but in practice, how often does that actually happen? It > > sounds to > > me like dependency injection is mostly about testability, not code > > reuse, and to that end ClassLoaders are actually less complex than > all > > the hoopla that Guice does under the hood (hint: Guice uses ASM which > > uses bytecode rewriting and possibly even custom ClassLoaders). > > > > Just wondering, have you read > > http://martinfowler.com/articles/injection.html ? > > > > Ironically I've found DI helps me avoid being tied to specific APIs > > (case in point, OSGi services) > > because I can isolate their use in binding modules and providers, rather > > than in the code itself. > > > > And so far DI + services has definitely been good for my users :) > > Okay, I overlooked the "service locator" aspect of DI. Thing is, > how > often do you need this sort of thing? For example, if you're writing > Google Collections, how many of your classes are "services" and need to > be plugable?
Google Collections is a (low-level) library... I'm talking more about composing applications from a suite of modules to satisfy customer needs, which is where I've found DI very useful > Very few if any at all. This reminds me of the new trend of > creating an interface for every class in the API even if there is (and > ever will be) only one concrete implementation. This isn't really a new trend (imagine C without header files) but to be honest most of my APIs are made up of interfaces, not concrete classes - writing an interface is way easier than fleshing out the whole class, and means I can divide up the implementations among developers without worrying too much about compatibility. Of course you don't need to have an interface for every class, but imho the "public" facing part of the API _should_ be made up of interfaces (ie. the contract) unless there's a good reason not to do this. Interfaces and DI have > their uses, but applying them everywhere sounds overkill. > Use the right tool for the job - but you should know it exists, its strengths and weaknesses. Gili > > > > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
