Go — Factory Pattern

Prerequisite

Before read this article, make sure you have a good understanding towards Go Interface.

Introduction

Factory Pattern is probably one of the most used design pattern in OOP world. This design pattern is part of Creational Design Pattern as this pattern provides the way to create an object. This pattern came from a book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

In Factory Pattern, we can create an object without exposing the creation logic of the client. The purpose of this approach is to abstract the user from the things like dependencies that needed to create the class. The user only needs an interface to get this value (the struct or accessing the functions within).

Delegation, will make you happy

Let’s say, our previous Car and Train are produced in same factory, we call it as Engine Factory. The boss of the factory doesn’t need to know the detail implementation of how the Car Engine or Train Engine is produced. The boss only send a message to the factory manager, “Bring me the car engine”, then the factory manager will decide to gow where the assembly line of car engine is located. After factory manager get the wanted engine, he will come back to the boss with that engine.

Factory Pattern works like the factory manager in that case, the decision and composition to create the object will be done in in this pattern.

This is the code will looks like while the factory boss asking to factory manager in above case:

The boss just tell, “car”. And then the rest of the work on how car engine is created, will be handled by the factory manager (in this case factories.GetEngine(type string) ). Then the factory manager will return the car engine to the boss, after that client (in this case factory owner) can do the rest of operation with the car engine functions. Without distracted with the assembly line detail to create the engine, it makes boss more focus on the conducting business for the company. Boss is happy because he can get the convenient way to get the engine, factory manager get promotion, the rest of employees get raising wages. What a happy story!

This happy story also can be yours as software engineers, to do abstraction in your codes, it will make your code easier to be maintained.

Lets we take more deep into the implementation:

Step 1: Create the Engine interface, for example we just create Assemble method.

Step 2: Create Car Engine struct to implement the interface

Step 3: Create Train Engine struct to implement the interface

Step 4: Create a method to call the Engine.Assemble() , in our scenario, it might close to the secretary role.

This function used to be the wrapper, if the requirement is change in one of the implementers, then we no need to change to multiple client that call Engine.Assemble() , we just focus on this method.

Notes: For modification strategy (if this function need to be changed), we can use Structural Pattern type — we will talk about it in another article. But, for now just keeps it on this current implementation.

Step 5: The factory pattern itself. This function will handle the delegation of the object creational.

Maybe you can improve by yourself, such as used enum, to register the supported type inside the Factory Engine.

Step 6: We will create the client of the factory. Because this is only an example, we will directly call the factory inside main.go . So, assumed main.go as the “factory owner”, the one who request something to get the results.

As you can see, “the factory owner’s desk is clean and clear”. It will make the client more focus on the business process to solve the problem, instead of juggling with the creational detail.

We also can add some extra lines (from line 12), to demonstrate scenario for Train and the undefined engine type.

And the boss no need to do detail checker whether the Ship engine is exist or not, because the null checker is done on the wrapper function bizsrvc.AssemblingEngine, boss only just need to make the request and receiving the results. The detail processing, verification, handling failure, etc can be delegate to other services.

One more time, boss is happy, factory manager position is safe, and employees get bonus!

Conclusion

We have play around about the Factory Pattern, we can make a conclusion, now.

• Hide detail of creational object, and delegate the instantiation (even dependency injection) to the factory
• Decouple the abstraction and implementation, so factory can do the creational operation
• Make the client happy! So, you can create a simple solution with flexibility and reusable components

Happy implementing Factory Pattern in your Go-land!

Extra Notes: Gopher is Go Language mascot (used as part of the image cover in this article), created by Renee French. Creative Commons Attribution 3.0 licensed.