I am working on a C# programming project in Visual Studio. I have created various VS library projects inside the VS solution containing the various components of the solution. Without giving it too much thought, I have put the factories for these components into their corresponding VS projects.

I have now needed to reuse one of these components inside another VS solution and realized that having the factory inside the components VS project may not be the correct way, since in the new project I have different requirements for the factory to construct the object (e.g. parameters, etc.). So this would suggest, that the factory should not form part of the components VS project.

On the other hand factories appear to be very closely bound to the components/objects they construct. For me this raises the question, where I should put them:

Should factories be part of the solution using the components library or should it be part of the library?

  • What do you mean by factory? Abstract factory? Builder? Or just a method that calls another class's constructor?
    – Euphoric
    Feb 8, 2016 at 8:29
  • @Euphoric Well I am still a little new to the whole concept as you probably can tell. By "factory" I mean a class that returns the an object of a given type depending on its input parameter. E.g. I currently have a class, where I can do MotorFactor.GetMotor("xmotor") and it returns the motor controller for the x-axis.
    – packoman
    Feb 8, 2016 at 8:33
  • So, the factories create same objects, but just initialize them differently? What is their point then? Wouldn't it be simpler just to initialize them in place where they are needed?
    – Euphoric
    Feb 8, 2016 at 8:37
  • @Euphoric Not sure I understand factories yet, so please correct if I am wrong: I thought one of the uses for factories is to hide the details of instantiating the objects they produce versus constructing the object in place. That was the reason I started using them. So that if in the future I have a different device with a different motor for the x-axis, the factory could provide the correct one. Or am I misunderstanding the whole point of factories?
    – packoman
    Feb 8, 2016 at 8:45
  • This might be my opinion, but I don't see the point of factories as you describe it. Either you want to ensure invariant in class and use a constructor, use abstract factory to delegate creation to some other part of program or builder to encapsulate complex creation rules. I don't see advantage of passing a string and having same object with just different configuration.
    – Euphoric
    Feb 8, 2016 at 8:56

1 Answer 1



It depends on how configurable and extendable you want to have the reusable library (project), without touching it.

In the end you either have factories in the library itself, or the library does not have them and the client (the user) of the library is responsible for creating them and instantiating the library himself.

Longer answer

No matter how object oriented your code is, a part of OO code will always have to be procedural. The part where the object graph is constructed, the newing of the classes.

When dealing with construction of classes belonging to another project (this will usually be some common library which contains code useful throughout more projects), you usually have two options how to expose the project to the outer world.

For this demostration purpose I chose the cache layer, which, from my experience, usually has very similar API throghout many different projects, only the configuration is different.

1. Creating a public endpoint of the library to expose it

If you were to follow this ideology, all the classes inside your cache library project would be set to internal except one class, perhaps a YourNamespace.Library.Cache class, which would be set to public, thus if you were to use the cache library, the only class you would have publicly access to is one single endpoint.

The YourNamespace.Library.Cache class constructor could look like this:

public class Cache : CachingInterface
    public Cache(string configuration)
        // this is where the magic happens

Not saying very much, is it? What exactly is the magic I am talking about?

Notice the configuration string as a parameter. It is a variable in which you define what you want to have, you insert your configuration, and this one public endpoint, the YourNamespace.Library.Cache class, will, in its constructor, parse this string, extract the data it needs from it, and based on the user input construct everything necessary.

Inside this constructor the Cache endpoint will instantiate the factories belonging to the cache project, it will the use those to instantiate the correct implementations.

In your main project, the code then could be as simple as this:

var cache = new YourNamespace.Library.Cache("type:redis,connection:[schema:tcp,host:localhost,port:3000,database:master],options:[replication:true]");

By parsing the string, the constructor will then see, you want to cache to redis, and provided the configuration, it will use the configuration and pass it onto the internal classes of the cache library, which know what to do with it.

Be aware the configuration does not need to be a string, you may use whatever you want.

The placement of the factories

When using this approach, the factories are inside the cache project. In fact, the one public endpoint, the Cache class, acts as a factory itself.

The project itself calls new on desired object based on the configuration string and after the construction of the endpoint, should it not throw an exception, you are set to use all the functionality of the library.

The good

  • the construction of a very complex library is simplified to one single endpoint, which only requires some configuration (be it a string, an array,...) described in documentation
  • you do not expose the internal parts of the library, so as long as you do not change the endpoint, you can optimize it, release new versions and the clients of this library need not to change anything in their code

The bad

  • if someone uses your library and wants to add his custom caching mechanism (perhaps a faster Redis driver or a completely new caching mechanism), he has to contact the owner of the library the add it
  • you need to create thorough documentation, so people know, how to use the endpoint and what configuration it offers

2. Exposing everything inside the library and letting the client of the library decide what he wants to construct

Using this approach, (almost) all classes inside the cache library will be set to public, all the interfaces, all the implementations, everything.

Besides the unit tests part of the cache library, there will probably be no usage of the new keyword inside the cache library. The library itself will not construct anything, it will only provide constructors and methods with predefined types of parameters, to let you know which exact class you will need if you want to instantiate a class.

The placement of the factories

Considering the cache library itself does not construct anything, the only place where you will have the factories is your main project, or the project of the client using the library.

The client himself will be responsible for constructing the object graph, by newing the dependencies, until he creates the final object representing the cache itself.

The good

  • the library is very easily extendable by the end user, would he want to use some custom implementation of a part of the library, he simply needs to adhere to the contract presented by the type of an object a class requires for its construction, perhaps by implementing an interface or extending a class
  • the creator of the library itself does not need to create a lot of documentation describing the construction, because by following the dependency injection principle, it is always pretty clear, which other classes you need in order to construct the class you desire
  • the client may very easily manipulate concrete implementations to make the library suitable for the project he is using it in

The bad

  • the construction in client code may become (really) ugly

You are likely to see something like this in the client code:

var depOne = new One();
var depTwo = new Two(depOne);
var depThree = new Three(depTwo);
var depFour = new Four(depThree);
// ...
var depTwentySeven = new TwentySeven(depTwentySix);
var cache = new Cache(depTwentySeven);

This is an extreme example, the amount of dependencies would probably vary, based on the type of cache you would like to construct, but it can happen.

  • because the client is responsible for creating all the dependencies, some of them may use the first pattern I am describing in this example for construction, meaning the client of the cache library is forced to check the documentation of the third party library to know how he is supposed to construct the dependency for the cache library.


Before diving in, you should decide, what it is you want.

If you want to encapsulate the library and want to have it its own environment and hide its complexity behind a simple abstraction layer, I would say go with a variation the first approach.

I would also use the first approach when I wanted to reflect all the internal changes in the library in all the projects where the library is used.

If you want the library to be easily extendable and you are likely to provide custom implementations, go with approach number two, where the library is not responsible for the construction, but gives clues on how the construction should happen.

But be aware, that change in the library will most likely need more change in the client code.

There is also always the third approach, which is a result of combining the first and second together, where then there are factories in both the library itself and also the client code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.