Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
From the "Gang of Four" design patterns, there's the Factory method:
class Factory(product)
case product
when a
new A
when b
new B
when c
new C
end
new Factory(a)
Why is this more useful than having three classes, a, b, and c and calling them individually?
Because your example is not complicated enough. For such a simple scenario it doesn't even make sense to use an advanced pattern.
But if you have to know more than the product to construct A, B or C, and you can't have direct access to that knowledge, then it is useful. Then you are using the factory to act as a knowledge center for producing needed objects.
Maybe those objects need a reference to some object X, which the factory can provide, but your code in the place where you want to construct A, B or C can't or shouldn't have access to X. Maybe when you have X you create A and B but if you have Y type then you create C.
Also consider that some objects might need 20 dependencies to create; what then? Going to hunt for those dependencies in a place where they should not be accessible might be problematic.
The Factory Method pattern abstracts the decision-making process from the calling class. This has several advantages:
Reuse. If I want to instantiate in many places, I don't have to repeat my condition, so when I come to add a new class, I don't run the risk of missing one.
Unit-Testability. I can write 3 tests for the factory, to make sure it returns the correct types on the correct conditions, then my calling class only needs to be tested to see if it calls the factory and then the required methods on the returned class. It needs to know nothing about the implementation of the factory itself or the concrete classes.
Extensibility. When someone decides we need to add a new class D to this factory, none of the calling code, neither unit tests or implementation, ever needs to be told. We simply create a new class D and extend our factory method. This is the very definition of Open-Closed Principle.
You can even create a new factory class and make them hot-swappable, if the situation requires it -- for example, if you want to be able to switch class D on and off, while testing. I have run into this situation only once, but it was extremely useful.
As has been said, the Factory Pattern isn't always the way to go. But, wherever you see conditional instantiation, you should give it a moment's thought.
A factory pattern is usually more complex than that. A factory decides on certain criteria which instance to create/return. Instead, when you don't use the factory, you would have that code repeatedly used in several locations in your code.
As an example consider the following: you need to load data from a DB, but you have one central DB for integration with lots of data, and one smaller one in memory on each dev-PC. In your code you ask a factory to get a DB-handle and the factory returns one of those depending on e.g. a configuration file.
The key advantages of the Factory pattern are twofold:
The places that need an implementation of the product do not need to know how to construct one. The factory holds that information.
Do you want to know what arguments to pass to the particular constructor? Or what dependencies you have to inject? Or how to register the implementation class with the database after it is fully configured? No? Let the factory look after all that stuff.
The places that need an implementation of the product do not need to know at the time of module description (i.e., at compilation time) what the name of the implementation class is.
Thus, a need not have anything to do with A; the “what to build” can be described in terms of the desired non-functional properties, and not just the name. This is much more flexible.
The downside is that where you know what to make and how to do it, you get more complexity when you use a factory. The fix to that is simple though: don't use a factory when it doesn't make sense!
The Factory pattern is the most overused and abused design pattern.
I have come across numerous cases where a Factory class is coded when a simple constructor would be adequate.
Dont use a factory class unless:-
I would like to think about design patterns in terms of classes being as 'people,' and patterns are ways that people talk to each other.
So, to me the factory pattern is like a hiring agency. You've got someone that will need a variable number of workers. This person may know some info they need in the people they hire, but that's it.
So, when they need a new employee, they call the hiring agency and tell them what they need. Now, to actually hire someone, you need to know a lot of stuff - benefits, eligibility verification, etc. But the person hiring doesn't need to know any of this - the hiring agency handles all of that.
In the same way, using a Factory allows the consumer to create new objects without having to know the details of how they're created, or what their dependencies are - they only have to give the information they actually want.
Use Factory Method when instantiating a subclass and the client code isn't supposed to be responsible for deciding which particular subclass is instantiated.
It is useful because it prevents you from having to change client code when you need to change what class gets instantiated. Changing existing code is bad practice because it is typically error prone.
An example would be having subclasses, where each one sorts data in ascending order, but in a different way. Each way is optimal for a particular kind of data. e.g: partially sorted data, data that are numbers etc. The client code is a class that only handles printing of data. Having code that decides which sorting class gets instantiated in the client class would make it a complex class. In other words having more than one responsibility, in this case, deciding which sorting class is optimal and printing data. By putting the code that decides which sorting class gets instantiated into a Factory class it separates the concerns so that you don't need to change the client class every time you need to change which sorting subclass gets instantiated.
It's a way of covering your arse, if you can foresee your self-making changes down the line in how or what class gets instantiated then factory classes makes sense to use. It helps keep your classes focused on their one responsibility and as a result ensures that you are less likely to have to modify existing code that isn't related.
