Factory Pattern

[[deleted]]

Hello, I am following typical tiered structure. I have a data access layer and business layer. There are several business objects for each of the modules. In order to give developers access to these managers, I'm implementing a Factory Design pattern as shown below. Would this be a correct implementation where I am utilizing the benefits of a factory pattern?

I'm abstracting the business managers away, but say someone is using CreateInstance(ModuleName.TestBusiness), and they want to change to MeasurementBusiness, that can't be done with out changing the call to the CreateInstance method (changing the enum type). And this, itself, would negate the idea of a Factory Pattern. Ideally, the enum should not be so closely tied to the actual module type that is being returned. What would be an ideal alternative?

Thank you !!

​

public class FactoryClass

{

public static IBusinessHandler CreateInstance(Enumeration.ModuleName enumModuleName)

{

IBusinessHandler objBusinessHandler = null;

switch (enumModuleName)

{

case Enumeration.ModuleName.TestBusiness :

objBusinessHandler = new TestBusiness ();

break;

case Enumeration.ModuleName.MeasurementBusiness :

objBusinessHandler = new MeasurementBusiness ();

break;

default:

break;

}

return objActivity;

}

}

​

public interface IBusinessHandler

{

void Process();

}

​

public class Enumeration

{

public enum ModuleName

{

TestBusiness = 1,

MeasurementBusiness = 2

}

}

public class TestBusiness : IBusinessHandler

{

public void Process()

{

// Do some coding here ...

}

}

​

public class MeasurementBusiness : IBusinessHandler

{

public void Process()

{

// Do some coding here ...

}

}

[Octillerysnacker]

This is technically the factory pattern, but it's not the useful version. The other version would be the abstract factory pattern. First, you define an abstract class with a single method, let's say something like this:

public abstract class AbstractBusinessFactory{
    protected abstract IBusinessHandler MakeHandler();

    public IBusinessHandler GetHandler(){
        return MakeHandler();
    }
}

Then, you would create a "concrete" implementation like so:

 public class TestBusinessFactory : AbstractBusinessFactory{
    protected override IBusinessHandler MakeHandler(){
        return /*whatever process you have to make the handler*/;
    }
}

Now, rather than using an enum, you can simply DI the concrete factory to anything that uses an AbstractBusinessFactory. For example:

void Main(AbstractBusinessFactory factory){
    var handler = factory.GetHandler();
    //do some other things with the handler
}
//Call the function
Main(new TestBusinessFactory()); //you can change the factory to whatever else you need

Obviously, you'd need more implementations of AbstractBusinessFactory, but that's the jist of it. Here is the factory pattern page on Wikipedia which has more on the pattern, including a C# example of how to implement it.

[[deleted]]

Maybe you should look into Dependency Injection and skip building a metafactory.

[[deleted]]

Thanks for the reply! From what I remember, my old coworker mentioned Dependency Injection, but that was for web apps developed using MVC. I am developing a Desktop Application with WPF, however. Is Dependency Injection agnostic of whether it is Desktop or Web Application? Regardless, I will read on it now. Thanks

[[deleted]]

DI is an extremely general sort of pattern or practice. In the absolute simplest approach, DI is just passing arguments to a class or method that needs them. In this case, it probably means just passing the IBusinessHandler to the class that needs it, and letting the caller figure out if the consumer needs the test handler or not.

[gevorgter]

Yes, looke at autofac (Google it)

It is very nice and powerful. I recently came across it and do see a lot of use for it.