I'm working on an application with many inheritance hierarchies that are not directly related.
Do I have to assign a factory method for each hierarchy in the client code to select a certain class from each hierarchy to instantiate upon the user selection through the GUI?
Instead if a concret Factory you may take a look at the Abstract Factory
Abstract Factory offers the interface for creating a family of related objects, without explicitly specifying their classes.
Reference
If objects are not related, I think you can't avoid having a factory for each object. Take a look at the Dependency Injection architecture , it could be an interesting option Dependency Injection vs Factory Pattern
Have a look at this webpage, which demonstrates using the Abstract Factory pattern with multiple inheritance hierarchies: http://www.dofactory.com/Patterns/PatternAbstract.aspx.
Related
Apparently, singletons are bad, and a factory method is recommended. I'm wondering if a singleton toolbox is any better than a singleton.
In my opinion, It's really weak to think that singletons are bad,factory methods are good.
Each of them has preferences. As consequence, I'm sure that there is misunderstanding here.
I know that wikipedia is not the best source. But check out the definition of them. The range of situations are not the same for these patterns.
In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.
In class-based programming, the factory method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created. This is done by creating objects via calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.
The intent of the Abstract Factory design pattern is to
"Define an interface for creating families of related or dependent objects
without specifying their concrete classes." [GoF]
This is a short statement of what the design pattern does (solution),
but it isn't clear what particular design problems it solves.
I would define the
following design, refactoring, and test problems,
but I am not sure whether this list is complete.
Design Problems
Creating Objects and Object Families
How can a system support creating different families of objects
so that which family to create can be selected and changed dynamically?
How can a system be configured with a family of objects?
And how can the whole family of objects be exchanged dynamically?
How can the way objects are created (which classes are instantiated)
be changed independently?
How can a system be independent of how its objects are created?
Creating Consistent Object Families
How can be ensured that a system creates objects from only one of different
families at a time?
Refactoring Problems
Distributed Creation Code
How can instantiating concrete classes throughout an application be refactored?
How can creation code that is distributed across many classes be centralized?
Testing Problems
Unit Tests
How can creating objects and object families be designd
so that object creation can be mocked easily for unit testing?
Keeping the long story short - if in the future a new group of objects is introduced in your current OO design, a new factory will be derived from AbstractFactory, encapsulating creation of all concrete objects related to that group. It’s that simple.
As addition is also important to say that
“This pattern defines an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses".
In short we need a class here which will do all the common tasks and expose a virtual or abstract function.
So creating AbstractFactory will encapsulate common functionalities with an additional overridable (virtual or abstract) method and then recreate our SubFactoryA and SubFactoryB. By doing so - you'll achieve common architecture, propagate minimum/default set of practices, standards etc. Here is a very good article about all this.
I have an object that I would like to create. This object is composed of other objects that I don't want the client class to be responsible for creating. There are lots of validation rules that must pass before the object can be created.
So I would like to abstract away the creation of this complex object into a "factory" class. I have 2 questions really, the first is purely about semantics:-
What should I call the class which is creating my object? The factory method pattern and abstract factory pattern are both related to abstracting away creation of concrete classes of different types. However, I'm creating an object of a single type, so using the term factory might be confusing?
Is this an appropriate solution? Are there any patterns/examples of this being done?
Thanks in advance for any help/guidance.
You can use the term factory because we all use it in its broadest sense unless we use a more unique name like Factory Method design pattern or Abstract Factory design pattern.
Builder pattern is typically used if you have an object build process that should still be used if the same master steps should be used in creating different types of objects. But in your case you just have one type. So there's no need for a better solution since there's no special problem to solve. Just do the validation in the simplest form you can.
Hi there I hope I am able to explain myself clear enough with this problem I have been really confused about.
I have a concrete class called UTModule, it is not subclassed at all, but it is composed of several different abstract objects (for example UTListener, UTRenderer, UTDeliverer) the instantiation of these abstract classes to concrete objects defines the behaviour of my completed UTModule object.
The question I am asking is that, every example I see for the factory design pattern is in regards to an abstract object that is subclassed, whereas my object is a concrete class who's behaviour is decided by its composition.
Am I supposed to create a factory for each of my composite abstract objects? Or just create one factory that creates my UTModule, with the correct composite objects depending on the clients request?
Thanks in advance!
I feel like using the Abstract factory pattern is a clear solution for you.
Lets take UTModule as a abstract factory class which has methods to create a Factory of the Other Objects like "UTListener, UTRenderer, UTDeliverer"
Some additional interface is required for each UTListener, UTRenderer, UTDeliverer and respective factory class for each family.
UTModule add all require method to return the factory of the family you are looking.
For More details and example please follow OODesgin
I'm trying to succinctly describe when to use a factory, for both myself and my team. I ran across the following related questions, which helped somewhat:
When to use factory patterns?
(useful pdf link is broken)
How do you create your Factories?
(more 'how' rather than 'when')
What is your threshold to use factory instead of a constructor to create an object?
(some general answers)
Factory Pattern. When to use factory methods?
(more about factory methods than factory classes)
When to use Factory method pattern?
(again more about factory methods)
Based on these links, and a bunch of other sources (listed at the bottom), I've come up with the following:
When to use the abstract factory pattern:
when you use an interface var or the 'new' operator
e.g. User user = new ConcreteUserImpl();
and the code you are writing should be testable / extensible at some point
Explanation:
interfaces by their very nature imply multiple implementations (good for unit testing)
interface vars imply OCP- and LSP-compliant code (support sub-classing)
use of the 'new' operator breaks OCP/DI, because highly-coupled classes are hard to test or change
"Do I create a factory for every object type? That seems excessive."
no, you can have one (or a few) factories that produce a lot of (usually related) object types
e.g. appFactory.createUser(); appFactory.createCatalog(); etc.
When NOT to use a factory:
the new object is very simple and unlikely to be sub-classed
e.g. List list = new ArrayList();
the new object is not interesting to test
has no dependencies
performs no relevant or long-running work
e.g. Logger log = new SimpleLogger();
References:
http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html
http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
http://en.wikipedia.org/wiki/Dependency_Injection
http://en.wikipedia.org/wiki/Open_Closed_Principle
http://en.wikipedia.org/wiki/Liskov_substitution_principle
My question is: is my summary accurate, and does it make sense? Is there anything I've overlooked?
Thanks in advance.
I'd also say don't use a factory when you have a particular implementation that you want. To continue the List example, I know that I want an ArrayList because I'm doing random access. I don't want to rely on a factory getting this right when I can do it myself.
Conversely, when I don't want to know about the concrete subclass then I can use a factory and let it worry about which object to actually instantiate.
I guess I'd suggest that you add a bullet to the "when to use the abstract factory pattern" that says "and you don't really care which concrete subclass you get", and the converse to "when not to use a factory".
EDIT: Be careful to avoid the general-purpose tool-building factory factory factory.
In general, use it when you want to be able to switch of implementation by external configuration.
JDBC and JAXP are excellent examples. For more examples, check this answer.
Abstract Factory pattern provides with a way to encapsulate concrete factories that share some commonality with each other, meaning they implement same interface/abstract class.
You need to use factory pattern whenever you want to control the initialization of your objects, instead of giving the control to the consumer.