locked
should a factory pattern always be implemented as a singleton? RRS feed

  • Question

  • User1610691276 posted
    Hello, should a factory pattern always be implemented as a singleton? Are there any scenarios where a factory pattern should *not* be implemented as a singleton?
    Saturday, July 26, 2014 3:15 PM

All replies

  • User-484054684 posted

    They both are different design patterns. Factory pattern delegates the responsibility of creating the instances (objects) to the factory classes. But, singleton pattern ensures the creation of an object should be done only once per application instance. The point here is, not all the classes need one instance per application. Factory classes are responsible to create any instance - the instances' life time could be through out application or local to a method.

    Sunday, July 27, 2014 5:28 AM
  • User1610691276 posted
    @siva - I think the point here is that there's no reason why there should be more than 1 instance of a factory across all app instances. Or can you think of a reason why there should be?
    Sunday, July 27, 2014 1:17 PM
  • User-545631939 posted

    I think the point here is that there's no reason why there should be more than 1 instance of a factory across all app instances. Or can you think of a reason why there should be?

    By your logic, it seems every class in the world should be a singleton!

    Monday, January 26, 2015 5:42 AM
  • User-525215917 posted

    You are mixing here three different patterns:

    1. Singleton
    2. Factory
    3. Static factory

    Static factory is usually mix of Singleton and Factory. 

    I think static factory is okay in most cases and that's why it is popular. But it doesn't mean that it is always correct choice. In more complex systems you may need multiple factories for same class. By example, if your system reads products information from two different systems it may need two different factories because those external services or data sources may give you product data with different structure.

    Saturday, January 31, 2015 7:32 PM
  • User-1067017023 posted

    Hello, should a factory pattern always be implemented as a singleton? Are there any scenarios where a factory pattern should *not* be implemented as a singleton?

    If you're merely doing a project for timepass, go ahead, implement your factory as a singleton. But if you are doing a serious, enterprise project, then you need to do some serious abstraction. In the later case, implement your factory as a singleton if and only if a single instance of your factory is justified by your problem domain.

    Sunday, February 1, 2015 1:33 PM
  • User-1611549905 posted

    But if you are doing a serious, enterprise project, then you need to do some serious abstraction.

    Be careful here. Don't fall into the enterprisey trap of abstraction for abstraction's sake. Abstraction adds complexity and friction, and therefore additional risk. It should only be added when it solves a specific business requirement. The usual driver for abstraction in enterprise applications is testability: making it possible to swap components for mocks and stubs in your unit tests.

    Now coming back to the factory and singleton patterns. Both of these are patterns that should be approached with a certain amount of caution. Singletons introduce two problems in particular to your code: multithreading issues such as race conditions or deadlocks; and poor testability, as they can add a hard dependency on your singleton instance into your code which can't be mocked. Factory patterns tend to suffer from over-use: if you ever find yourself implementing a factory factory (and bear in mind that factories can hide behind names such as "provider" or "manager" or "service" or what have you), it's a warning sign that you're over-complicating things.

    A factory implemented as a singleton is actually an example of the Service Locator pattern. This is a role which is usually served by your IOC container, of which there should normally be only one instance in your project, invoked only at the topmost level of your code to create all your dependent services.

    Wednesday, February 4, 2015 4:31 AM
  • User784151913 posted

    jammycakes

    Be careful here. Don't fall into the enterprisey trap of abstraction for abstraction's sake.

    I agree with you on that. Overload of anything, just for its own sake, can be harmful. But what I have observed many a times is no abstraction at all! And that in my opinion, is much worse than abstraction overload. There are a lot of cases where I have seen behavioral concerns attempted to be solved using creational patterns, endless switch - cases (sometimes nested within switch - cases!), List<object> types, and lots of other ugly stuff. Let alone abstraction, if only people had applied a little thought, how nice things would have been! :)

    I also agree with you on the other points you mentioned regarding singletons. They tend to increase the level of global state in a program, and as a result put testability in peril. Mutable global state especially is a bad thing. I would refer the interested reader to the following excellent article on the use of singletons:

    http://www.ibm.com/developerworks/library/co-single/

    .Brutus

    Wednesday, February 4, 2015 5:29 AM