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

Effective Java 2nd - Item 1 - The Factory Pattern?

Expand Messages
  • Aeden Jameson
    Hi, On the first page of chapter 2 Bloch states that his item 1 is not the Factory Method pattern described in gang four book. You can read it here
    Message 1 of 9 , Jul 15, 2008
    View Source
    • 0 Attachment
      Hi,

      On the first page of chapter 2 Bloch states that his item 1 is not
      the Factory Method pattern described in gang four book. You can
      read it here

      http://www.ddj.com/java/208403883


      It seems to me Bloch's item 1 fits the intent and motivation of the
      pattern and is therefore just a example of how one could implement it.
      I've never heard of the guy until recently and since he's supposed
      to be a genius I feel like I'm missing something. Help!

      --
      Cheers,
      Aeden
    • Bartels, Mel
      ... On the first page of chapter 2 Bloch states that his item 1 is not the Factory Method pattern described in gang four book. You can read it here
      Message 2 of 9 , Jul 16, 2008
      View Source
      • 0 Attachment
        >>>
        On the first page of chapter 2 Bloch states that his item 1 is not
        the Factory Method pattern described in gang four book. You can
        read it here
        http://www.ddj. com/java/ 208403883
        It seems to me Bloch's item 1 fits the intent and motivation of the
        pattern and is therefore just a example of how one could implement it.
        I've never heard of the guy until recently and since he's supposed
        to be a genius I feel like I'm missing something. Help!
        <<<
         
         
        The static factory pattern is quite different in intent than the factory and abstract factory patterns.
         
        Static factories are strongly identity coupled, typically being encapsulated within the class.  The fundamental class template includes the static factory.  Static factories lead to inversion of control and dependency injection.
         
        Contrast with factory pattern: not encapsulated within the class (it's inverted from this sense) and not strongly identity coupled.
         
        I split code and patterns into three large categories: instantiation (getting it into memory), structure (relationships), and behavior (events, observers).  Static factory is about instantiation but also about structure to some degree.  I don't usually think of factory/abstract factory patterns as having big structure aspects, because they are more loosely coupled.
         
        Does this help?
         
        Mel Bartels
         
      • Scott L. Bain
        I agree with Mel s response (below), and with Josh s original point, but will state it a little differently. Seeing things from multiple angles sometimes adds
        Message 3 of 9 , Jul 16, 2008
        View Source
        • 0 Attachment

          I agree with Mel’s response (below), and with Josh’s original point, but will state it a little differently.  Seeing things from multiple angles sometimes adds clarity.

           

          The difference is also about intent.  The static factory (which I call an “encapsulated constructor”) is really about hiding the “new” keyword away from client objects.  “new” is a problem in that, wherever it appears, you couple very tightly to the actual type you are building (what Josh refers to as “identity coupling”).  When you call a static method to “get an instance”, you could get exactly what you expect, or something else that qualifies (a subtype, etc…).  This promotes the ability to make changes as requirements change.

           

          The Factory Method design pattern is about binding one type to another, where each type is part of a set.  The simplest and perhaps most well-known example is the collections framework that most languages now provide.

           

          Take Java, for instance.  You can have Arraylist, Hashmap, Vector, etc…  all of which cast to List.  In List, there is a method called getIterator() that you can call without “knowing” the actual collection type you are dealing with.  Arraylist overrides this to produce the proper particular Iterator for its structure, Vector overrides it to produce a different Iterator (one that iterates over a Vector) and so on.  All iterators cast to the base type Iterator (or IEnumeration in .Net, etc…), so you get the right one without knowing what you’re getting.

           

          The Factory Method is an abstract, virtual method in a base class that is overridden by subclasses to produce, in each case, the thing that is appropriate to that subclass.  A Static Factory (“Encapsulated Constructor” in my parlance) is a concrete, static method that produces an instance using “new” directly, so the client does not have to.

           

          The real confusion comes, I think, from a poor name.  Any method that produces an instance could be thought of as “a factory method”, but it would only be “The Factory Method Pattern” if it was abstract/overridden and so forth.  An alternate name (from the past) was “Virtual Constructor”, which I personally prefer, but which fell out of usage for some reason.

           

          Hope this helps.  Oh, and I don’t know if Josh Bloch is a genius, but he’s pretty darn sharp. So is Mel.  J

           

          -S-

           

          From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Bartels, Mel
          Sent: Wednesday, July 16, 2008 8:31 AM
          To: leanprogramming@yahoogroups.com
          Subject: RE: [leanprogramming] Effective Java 2nd - Item 1 - The Factory Pattern?

           

          >>>  

          On the first page of chapter 2 Bloch states that his item 1 is not
          the Factory Method pattern described in gang four book. You can
          read it here
          http://www.ddj.com/java/208403883
          It seems to me Bloch's item 1 fits the intent and motivation of the
          pattern and is therefore just a example of how one could implement it.
          I've never heard of the guy until recently and since he's supposed
          to be a genius I feel like I'm missing something. Help!
          <<<

           

           

          The static factory pattern is quite different in intent than the factory and abstract factory patterns.

           

          Static factories are strongly identity coupled, typically being encapsulated within the class.  The fundamental class template includes the static factory.  Static factories lead to inversion of control and dependency injection.

           

          Contrast with factory pattern: not encapsulated within the class (it's inverted from this sense) and not strongly identity coupled.

           

          I split code and patterns into three large categories: instantiation (getting it into memory), structure (relationships), and behavior (events, observers).  Static factory is about instantiation but also about structure to some degree.  I don't usually think of factory/abstract factory patterns as having big structure aspects, because they are more loosely coupled.

           

          Does this help?

           

          Mel Bartels

           


          ______________________________________________________________________
          This email has been scanned by the MessageLabs Email Security System.
          For more information please visit http://www.messagelabs.com/email
          ______________________________________________________________________

        • Aeden Jameson
          On Wed, Jul 16, 2008 at 8:30 AM, Bartels, Mel ... Are they strongly identiy coupled? If I had something like public interface Foo class FooOne implements Foo
          Message 4 of 9 , Jul 18, 2008
          View Source
          • 0 Attachment
            On Wed, Jul 16, 2008 at 8:30 AM, Bartels, Mel
            <Mel.Bartels@...> wrote:
            >>>>
            > On the first page of chapter 2 Bloch states that his item 1 is not
            > the Factory Method pattern described in gang four book. You can
            > read it here
            > http://www.ddj.com/java/208403883
            > It seems to me Bloch's item 1 fits the intent and motivation of the
            > pattern and is therefore just a example of how one could implement it.
            > I've never heard of the guy until recently and since he's supposed
            > to be a genius I feel like I'm missing something. Help!
            > <<<
            >
            >
            > The static factory pattern is quite different in intent than the factory and
            > abstract factory patterns.
            >
            > Static factories are strongly identity coupled, typically being encapsulated
            > within the class. The fundamental class template includes the static
            > factory. Static factories lead to inversion of control and dependency
            > injection.

            Are they strongly identiy coupled? If I had something like

            public interface Foo

            class FooOne implements Foo

            class FooTwo implements Foo

            public class Factory
            {
            public static Foo Create( int choice ) {....}
            }

            This is static factory method. No? And it's as loosely coupled as you
            can design for. No?


            > Contrast with factory pattern: not encapsulated within the class (it's
            > inverted from this sense) and not strongly identity coupled.

            Does the a static factory method have to be in the same class? What do
            you call the
            above example ?


            --
            Cheers,
            Aeden
          • Bartels, Mel
            ... public class Factory{ public static Foo Create( int choice ) {....} } This is static factory method. No? And it s as loosely coupled as you can design for.
            Message 5 of 9 , Jul 18, 2008
            View Source
            • 0 Attachment
              >>>
              public class Factory{
                  public static Foo Create( int choice ) {....}
              }
              This is static factory method. No? And it's as loosely coupled as you
              can design for. No?
              <<<
               
              Ah, not really.  You are ignoring intent.  That's the equivalent of taking your Lexus and spray painting 'truck" on the doors then hauling wood chips in it.   You can do it but you ignore the intent of the car's design.
               
              That's why 'code by intent' and 'intend what you code' are such important principles.  It's trivial to split code from intent causing context issues down the road.  A method used for a different context than was originally intended is a nightmare to refactor/maintain/edit/test.
               
              Perhaps a better name than 'static factory'  as Scott Bain uses will help.  I fell into the 'static factory' name because it's the only factory type that the teams I work with declare as static.  There are important reasons to keep concrete and abstract factories dynamic.  And there are important reasons to make instance encapsulators static, having to do with 'closeness' to the class loader.
               
              Well, hope this helps, Mel Bartels
               
            • Aeden Jameson
              Ok I think the heart of my confusion has been thinking that the Gof pattern was the general notion of a factory, As Scott said, anything that produces an
              Message 6 of 9 , Jul 19, 2008
              View Source
              • 0 Attachment
                Ok I think the heart of my confusion has been thinking that the Gof
                pattern was the general notion of a factory, As Scott said, "anything
                that produces an instance" instead of what the Gof pattern is actually
                stating. I think that clears up the confusion in my original question,
                but now I'm little thrown off by various ideas in the replies.


                > Contrast with factory pattern: not encapsulated within the class

                ...because the new keyword isn't encapsulated within the class?


                > (it's inverted from this sense) ....
                I'm not sure what you mean by this.


                > Ah, not really. You are ignoring intent. That's the equivalent of taking
                > your Lexus and spray painting 'truck" on the doors then hauling wood chips
                > in it. You can do it but you ignore the intent of the car's design.

                I now see that one issue with the example I provided is it doesn't
                enforce the inversion of
                control of the new operator. EnumSet example stated in the article
                clarifies this for me.
                Ok, out of curiousity what would be your statment of intent for the
                static factory method?


                >and not strongly identity coupled.
                What's the difference between strongly identity coupled and identity coupled?


                > Perhaps a better name than 'static factory' as Scott Bain uses will help.

                Yeah.


                > And there are important reasons to make instance encapsulators static, having to do with 'closeness'
                > to the class loader.

                Would you elaborate?




                --
                Cheers,
                Aeden
              • Scott L. Bain
                I ll take a run at trying to clear up the point here... at least, in the way I look at it. In OO design, one thing we try to do is to avoid coupling to
                Message 7 of 9 , Jul 21, 2008
                View Source
                • 0 Attachment

                  I’ll take a run at trying to clear up the point here… at least, in the way I look at it.

                   

                  In OO design, one thing we try to do is to avoid coupling to concrete types.  We know that we have to create coupling in systems, because the very nature of being “object-oriented” is that we break up solutions into cohesive objects, encapsulating each responsibility of the system into separate objects.  But we would like this coupling, as much as possible, to involve abstract types rather than concrete ones.  It’s an aspect of the GoF advice that says “design to interfaces”.

                   

                  Code like this:

                   

                  class client {

                  Service myService = new Service();

                                  myService.doStuff();

                  }

                   

                  …creates coupling to the concrete type Service within the class Client.  This is inherent whenever the keyword “new” is used in languages like Java and C#, because we are not permitted to override “new” to produce anything other than an instance of the literal class Service.

                   

                  If Service is later changed to an abstract class, this code breaks (and, if this is in many places, or used by other teams, this can be significant).  Even if Service stays concrete, but we wish (due to a changing requirement) to build a sub-type of Service, we’ll have to make lots of changes all over the place, and the logic to select the “right one” will be duplicated in all those places.

                   

                  Code like this:

                   

                  class client {

                  Service myService = Service.getInstance();

                                  myService.doStuff();

                  }

                   

                  …would seem to create concrete coupling, but does not.  Service.getInstance() does not have to return an actual instance of Service (even if it does now, this can easily be changed).  It can create anything that “qualifies” as Service.  It’s a method, so we control it, which makes it distinct from “new”.

                   

                  I call this an encapsulated constructor, Bloch is calling it a static factory.

                   

                  The Factory Method Pattern is really a complete different issue, with a different reason for being, and with different effects (look back at my example about collections for more on this).  There are many factory patterns, each of which does something different, and when you have the motivation to use them you’ve usually already solved this “concrete coupling’ problem.  I use the encapsulated constructor trick when I don’t have a justification to do something more complex.  It is an “at least” sort of practice, for me.

                   

                  Hope this helps !

                   

                  -Scott-

                   

                   

                  From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Aeden Jameson
                  Sent: Saturday, July 19, 2008 9:12 PM
                  To: leanprogramming@yahoogroups.com
                  Subject: Re: [leanprogramming] Effective Java 2nd - Item 1 - The Factory Pattern?

                   

                  Ok I think the heart of my confusion has been thinking that the Gof
                  pattern was the general notion of a factory, As Scott said, "anything
                  that produces an instance" instead of what the Gof pattern is actually
                  stating. I think that clears up the confusion in my original question,
                  but now I'm little thrown off by various ideas in the replies.

                  > Contrast with factory pattern: not encapsulated within the class

                  ...because the new keyword isn't encapsulated within the class?

                  > (it's inverted from this sense) ....
                  I'm not sure what you mean by this.

                  > Ah, not really. You are ignoring intent. That's the equivalent of taking
                  > your Lexus and spray painting 'truck" on the doors then hauling wood
                  chips
                  > in it. You can do it but you ignore the intent of the car's design.

                  I now see that one issue with the example I provided is it doesn't
                  enforce the inversion of
                  control of the new operator. EnumSet example stated in the article
                  clarifies this for me.
                  Ok, out of curiousity what would be your statment of intent for the
                  static factory method?

                  >and not strongly identity coupled.
                  What's the difference between strongly identity coupled and identity coupled?

                  > Perhaps a better name than 'static factory' as Scott Bain uses will help.

                  Yeah.

                  > And there are important reasons to make instance encapsulators static,
                  having to do with 'closeness'
                  > to the class loader.

                  Would you elaborate?

                  --
                  Cheers,
                  Aeden


                  ______________________________________________________________________
                  This email has been scanned by the MessageLabs Email Security System.
                  For more information please visit http://www.messagelabs.com/email
                  ______________________________________________________________________

                • Max Guernsey, III
                  This is kind of askew the main line of the conversation, but I ll say it anyway. Scott nailed one of the reasons why encapsulated constructors are so important
                  Message 8 of 9 , Jul 21, 2008
                  View Source
                  • 0 Attachment

                    This is kind of askew the main line of the conversation, but I’ll say it anyway.

                     

                    Scott nailed one of the reasons why encapsulated constructors are so important right on the head: it’s not having to switch from the use of one constructor to another every where the constructor was used that kills you; a compiler will tell you when you are “done” with that.  It’s having to duplicate the logic deciding which type of object to use everywhere that can really hurt you.

                     

                    Let me throw another reason to do it out there.  Really this is just codifying the principle which underlies the consequences delineated below by Scott.  A class should never expose how something is done to its clients.  It should only provide them with an interface that they can use to indicate what they want done.  “new” is all about “how” in most languages for the very reason that Scott mentions below: there is no reasonable way to alter its behavior.  Not encapsulating a constructor is tantamount to making a field public rather than exposing access to it via getters and setters.

                     

                    Max Guernsey, III

                    Managing Member, Hexagon Software

                    http://www.hexsw.com

                    http://www.dataconstructor.com

                     

                    From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott L. Bain
                    Sent: Monday, July 21, 2008 12:21 PM
                    To: leanprogramming@yahoogroups.com
                    Subject: RE: [leanprogramming] Effective Java 2nd - Item 1 - The Factory Pattern?

                     

                    I’ll take a run at trying to clear up the point here… at least, in the way I look at it.

                     

                    In OO design, one thing we try to do is to avoid coupling to concrete types.  We know that we have to create coupling in systems, because the very nature of being “object-oriented” is that we break up solutions into cohesive objects, encapsulating each responsibility of the system into separate objects.  But we would like this coupling, as much as possible, to involve abstract types rather than concrete ones.  It’s an aspect of the GoF advice that says “design to interfaces”.

                     

                    Code like this:

                     

                    class client {

                    Service myService = new Service();

                                    myService.doStuff();

                    }

                     

                    …creates coupling to the concrete type Service within the class Client.  This is inherent whenever the keyword “new” is used in languages like Java and C#, because we are not permitted to override “new” to produce anything other than an instance of the literal class Service.

                     

                    If Service is later changed to an abstract class, this code breaks (and, if this is in many places, or used by other teams, this can be significant).  Even if Service stays concrete, but we wish (due to a changing requirement) to build a sub-type of Service, we’ll have to make lots of changes all over the place, and the logic to select the “right one” will be duplicated in all those places.

                     

                    Code like this:

                     

                    class client {

                    Service myService = Service.getInstance();

                                    myService.doStuff();

                    }

                     

                    …would seem to create concrete coupling, but does not.  Service.getInstance() does not have to return an actual instance of Service (even if it does now, this can easily be changed).  It can create anything that “qualifies” as Service.  It’s a method, so we control it, which makes it distinct from “new”.

                     

                    I call this an encapsulated constructor, Bloch is calling it a static factory.

                     

                    The Factory Method Pattern is really a complete different issue, with a different reason for being, and with different effects (look back at my example about collections for more on this).  There are many factory patterns, each of which does something different, and when you have the motivation to use them you’ve usually already solved this “concrete coupling’ problem.  I use the encapsulated constructor trick when I don’t have a justification to do something more complex.  It is an “at least” sort of practice, for me.

                     

                    Hope this helps !

                     

                    -Scott-

                     

                     

                    From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Aeden Jameson
                    Sent: Saturday, July 19, 2008 9:12 PM
                    To: leanprogramming@yahoogroups.com
                    Subject: Re: [leanprogramming] Effective Java 2nd - Item 1 - The Factory Pattern?

                     

                    Ok I think the heart of my confusion has been thinking that the Gof
                    pattern was the general notion of a factory, As Scott said, "anything
                    that produces an instance" instead of what the Gof pattern is actually
                    stating. I think that clears up the confusion in my original question,
                    but now I'm little thrown off by various ideas in the replies.

                    > Contrast with factory pattern: not encapsulated within the class

                    ...because the new keyword isn't encapsulated within the class?

                    > (it's inverted from this sense) ....
                    I'm not sure what you mean by this.

                    > Ah, not really. You are ignoring intent. That's the equivalent of taking
                    > your Lexus and spray painting 'truck" on the doors then hauling wood
                    chips
                    > in it. You can do it but you ignore the intent of the car's design.

                    I now see that one issue with the example I provided is it doesn't
                    enforce the inversion of
                    control of the new operator. EnumSet example stated in the article
                    clarifies this for me.
                    Ok, out of curiousity what would be your statment of intent for the
                    static factory method?

                    >and not strongly identity coupled.
                    What's the difference between strongly identity coupled and identity coupled?

                    > Perhaps a better name than 'static factory' as Scott Bain uses will help.

                    Yeah.

                    > And there are important reasons to make instance encapsulators static,
                    having to do with 'closeness'
                    > to the class loader.

                    Would you elaborate?

                    --
                    Cheers,
                    Aeden


                    ______________________________________________________________________
                    This email has been scanned by the MessageLabs Email Security System.
                    For more information please visit http://www.messagelabs.com/email
                    ______________________________________________________________________

                  • Scott L. Bain
                    Well said! From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Max Guernsey, III Sent: Monday, July 21, 2008 12:50 PM
                    Message 9 of 9 , Jul 21, 2008
                    View Source
                    • 0 Attachment

                      Well said!

                       

                      From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Max Guernsey, III
                      Sent: Monday, July 21, 2008 12:50 PM
                      To: leanprogramming@yahoogroups.com
                      Subject: RE: [leanprogramming] Effective Java 2nd - Item 1 - The Factory Pattern?

                       

                      This is kind of askew the main line of the conversation, but I’ll say it anyway.

                       

                      Scott nailed one of the reasons why encapsulated constructors are so important right on the head: it’s not having to switch from the use of one constructor to another every where the constructor was used that kills you; a compiler will tell you when you are “done” with that.  It’s having to duplicate the logic deciding which type of object to use everywhere that can really hurt you.

                       

                      Let me throw another reason to do it out there.  Really this is just codifying the principle which underlies the consequences delineated below by Scott.  A class should never expose how something is done to its clients.  It should only provide them with an interface that they can use to indicate what they want done.  “new” is all about “how” in most languages for the very reason that Scott mentions below: there is no reasonable way to alter its behavior.  Not encapsulating a constructor is tantamount to making a field public rather than exposing access to it via getters and setters.

                       

                      Max Guernsey, III

                      Managing Member, Hexagon Software

                      http://www.hexsw.com

                      http://www.dataconstructor.com

                       

                      From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott L. Bain
                      Sent: Monday, July 21, 2008 12:21 PM
                      To: leanprogramming@yahoogroups.com
                      Subject: RE: [leanprogramming] Effective Java 2nd - Item 1 - The Factory Pattern?

                       

                      I’ll take a run at trying to clear up the point here… at least, in the way I look at it.

                       

                      In OO design, one thing we try to do is to avoid coupling to concrete types.  We know that we have to create coupling in systems, because the very nature of being “object-oriented” is that we break up solutions into cohesive objects, encapsulating each responsibility of the system into separate objects.  But we would like this coupling, as much as possible, to involve abstract types rather than concrete ones.  It’s an aspect of the GoF advice that says “design to interfaces”.

                       

                      Code like this:

                       

                      class client {

                      Service myService = new Service();

                                      myService.doStuff();

                      }

                       

                      …creates coupling to the concrete type Service within the class Client.  This is inherent whenever the keyword “new” is used in languages like Java and C#, because we are not permitted to override “new” to produce anything other than an instance of the literal class Service.

                       

                      If Service is later changed to an abstract class, this code breaks (and, if this is in many places, or used by other teams, this can be significant).  Even if Service stays concrete, but we wish (due to a changing requirement) to build a sub-type of Service, we’ll have to make lots of changes all over the place, and the logic to select the “right one” will be duplicated in all those places.

                       

                      Code like this:

                       

                      class client {

                      Service myService = Service.getInstance();

                                      myService.doStuff();

                      }

                       

                      …would seem to create concrete coupling, but does not.  Service.getInstance() does not have to return an actual instance of Service (even if it does now, this can easily be changed).  It can create anything that “qualifies” as Service.  It’s a method, so we control it, which makes it distinct from “new”.

                       

                      I call this an encapsulated constructor, Bloch is calling it a static factory.

                       

                      The Factory Method Pattern is really a complete different issue, with a different reason for being, and with different effects (look back at my example about collections for more on this).  There are many factory patterns, each of which does something different, and when you have the motivation to use them you’ve usually already solved this “concrete coupling’ problem.  I use the encapsulated constructor trick when I don’t have a justification to do something more complex.  It is an “at least” sort of practice, for me.

                       

                      Hope this helps !

                       

                      -Scott-

                       

                       

                      From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Aeden Jameson
                      Sent: Saturday, July 19, 2008 9:12 PM
                      To: leanprogramming@yahoogroups.com
                      Subject: Re: [leanprogramming] Effective Java 2nd - Item 1 - The Factory Pattern?

                       

                      Ok I think the heart of my confusion has been thinking that the Gof
                      pattern was the general notion of a factory, As Scott said, "anything
                      that produces an instance" instead of what the Gof pattern is actually
                      stating. I think that clears up the confusion in my original question,
                      but now I'm little thrown off by various ideas in the replies.

                      > Contrast with factory pattern: not encapsulated within the class

                      ...because the new keyword isn't encapsulated within the class?

                      > (it's inverted from this sense) ....
                      I'm not sure what you mean by this.

                      > Ah, not really. You are ignoring intent. That's the equivalent of taking
                      > your Lexus and spray painting 'truck" on the doors then hauling wood
                      chips
                      > in it. You can do it but you ignore the intent of the car's design.

                      I now see that one issue with the example I provided is it doesn't
                      enforce the inversion of
                      control of the new operator. EnumSet example stated in the article
                      clarifies this for me.
                      Ok, out of curiousity what would be your statment of intent for the
                      static factory method?

                      >and not strongly identity coupled.
                      What's the difference between strongly identity coupled and identity coupled?

                      > Perhaps a better name than 'static factory' as Scott Bain uses will help.

                      Yeah.

                      > And there are important reasons to make instance encapsulators static, having
                      to do with 'closeness'
                      > to the class loader.

                      Would you elaborate?

                      --
                      Cheers,
                      Aeden


                      ______________________________________________________________________
                      This email has been scanned by the MessageLabs Email Security System.
                      For more information please visit http://www.messagelabs.com/email
                      ______________________________________________________________________


                      ______________________________________________________________________
                      This email has been scanned by the MessageLabs Email Security System.
                      For more information please visit http://www.messagelabs.com/email
                      ______________________________________________________________________

                    Your message has been successfully submitted and would be delivered to recipients shortly.