Factory Design Pattern in Swift for Beginners
Programmers can be called a lot of different names, but artisan is not one of them, in my opinion. End users, can not feel the difference between two separately initialized buttons.
We create various buttons, labels, and views. If you find yourself in a position where you copy and paste the same code to create the same objects, this pattern is for you.
What is Factory Design Pattern?
The factory pattern is a creational pattern that allows you to construct things without disclosing the logic that goes into making them. There are usually three actors involved:
- The owner of the factory that uses/owns the creation methods
- The factory that creates the end object
- The object that is the created end product
This design pattern comes in a variety of implementations like the simple factory, the abstract factory, or any others. But each of these, however, has the same purpose which is to encapsulate object creation logic within its class.
In this article, I will go over the simple factory pattern which is better to start for beginners.
When do we use it?
This pattern comes in handy when:
- You create objects from the same models over and over again,
- Not only creating a particular object but different flavors of the same model according to properties,
- Overall simplifying an object creation,
- Streamlining object creation in projects such as UI components,
- Needing the ability to change all objects all over the project,
- Reducing the if/switch statements inside the view controller.
Compare below two examples for configuring the ScoreCard model for the score given:
Having all this logic inside our class is eye-soring. If we need to show the scorecard in another place, will I copy this code and paste it there? No.
By implementing the factory pattern we will end up with something like this:
Shorter, cleaner, delicious. The class knows nothing about the creation logic. It's only concerned with the final object, as it should be.
Implementation
Fire up a playground and start typing the below code in order.
We define two structs.
- The first one is the Score which we define it with an Int point. And it also provides us with a computed property status. The status property will come in handy when differentiating between scores. We won't be dealing with math in the factory method, because it's taken care of here.
- The other is ScoreCard which we will fill with the information given by the Score model.
- Now we created the ScoreCardFactory class.
- It has one method for now which takes a Score argument and returns a ScoreCard.
- Inside the createScoreCard method, we create the ScoreCard object according to the status of the score using the switch case.
Now, let's test this new factory.
- We defined some scores.
- Initialized the ScoreCardFactory.
- Created ScoreCards using the factory's createScoreCard(for:) method.
- Printed the result.
As a result, we built an API for a safe and easy way to create ScoreCard objects. In the end, we don't know how the ScoreCard is created. In this class, we are only concerned with the final product.
Do we need to change how we configure a ScoreCard? Now we only need to change one place which is, the factory's creation method.
We successfully separated the logic from the owner/user class.
A real-world case
In the project I work on, we use factory methods for button creation. You see we have predefined buttons which were decided by the design team. And they are going to be the same throughout the app. Now whenever we need to use a button, we don't create it by ourselves, but initialized a ButtonFactory, then use the create methods which return a button object.
This factory allows all the developers to use the same method, which prevents misconfiguration.
A change in the button text font? No problem, just fix it on the factory method. No need to fix it in 25 different locations.
Be careful when…
All this work may be too much for simple objects. If that's the case you can put the creation logic directly in the owner/user, which is probably a view controller.
The key is avoiding repeating ourselves. If you don't see yourself repeating the same creation logic, it could be fine to not create a factory.
By the way, if your object takes several stages to construct, the builder pattern may be more appropriate. Check out my article about builder pattern for beginners.
Congratulations. You’ve made it to the end.
This is a great pattern to learn and implement. This will be a great asset to your coding arsenal.
I hope that the above explanation makes sense and will be helpful to you on your iOS development journey.
Thanks for reading. Have a great one.
References:
