Who doesn't love a good Factory pattern?



  • Among some perfectly legitimate factory methods, I found this pattern repeated quite frequently:

    public class SuperDuperClassFactory
    {
      ...
    

    public static IThing CreateThing()
    {
    return (IThing)new Thing();
    }

    ...
    }

    Now, instead of having to write code like "new Thing();" I can use the convenient factory method "SuperDuperClassFactory.CreateThing();" instead! It's also worth mentioning that the interface IThing is [i]only[/i] implemented by the class Thing, and it has been that way for years.



  • This looks like a Simple Factory (which is not a pattern) as opposed to the Factory Method (pattern) and the Abstract Factory (pattern)



  • Thats not a WTF...

     It allows for better unit testing. You can create a mock (or write a stub yourself) of IThing from the Interface and test some other class or method that wants to do something with iThing.



  • I am not getting it, in that case. I mean, the interface defines 9 properties and 3 methods that you would have to implement to make a "mock" implementation, when there is already one implemented in this case. There's no unit testing going on, anyway. It just seems like over-indulgence in patterns to me. And, also, nearly every factory method I've ever seen always operates on some arguments passed to it..



  • @bobday said:

    This looks like a Simple Factory (which is not a pattern) as opposed to the Factory Method (pattern) and the Abstract Factory (pattern)

    This must be some strange new use of the word "pattern" with which I was not previously familiar. 



  • Factory object
    Factory method pattern
    Abstract factory pattern
     

    Head First Design Patterns by Freeman & Freeman also has the same/similar definition, whereby creating a Class/Object that creates other Objects is a programming idiom, rather than a pattern.

     

    Also GoF seem to know what they are talking about



  • From the definition at http://en.wikipedia.org/wiki/Factory_object:

    Factory objects are used in situations where getting hold of an object of a particular kind is a more complex process than simply creating a new object. The factory object might decide the created object's class (if applicable) dynamically, return it from an object pool, do complex configuration on the object, or other things.

    In this case, the code posted [i]does not[/i] satisfy any of those criteria. So what is it?



  • It obviously is a factory object, it's just being used for no sensible reason.

    I think the person who said that they just liked factories was spot on.
     



  • @djork said:

    I am not getting it, in that case. I mean, the interface defines 9 properties and 3 methods that you would have to implement to make a "mock" implementation, when there is already one implemented in this case. There's no unit testing going on, anyway. It just seems like over-indulgence in patterns to me. And, also, nearly every factory method I've ever seen always operates on some arguments passed to it..

    Maybe it was used in far away past before the actual Thing implementation was there and then simply left in place?



  • I could almost understand it if i make one assumption (the Thing class is public) and they changed one word... (in bold)

    @djork said:

    public class SuperDuperClassFactory
    {
      ...
    

    internal static IThing CreateThing()
    {
    return (IThing)new Thing();
    }

    ...
    }



  • Did you mean "Thing class is internal and CreateThing method is public"? So users of the library get only restricted access to Thing.

    public class SuperDuperClassFactory
    {
    ...

    public static IThing CreateThing()
    {
    return (IThing)new Thing();
    }

    ...
    }

    BTW: I hate ajax! It ate my contents of this textbox.



  • Well, of course, all of the classes and methods involved are public :)



  • No, I meant the class could be public with a private constructor.  The static "create thing" method would be internal. 

    This means that this class can only be created within the current assembly, but can be used and referenced by other assemblies.  If you make the class itself internal, then other assemblies can't even see it.

    Besides, you cannot have a public method return an internal type.  The type must be at least as accessible as the method itself.



  • Ah, it could be useful. I was thinking about something like this: - indeed other assemblies can't see Thing class, but they can access it through a small IThing interface.

    <FONT color=#0000ff>public</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>interface</FONT><FONT size=2> </FONT><FONT color=#2b91af size=2>IThing
    </FONT><FONT size=2>{
    </FONT><FONT color=#0000ff size=2>void</FONT><FONT size=2> GoodPublicMethod();
    }
    </FONT><FONT color=#0000ff size=2>internal</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>class</FONT><FONT size=2> </FONT><FONT color=#2b91af size=2>Thing</FONT><FONT size=2>:</FONT><FONT color=#2b91af size=2>IThing
    </FONT><FONT size=2>{
    </FONT><FONT color=#0000ff size=2>#region</FONT><FONT size=2> IThing Members
    </FONT><FONT color=#0000ff size=2>public</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>void</FONT><FONT size=2> GoodPublicMethod()
    {
    </FONT><FONT color=#0000ff size=2>throw</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>new</FONT><FONT size=2> </FONT><FONT color=#2b91af size=2>Exception</FONT><FONT size=2>(</FONT><FONT color=#a31515 size=2>"The method or operation is not implemented."</FONT><FONT size=2>);
    }
    </FONT><FONT color=#0000ff size=2>#endregion
    </FONT><FONT color=#0000ff size=2>public</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>void</FONT><FONT size=2> SomeOtherMethod()
    {
    </FONT><FONT color=#0000ff size=2>throw</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>new</FONT><FONT size=2> </FONT><FONT color=#2b91af size=2>Exception</FONT><FONT size=2>(</FONT><FONT color=#a31515 size=2>"The method or operation is not implemented."</FONT><FONT size=2>);
    }
    }
    </FONT><FONT color=#0000ff size=2>public</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>class</FONT><FONT size=2> </FONT><FONT color=#2b91af size=2>SuperDuperClassFactory
    </FONT><FONT size=2>{
    </FONT><FONT color=#0000ff size=2>public</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>static</FONT><FONT size=2> </FONT><FONT color=#2b91af size=2>IThing</FONT><FONT size=2> CreateThing()
    {
    </FONT><FONT color=#0000ff size=2>return</FONT><FONT size=2> (</FONT><FONT color=#2b91af size=2>IThing</FONT><FONT size=2>)</FONT><FONT color=#0000ff size=2>new</FONT><FONT size=2> </FONT><FONT color=#2b91af size=2>Thing</FONT><FONT size=2>();
    }
    }</FONT>



  • That would be useful. Unfortunately, in our system, IFoo defines [i]asbolutely everything[/i] that the class Foo does, even things that should be static methods of Foo, and nothing is ever added to Foo that isn't added to IFoo first. There is literally no difference. We've made it so that IFoo is basically "foo.h" where Foo is "foo.c" in our framework. :D

    That's not the only defectively old-school C-style idiosyncrasy in this C# code either.


Log in to reply