Factory Design Pattern in Java
By: Michael Tong
Tags: Java8, Java, Design Patterns

Photo by Science in HD on Unsplash

Have you ever look at a factory and wonder how things are created so quickly, in such an automated fashion?

When we are buying something that came up out of a factory, we are never concern how the factory produced what we are looking for. We are only concerned about getting what we requested, which is the item we are buying ourself.

That’s how the factory pattern works in java.

With factory pattern, objects are created without exposing the creation logic to the client and refer to newly created object using a common interface.

What? What does that even mean?

Photo by Will Esayenko on Unsplash

For example, let’s say we have a factory class that gets us some shapes. We can choose between a circle and a rectangle, let’s say. We specify the factory to give us a circle or rectangle without having to instantiate the circle or rectangle ourselves. In fact, we do not even care about how the circle or rectangle was created/implemented because the factory handles it for us.

Let’s take a look at how the factory is setup:

Over here, we have a shape interface. We created a shape factory that returns a specific type of shape. We throw in a parameter that will give us the corresponding shape we wanted.

Here is a real world analogy: it’s like going to McDonalds and choosing which burger to order. The fast food restaurant works just like a factory; the customer does not need to be concerned about how the burgers are created. All they cared about was what burger they ordered and the restaurant will give them exactly what they need.

Let’s take a look at how client code will handle:

Over here, we instantiate a shape factory. From there, we can choose what kind of shape to get, without instantiating the specific shapes like Rectangle and Circle ourselves.

One might ask: why should we use the factory design pattern instead of just instantiating the different objects ourselves(Circle, Square, Rectangle)?

First of all, it allows developers to support more objects with their factory class as times passes by, without affecting client code.

Take the example above: let’s say we need to support additional shape classes, such as triangles and pentagons. All we have to do is add a triangle and pentagon class that implements the shape interface and add a new logic in shapefactory.java to generate triangles and pentagons upon request.

How about the client code? Does it affect the client code when you add in additional code to support triangle and pentagon class?

Not at all since all the changes are happening at the factory level. Client code doesn’t have to change at all in this case. It’s like going into a fast food restaurant the next day and you realize there are new burgers you can order. It doesn’t block you for ordering the burger you always order though. That’s exactly how factory pattern works.

Let’s summarize pros and cons of factory design pattern in the following sentences:

Pros:

allow us to hide implementation of how the shapes and the factory is implemented. All user need to be concerned is how to get the instance it needs via the right call.

allows loose coupling between client code and factory logic. It allows factory logic to be extended and scale for additional code in the long run.

Cons

Troubleshooting can be challenging as the factory logic is all hidden due to abstraction.

That’s all to it for factory design pattern in java!