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

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

Expand Messages
  • lasse.koskela@accenture.com
    ... Good point... - Lasse - This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If
    Message 1 of 3 , Jun 2, 2004
    • 0 Attachment
      J.B.:
      > 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.


      Good point...

      - Lasse -



      This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.


      [Non-text portions of this message have been removed]
    • lasse.koskela@accenture.com
      Note that I said PicoContainer-*like* approach. If I have understood the setter/constructor injection stuff correctly, it means that you create a Container
      Message 2 of 3 , Jun 2, 2004
      • 0 Attachment
        Note that I said "PicoContainer-*like*" approach.

        If I have understood the setter/constructor injection stuff correctly, it means that you create a Container and a number of Components. Then you register the components with the Container, one by one, at which time the Container uses reflection to figure out what kind of dependencies the Component in question needs (either based on constructor arguments or setter method arguments) and tries to locate matching Components from its internal component registry.

        In other words, you're letting "someone else" (the container) wire up your components instead of writing a long piece of bootstrap code for doing the same. You can test your components without the container, but your "production" setup still gets its dependencies via some magic so the "I don't know what's happening under the hood" problem is still there.

        Now, all this pretty much makes sense (both the pros and the cons) from what I can get out of reading overviews, blogs, etc. What I don't know is how it works out in the real world?

        - Lasse -

        -----Alkuperäinen viesti-----
        Lähettäjä: Steve Bate [mailto:steve@...]
        Lähetetty: ke 2.6.2004 15:56
        Vastaanottaja: extremeprogramming@yahoogroups.com
        Kopio:
        Aihe: RE: [XP] Component registries (was: Testing Leftover)



        > 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).

        > 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 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. :)

        Steve




        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

        ad-free courtesy of objectmentor.com
        Yahoo! Groups Links









        This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.


        [Non-text portions of this message have been removed]
      • Keith Ray
        XMLTalk (which seems to no longer publicly available) used XML to document the connections between objects - both the embedding of widgets within windows or
        Message 3 of 3 , Jun 2, 2004
        • 0 Attachment
          XMLTalk (which seems to no longer publicly available) used XML to
          'document' the connections between objects - both the embedding of
          widgets within windows or views, and the connections between 'model'
          objects and 'view/controller' objects. The parser reads the xml,
          instantiates the named classes, and connects the objects together. You
          can take typical "book-example" Java code that constructs views and
          model objects and connects them, and refactor them into something like
          XMLTalk.

          On Jun 2, 2004, at 3:20 AM, lasse.koskela@... wrote:

          > J.B.:
          >> 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.
          >
          >
          > Good point...
          >
          > - Lasse -
          >
          >
          >
          > This message is for the designated recipient only and may contain
          > privileged, proprietary, or otherwise private information. If you
          > have received it in error, please notify the sender immediately and
          > delete the original. Any other use of the email by you is prohibited.
          >
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >
          --
          C. Keith Ray
          <http://homepage.mac.com/keithray/blog/index.html>
          <http://homepage.mac.com/keithray/xpminifaq.html>
          <http://homepage.mac.com/keithray/resume2.html>
        Your message has been successfully submitted and would be delivered to recipients shortly.