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?
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.
@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?
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!
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.
Don't forget to mark solution providing post as "Answered".
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.
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.
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:
Member
34 Points
548 Posts
should a factory pattern always be implemented as a singleton?
Jul 26, 2014 03:15 PM|dotnetterAMG123|LINK
Star
9052 Points
2255 Posts
Re: should a factory pattern always be implemented as a singleton?
Jul 27, 2014 05:28 AM|Siva Krishna Macha|LINK
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.
Thanks & Regards,
Siva
Member
34 Points
548 Posts
Re: should a factory pattern always be implemented as a singleton?
Jul 27, 2014 01:17 PM|dotnetterAMG123|LINK
Member
42 Points
102 Posts
Re: should a factory pattern always be implemented as a singleton?
Jan 26, 2015 05:42 AM|Novice Kid|LINK
By your logic, it seems every class in the world should be a singleton!
Contributor
4030 Points
999 Posts
MVP
Re: should a factory pattern always be implemented as a singleton?
Jan 31, 2015 07:32 PM|DigiMortal|LINK
You are mixing here three different patterns:
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.
Also visit my ASP.NET blog or follow me @ Twitter:twitter.com/gpeipman
Member
40 Points
60 Posts
Re: should a factory pattern always be implemented as a singleton?
Feb 01, 2015 01:33 PM|Ringoo|LINK
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.
Member
440 Points
401 Posts
Re: should a factory pattern always be implemented as a singleton?
Feb 04, 2015 04:31 AM|jammycakes|LINK
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.
Member
70 Points
28 Posts
Re: should a factory pattern always be implemented as a singleton?
Feb 04, 2015 05:29 AM|Brutus Maximus|LINK
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