locked
factory pattern guidance RRS feed

  • Question

  • All,

     

    I'm a long time vb'er looking to learn more about applying patterns to my code. I'm starting small and could use a little advice/guidance. I've written a series of classes which implement the factory pattern (I think). While doing some research on the pattern I discovered a couple of different ways to implement it. I was hoping someone could validate my object model or suggest ways to improve upon it. My biggest question is, have I implemented the factory patterm correctly?

     

    Here's my model.

     

    Class MyFactory

     

    Public Shared Function CreateInstance(ByVal classType as MyType) as MyBaseClass

     

    Dim myClass As MyBaseClass

     

    Select Case classType

    Case TypeA

    myClass = new MyConcreteClassA

    Case TypeB

    myClass = new MyConcreteClassB

    End Select

     

    Return myClass

     

    End Function

     

    End Class

     

    MustInherit Class MyBaseClass

    MustOverride Function DoSomething() As Boolean

    End Class

     

    Class MyConcreteClassA

    Inherits MyBaseClass

     

    Function DoSomething() As Boolean

    Return True

    End Function

    End Class

     

    Class MyConcreteClassB

    Inherits MyBaseClass

     

    Function DoSomething() As Boolean

    Return False

    End Function

    End Class

     

    ' Calling code in the client application:

    Dim myClientClass As MyBaseClass = MyFactory.CreateInstance(MyType.TypeA)

     

    Any guidance you can provide is greatly appreciated.

     

    Thanks,

     

    Paul

     

     

    Thursday, August 7, 2008 3:47 AM

Answers

  • Your implementation looks fine. 

     

    My only point is that I would use interfaces instead of abstract classes.  Perhaps you got your example from a language that doesn't support interfaces?

     

    Thursday, August 7, 2008 8:02 AM
  • I agree with GMoore's comments.  Use Abstract class one and only if you think there is a common code that does not need to be written in each concrete implementation.

     

    Also, if you have time take a look at Inversion of Control/Dependency Injection.  Depending on how loosely you want to couple your dependency in the class library, an IoC/DI container like Unity, SpringFramework and Ninject can help you achieve that.
    Thursday, August 7, 2008 9:02 PM
  •  

    Hi,

     

    Here is my suggestion...

     

    First point -- interface is a better option if you want to share some common code, property for all derived classes. e.g dispose() pattern implementation....

     

    Second point -- the way you are implementing the factory is right but not a good approach. if you are using type as an input and basetype as output then there is no need to write the switch code..

     

    you can write all above in two lines...

     

    string typeName = "namespace.classname,assemblyname";

    Type type = Type.GetType("namespace.classname,assemblyname");

    object obj = Activator.CreateInstance(type) as BaseType;

     

    You can take above typeName value from config file.

     

     

    Hope this helps you...

     

     

    Friday, August 8, 2008 3:02 PM

All replies

  • Your implementation looks fine. 

     

    My only point is that I would use interfaces instead of abstract classes.  Perhaps you got your example from a language that doesn't support interfaces?

     

    Thursday, August 7, 2008 8:02 AM
  • I agree with GMoore's comments.  Use Abstract class one and only if you think there is a common code that does not need to be written in each concrete implementation.

     

    Also, if you have time take a look at Inversion of Control/Dependency Injection.  Depending on how loosely you want to couple your dependency in the class library, an IoC/DI container like Unity, SpringFramework and Ninject can help you achieve that.
    Thursday, August 7, 2008 9:02 PM
  •  

    Hi,

     

    Here is my suggestion...

     

    First point -- interface is a better option if you want to share some common code, property for all derived classes. e.g dispose() pattern implementation....

     

    Second point -- the way you are implementing the factory is right but not a good approach. if you are using type as an input and basetype as output then there is no need to write the switch code..

     

    you can write all above in two lines...

     

    string typeName = "namespace.classname,assemblyname";

    Type type = Type.GetType("namespace.classname,assemblyname");

    object obj = Activator.CreateInstance(type) as BaseType;

     

    You can take above typeName value from config file.

     

     

    Hope this helps you...

     

     

    Friday, August 8, 2008 3:02 PM
  • Bhavu, you  perfectly centered the problem: factory pattern is usefull if you have not to write code and use declarative approach instead.

    Tha fact of writing the type you are using inside a gonfig file permits to make dramatic changes on the line without any need to rebuild the project (never forget the patterns have been implemented to reduce the need of recompiling).

    Suppose for instance to migrate from one data source to another or worst to be on the pace to do that. I maybe have the need to switch from one DB system, server or so on to another. The chance to decide wich DataSource I use and the chance to do that outside the code is really nice feature.

    The factory pattern, with a declarative viriable writen outside the code, is the best solution you can have.

     

    ciao, Luca

    Sunday, January 4, 2009 11:18 AM
  • For a code example using the Factory pattern in C#, have a look at http://www.rmfusion.com/design_patterns/gof/factory_method_pattern.htm
    Friday, August 14, 2009 12:22 PM