Design Patterns Saga: The Beginning
By: Gene Zeiniss
Tags: Backend, Design Patterns, Factory Pattern, Polymorphism, Java

Factory Design Pattern

What are your associations with the word factory? Someplace where workers manufacture goods. This is exactly this. The Factory Pattern is a creational pattern, whose purpose is to create objects. Just like a factory in the real world. In this pattern, the object creation happens in the factories, without exposing the creation logic to the client. Imagine that your software implements a sushi bar and you want to create sushi to serve at your bar. There are many different types of sushi, but let’s start with the California and Dragon rolls that were mentioned in the polymorphism example.

A lot of the sushi rolls we’ve become familiar with are a Western take on Japanese Maki sushi. Therefore, to implement the sushi bar software, you need a Maki interface and concrete California and Dragon classes implementing Maki. Let’s say that all you need to create a maki roll is to add fish, fillings, and the topic. Can you smell polymorphism? Kidding, this is an overriding example we mentioned earlier.

Now, you need a createRoll(RollType rollType) method. The method will first declare the maki variable, which will refer to the maki object to be created. Think about it, like maki base, which is traditionally made with a sheet of nori, wrapped around a layer of rice. California Roll, for example, is an inside-out sushi roll with a layer of rice on the outside and a sheet of nori on the inside. The roll type parameter will determine which maki roll is actually instantiated.

When you have a base for your roll, you can call methods to add fish, fillings, and topics. These methods do not care what type of roll is created. All they want is a maki base to operate on.

The method looks like this.

Your brilliant chief adds more and more roll types to the menu. Spicy Tuna Roll, Spider Roll. In this example, the list of conditionals grows and grows as new roll types are added.

Notice that what we do with the roll after creating it doesn’t change. Each roll needs to contain fish, fillings, and topics. This is all getting pretty complicated. To decouple maki instantiation from the client, you can delegate the responsibility of maki base creation, based on provided roll type, to Sushi Factory.

In general, a factory object is an instance of such a class, which has a method to create product objects (maki base, in our case). Now, this Sushi Factory can be used by the Sushi Bar service. In other words, the sushi bar is now a client of the sushi factory.

Here is a UML diagram of the Sushi Bar service you just implemented.

Let’s look, what have you gained here? The Sushi Bar service and it’s createRoll(RollType rollType) method may not be the only client of Sushi Factory. Other clients, such as Sushi Delivery and Sushi Takeaway may use Sushi Factories to create maki as well. Since all of the actual maki creation happens in the Sushi Factory, you can simply add new roll types to your factory or to change the way the rolls are instantiated, without modifying the client’s code.

That’s all! Now you know your onions 🤓. And I know that I feel like ordering sushi delivery. This post made me hungry. Bon appetit!