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

ClassFactories vs dependancy injection

Expand Messages
  • chrishand40
    Can someone explain when would I want to prefer one over the other? Thanks, -Chris
    Message 1 of 7 , Jan 25, 2010
    View Source
    • 0 Attachment
      Can someone explain when would I want to prefer one over the other?

      Thanks,
      -Chris
    • Scott Bain
      It s an interesting question, Chris. Thanks for posting it. There are some ways in which this is an either/or question (ways in which DI and factories relate)
      Message 2 of 7 , Jan 25, 2010
      View Source
      • 0 Attachment

        It’s an interesting question, Chris.  Thanks for posting it.

         

        There are some ways in which this is an either/or question (ways in which DI and factories relate) and some ways in which it is not (where they have different motivations).

         

        Some ways they relate… 

        1.       They both Separate the use of something from its creation, which I think is a good separation of concerns. 

        2.       They both also help encapsulate variation (if the object being injected/constructed varies, as is usually the case).

         

        Some ways they are more different… 

        1.       Factories help to encapsulate business rules in a single place.  If, for instance, you are building a decorator chain of various behaviors, then a factory can impose rules about what chains can be built and which cannot, or which should be built under what circumstances.  If a client object builds the chain to inject it into a service, and the service has more than one client, then the rules are spread out and often redundant.

        2.       DI, on the other hand, can be very useful in breaking dependencies for testing (it is easy to inject a mock directly if the dependency is already “inject-able”, for example).  If you let a factory “decide” to build a mock, then the factory can get coupled to testing issues.

         

        Of course, they can be used together as well.  A Client can use a factory to build a dependency, and then inject what the factory built into the Service.  A test could inject  a mock instead, ignoring the factory.  This can be overkill, of course, but if one needs the benefits of both, one can use them in this way.

         

        That’s my first bit of thinking, anyway.  Let’s see what others say.

         

        -Scott-

         

        From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
        Sent: Monday, January 25, 2010 9:44 AM
        To: leanprogramming@yahoogroups.com
        Subject: [leanprogramming] ClassFactories vs dependancy injection

         

         

        Can someone explain when would I want to prefer one over the other?

        Thanks,
        -Chris

      • Christopher Sage
        It would also depend upon what your goal is. Is there anything in particular you re trying to solve, or is this just a general question? -Chris ... It would
        Message 3 of 7 , Jan 25, 2010
        View Source
        • 0 Attachment
          It would also depend upon what your goal is.  Is there anything in particular you're trying to solve, or is this just a general question?

          -Chris

          On Mon, Jan 25, 2010 at 12:14 PM, Scott Bain <slbain@...> wrote:
           

          It’s an interesting question, Chris.  Thanks for posting it.

           

          There are some ways in which this is an either/or question (ways in which DI and factories relate) and some ways in which it is not (where they have different motivations).

           

          Some ways they relate… 

          1.       They both Separate the use of something from its creation, which I think is a good separation of concerns. 

          2.       They both also help encapsulate variation (if the object being injected/constructed varies, as is usually the case).

           

          Some ways they are more different… 

          1.       Factories help to encapsulate business rules in a single place.  If, for instance, you are building a decorator chain of various behaviors, then a factory can impose rules about what chains can be built and which cannot, or which should be built under what circumstances.  If a client object builds the chain to inject it into a service, and the service has more than one client, then the rules are spread out and often redundant.

          2.       DI, on the other hand, can be very useful in breaking dependencies for testing (it is easy to inject a mock directly if the dependency is already “inject-able”, for example).  If you let a factory “decide” to build a mock, then the factory can get coupled to testing issues.

           

          Of course, they can be used together as well.  A Client can use a factory to build a dependency, and then inject what the factory built into the Service.  A test could inject  a mock instead, ignoring the factory.  This can be overkill, of course, but if one needs the benefits of both, one can use them in this way.

           

          That’s my first bit of thinking, anyway.  Let’s see what others say.

           

          -Scott-

           

          From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
          Sent: Monday, January 25, 2010 9:44 AM
          To: leanprogramming@yahoogroups.com
          Subject: [leanprogramming] ClassFactories vs dependancy injection

           

           

          Can someone explain when would I want to prefer one over the other?

          Thanks,
          -Chris


        • Allan Schougaard
          Why one or the other? DI essentially just says (one interpretation) that the agency in charge of creating objects and tying them together should not be the
          Message 4 of 7 , Jan 25, 2010
          View Source
          • 0 Attachment
            Why one or the other?

            DI essentially just says (one interpretation) that the agency in charge of creating objects and tying them together should not be the (base/domain/business/bean) objects themselves.
            Factories can be seen as just accessors and modifiers (getters and setters) on object in the process of being created.

            In fact, just the other day I used a static factory for to create objects for Spring (java) to inject (because I needed an parameter of type Class<T> which Spring has a little trouble with).

            Thanks,
            --Allan

            --- On Mon, 1/25/10, chrishand40 <cj.hand@...> wrote:

            > From: chrishand40 <cj.hand@...>
            > Subject: [leanprogramming] ClassFactories vs dependancy injection
            > To: leanprogramming@yahoogroups.com
            > Date: Monday, January 25, 2010, 9:44 AM
            > Can someone explain when would I want
            > to prefer one over the other?
            >
            > Thanks,
            > -Chris
          • Max Guernsey, III
            I m fairly certain that Scott summed up the issues nicely. I ll admit, I don t know what the term ClassFactories means and could interpret it one of two
            Message 5 of 7 , Jan 25, 2010
            View Source
            • 0 Attachment

              I’m fairly certain that Scott summed up the issues nicely.  I’ll admit, I don’t know what the term “ClassFactories” means and could interpret it one of two ways…

               

              Way #1:

              public class ToBeBuilt {

               private ToBeBuilt() { }

               

               // this is my class factory

               public static ToBeBuilt GetInstance() {

               }

              }

               

              Way #2:

              public class ToBeBuilt {

              }

               

              // this is my class factory:

              public class BuildsObjects {

               public ToBeBuilt MakeRequestedObject() {

               }

              }

               

              Practically speaking (for myself only), I’m fairly inflexible in this area when it comes to code I am writing.  Thanks to Scott, I always do Way #1.  I do this on principle: Construction is simple too intimate a detail for a class to expose.

               

              I vary between Way #2 and dependency injection based on whether or not procurement of a new object is a behavior of the client I am writing and whether or not the client object uses the dependent object.  I do this according to the following rules:

               

              When the client…

              ·         …uses but does not procure: Pass object in at the time when variation should occur

              ·         …uses and procures: Pass in some kind of provider (a Builder, an Abstract Factory, etc.) when the variation should occur

              ·         …procures but does not use: Directly invoke the GetInstance() of the right object at the right time

              ·         …procures and does not use but the above approach would be difficult to test: Reevaluate design; fall back on passing in some kind of provider

              ·         …doesn’t procure and does not use: Um.  Hmm.  Is this really a dependency or is it just idle coupling?

              Note that “use” includes using an object as the input for the creation of another object.

               

              Anyway.  I’m not sure if this is directly related to your question or just tangentially related but that’s never stopped me before.

               

              -- Max

               

              From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott Bain
              Sent: Monday, January 25, 2010 10:15 AM
              To: leanprogramming@yahoogroups.com
              Subject: RE: [leanprogramming] ClassFactories vs dependancy injection

               

               

              It’s an interesting question, Chris.  Thanks for posting it.

               

              There are some ways in which this is an either/or question (ways in which DI and factories relate) and some ways in which it is not (where they have different motivations).

               

              Some ways they relate… 

              1.       They both Separate the use of something from its creation, which I think is a good separation of concerns. 

              2.       They both also help encapsulate variation (if the object being injected/constructed varies, as is usually the case).

               

              Some ways they are more different… 

              1.       Factories help to encapsulate business rules in a single place.  If, for instance, you are building a decorator chain of various behaviors, then a factory can impose rules about what chains can be built and which cannot, or which should be built under what circumstances.  If a client object builds the chain to inject it into a service, and the service has more than one client, then the rules are spread out and often redundant.

              2.       DI, on the other hand, can be very useful in breaking dependencies for testing (it is easy to inject a mock directly if the dependency is already “inject-able”, for example).  If you let a factory “decide” to build a mock, then the factory can get coupled to testing issues.

               

              Of course, they can be used together as well.  A Client can use a factory to build a dependency, and then inject what the factory built into the Service.  A test could inject  a mock instead, ignoring the factory.  This can be overkill, of course, but if one needs the benefits of both, one can use them in this way.

               

              That’s my first bit of thinking, anyway.  Let’s see what others say.

               

              -Scott-

               

              From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
              Sent: Monday, January 25, 2010 9:44 AM
              To: leanprogramming@yahoogroups.com
              Subject: [leanprogramming] ClassFactories vs dependancy injection

               

               

              Can someone explain when would I want to prefer one over the other?

              Thanks,
              -Chris

              No virus found in this incoming message.
              Checked by AVG - www.avg.com
              Version: 8.5.432 / Virus Database: 271.1.1/2643 - Release Date: 01/25/10 07:36:00

            • chrishand40
              It is a general question. I was reading around on the issue, and there is a strong push to favor DI over class factories. The thing that concerned me is the
              Message 6 of 7 , Feb 1, 2010
              View Source
              • 0 Attachment
                It is a general question.

                I was reading around on the issue, and there is a strong push to favor DI over class factories. The thing that concerned me is the religiousness of it, as if DI where the higher evolved form of coding. Two reasons that I thought were interesting are: 1) class factories violate the open / close principal, and 2) Heavy use of class factories results in a lot of class factories in your project. Given how they are used, I'm not sure I care about #1, and at least in the size of the projects I am doing, #2 hasn't been an issue.

                As I learned more, I realized I didn't really phrase the question well. While I have found dependency injection to be very useful when properly applied, my larger concern is with the large and complex dependency injection frameworks. So far I've only worked on one project that used a framework and while I could see some advantages - it wasn't done very well (IMO). There was still a lot of coupling in that if I wanted to change the source of data to be anything other than a database it would involve a significant effort. It also added a learning curve just trying to understand what instances of which object would be created when.

                So far, the answer I have gathered from the group is that it isn't an either/or answer – they are different tools for different situations.

                I'm going to post my question about DI frameworks on a separate thread.


                --- In leanprogramming@yahoogroups.com, Christopher Sage <bigbuffwolf@...> wrote:
                >
                > It would also depend upon what your goal is. Is there anything in
                > particular you're trying to solve, or is this just a general question?
                >
                > -Chris
                >
                > On Mon, Jan 25, 2010 at 12:14 PM, Scott Bain <slbain@...>wrote:
                >
                > >
                > >
                > > It's an interesting question, Chris. Thanks for posting it.
                > >
                > >
                > >
                > > There are some ways in which this is an either/or question (ways in which
                > > DI and factories relate) and some ways in which it is not (where they have
                > > different motivations).
                > >
                > >
                > >
                > > Some ways they relate…
                > >
                > > 1. They both Separate the use of something from its creation, which
                > > I think is a good separation of concerns.
                > >
                > > 2. They both also help encapsulate variation (if the object being
                > > injected/constructed varies, as is usually the case).
                > >
                > >
                > >
                > > Some ways they are more different…
                > >
                > > 1. Factories help to encapsulate business rules in a single place.
                > > If, for instance, you are building a decorator chain of various behaviors,
                > > then a factory can impose rules about what chains can be built and which
                > > cannot, or which should be built under what circumstances. If a client
                > > object builds the chain to inject it into a service, and the service has
                > > more than one client, then the rules are spread out and often redundant.
                > >
                > > 2. DI, on the other hand, can be very useful in breaking
                > > dependencies for testing (it is easy to inject a mock directly if the
                > > dependency is already "inject-able", for example). If you let a factory
                > > "decide" to build a mock, then the factory can get coupled to testing
                > > issues.
                > >
                > >
                > >
                > > Of course, they can be used together as well. A Client can use a factory
                > > to build a dependency, and then inject what the factory built into the
                > > Service. A test could inject a mock instead, ignoring the factory. This
                > > can be overkill, of course, but if one needs the benefits of both, one can
                > > use them in this way.
                > >
                > >
                > >
                > > That's my first bit of thinking, anyway. Let's see what others say.
                > >
                > >
                > >
                > > -Scott-
                > >
                > >
                > >
                > > *From:* leanprogramming@yahoogroups.com [mailto:
                > > leanprogramming@yahoogroups.com] *On Behalf Of *chrishand40
                > > *Sent:* Monday, January 25, 2010 9:44 AM
                > > *To:* leanprogramming@yahoogroups.com
                > > *Subject:* [leanprogramming] ClassFactories vs dependancy injection
                > >
                > >
                > >
                > >
                > >
                > > Can someone explain when would I want to prefer one over the other?
                > >
                > > Thanks,
                > > -Chris
                > >
                > >
                > >
                >
              • Kim Gräsman
                Hello, ... I don t have a clear opinion either way, but I read this the other day, and it seems to touch on a couple of your concerns:
                Message 7 of 7 , Feb 1, 2010
                View Source
                • 0 Attachment
                  Hello,

                  On Mon, Feb 1, 2010 at 09:20, chrishand40 <cj.hand@...> wrote:
                  >
                  > It is a general question.
                  >
                  > I was reading around on the issue, and there is a strong push to favor DI over class factories.  The thing that concerned me is the religiousness of it, as if DI where the higher evolved form of coding.   Two reasons that I thought were interesting are: 1) class factories violate the open / close principal, and 2) Heavy use of class factories results in a lot of class factories in your project.  Given how they are used, I'm not sure I care about #1, and at least in the size of the projects I am doing, #2 hasn't been an issue.
                  >
                  > As I learned more, I realized I didn't really phrase the question well.  While I have found dependency injection to be very useful when properly applied, my larger concern is with the large and complex dependency injection frameworks.  So far I've only worked on one project that used a framework and while I could see some advantages - it wasn't done very well (IMO).  There was still a lot of coupling in that if I wanted to change the source of data to be anything other than a database it would involve a significant effort.  It also added a learning curve just trying to understand what instances of which object would be created when.
                  >
                  > So far, the answer I have gathered from the group is that it isn't an either/or answer – they are different tools for different situations.

                  I don't have a clear opinion either way, but I read this the other
                  day, and it seems to touch on a couple of your concerns:
                  http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

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