Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Component registries (was: Testing Leftover)

Expand Messages
  • J. B. Rainsberger
    ... WARNING: I have not used PicoContainer on a real project, so I may be repeating incorrect info. Feel free to set me straight, and I m glad you did. ... I
    Message 1 of 4 , Jun 2, 2004
    • 0 Attachment
      Steve Bate wrote:

      >>From: J. B. Rainsberger [mailto:jbrains@...]
      >>lasse.koskela@... wrote:
      >>
      >>>This reminds me of an approach to structuring a codebase where
      >>>one uses a PicoContainer-like approach with certain classes
      >>>directly referencing a "component registry" from which they can
      >>>do a getInstance(SomeInterface.class) to get their dependencies.
      >>>
      >>>The question is, have some of you folks out there tried this on
      >>>a large scale and how did you feel about it (especially regarding
      >>>testability)? ...
      >>
      >>I use this exact approach, but with Constructor Injection, rather than a
      >>pseudo-Service Locator.
      >
      > Can you clarify the comments you and Lasse are making about Pico?
      > Constructor
      > Injection is considered Pico's most important feature.
      > http://www.picocontainer.org/Constructor+Injection
      >
      > We've done some spikes with Pico although we decided not to use it on our
      > project. Based on that limited experience, I'd say that using Pico primarily
      > as a service locator would not be the best use of the tool (some might
      > consider it an abuse).

      WARNING: I have not used PicoContainer on a real project, so I may be
      repeating incorrect info. Feel free to set me straight, and I'm glad you
      did.

      >>My application entry point wires all the
      >>concrete classes together, but all the classes communicate with one
      >>another through interfaces. This design makes it easy for tests to run
      >>at over 100 per second, which I like.
      >
      > We use a similar technique. I believe the speed is actually due to strict
      > mocking of dependencies, regardless of IOC or service locators. Many of
      > our mocks are set up using IOC but some are provided by service locators.
      > I prefer the IOC approach but the service locators don't impact test speed
      > (ours run at 200+/sec).

      I tend to achieve that degre of mocking of dependencies by aggressively
      inserting interfaces, which is related to IoC concepts.

      >>I don't like Service Locator, whether with PicoContainer or not.
      >>It adds unnecessary magic. If class A should be able to work with any
      >>implementation of interface Z, then I want to be able create an A,
      >>handing it any Z that's convenient at that moment, rather than placing
      >>my convenient Z in that box /way over there/ so that A can walk /way
      >>over there/ and take it out of the box.
      >
      > It sounds like Pico might be a good fit for you given your emphasis
      > is on Constructor Injection. The Spring framework, HiveMind, and XWork
      > are other possibilities.
      >
      > An open IOC-related issue for our team is how to inject dependencies
      > into objects that are dynamically loaded by third party libraries
      > (e.g. an object/relational mapping layer). We are looking at some
      > possible approaches using custom entity persisters in Hibernate. However,
      > this is will require more magic that a service locator. :)

      I absolutely want to use PicoContainer on a near-future project, as I
      think it will be great.

      As for the problem you raise, my subconscious has started working on it.
      If I get an idea, you'll know it. :)
      --
      J. B. Rainsberger,
      Diaspar Software Services
      http://www.diasparsoftware.com :: +1 416 791-8603
      Let's write software that people understand
    Your message has been successfully submitted and would be delivered to recipients shortly.