Another post, another JavaScript design pattern. Today we feature the Factory pattern. The Factory pattern is one of my favorite patterns, especially the “simple factory”, which I’ll explain later. Factories – in real life as well as within the programming world – create objects. It helps clean up your code by removing all of the new
operators.
As usual, at the bottom of this post is a list of all the posts in this JavaScript Design Patterns series. I think it may be worth spending some time reading those too.
Simple Factory
There are two types of factories: the Simple Factory and the normal Factory. We’ll start out with the Simple Factory because it’s… well… simpler. Today, instead of simply conjuring up an example, we’ll actually use our example from the Decorator pattern post and fix it up to make it purely awesome. If you don’t understand the Decorator pattern, then you really should go back and read about it before continuing on if you want this to make any sense.
So, what is the Factory pattern going to do to make the Decorator example better? If you remember the end implementation code, if you wanted a vehicle with all three of the features that were currently coded, you needed to create 4 objects, all with the new
operator. This is tiresome and tedious, so we’re going to use a single function call to create a car with all of the features we desire.
The Simple Factory is just a Singleton (or just an static class in most programming languages, but in JavaScript, they’re essentially the same) that has one or more functions for creating and returning objects. If you look at the code below, you’ll see that object written and how to use it.
1 | var CarFactory = { |
Making the Factory Better
Our Decorator example had some additional problems that were not solved in the previous code snippet, though the Simple Factory can make it easier to solve those problems. Problem number 1 was that there was no way to ensure that a feature wasn’t added more than once. For instance, you could have several PowerWindowDecorator
s wrapping the same car, which wouldn’t make much sense. The other problem was that if the features should be added in any specific order, there was once again no particular way of enforcing that rule.
We can fix both of those problems using the Factory pattern. The best part is that none of this logic needs to be contained within the Car
object or the decorator objects. It is all in one place: the factory, which in a real-world perspective makes sense. Do you see the car or its features knowing how to add features or which order to install them in? No, this is handled at the factory.
1 | var CarFactory = { |
Can you now see why the Simple Factory is one of my favorite patterns? It takes all of the tedious bits out of object creation. Granted using a factory to create a single object that does not adhere to any interface except its own is pretty much just idiotic.
Another Way
The Factory’s power isn’t limited to Decorators. Basically any objects that share an interface can all be created using a Factory, which helps decouple those individual objects from your code. All you know for certain is what type of object you’ll receive from the Factory so the only thing you’re dependent on is the Factory and an interface, no matter how many different objects implement that interface.
How about I show an example of using the Factory for non-Decorator purposes? The next Factory is going to be part of a fictional MVC framework. The Factory can get a model object of the specified type and ship it back to the controller.
Different controllers use different models and even within the same controller it might use a different model for different methods. Instead of hard coding the specific model “class” names into the controller, we use the factory to fetch the model for us. This way if we change to a new model class (maybe we decided to use a different type of database) the only place where we need to make changes is in the factory. I won’t go into the details of how to implement this, because that would be a waste of time. We’ll just show how it’s used and I’ll let you use your imagination for the implementation code. Below you’ll see the code for a controller that uses the factory.
1 | // This controller uses two different models: car and cars |
Bringing this Madness to an End
Finishing already? What about the normal Factory? I believe this post has become long enough, don’t you? How about we reconvene on Wednesday for another post dedicated entirely to the normal Factory Pattern? There should be enough code to write that it shouldn’t be too short. Besides, this gives you some time to absorb the knowledge you gained here before I fill your head with more nonsense.
So, if you ever run into the Decorator Pattern or into any group of objects using the same interface, make sure you consider using the Factory Pattern to accomplish the creation of those object in order to remove the dependencies on those objects. Also, make sure to leave a comment below if there’s anything you want to shout out to myself or the community. Remember, it’s your comments that make this a community to get involved in, rather than just a blog with static text.
JavaScript Design Patterns series: