Advanced iOS Series — Episode III: Design Patterns in Swift: Abstract Factory
Learn advanced design patterns used in iOS app development with Swift. Unlike the ones we use in daily life, the design patterns described in this article are the ones that will make you stand out in the sector.
Design Patterns are divided into 3 types: Creational, Structural and Behavioral. Since we have touched on advanced topics in this series of articles, we will cover these 3 different types in depth in separate articles. Our first topic is Abstract Factory, a creational design patterns.
If you want to make a difference with what you will learn, I strongly recommend that you review the sample project along with the article.
You can find the sample projects source code here.
Table Of Contents
1-) What are Design Patterns?
2-) Why we need Design Patterns anyway?
3-) What areCreational Design Patterns?
4-) Abstract Factory
5-) Problem
6-) Solution
7-) Conclusion
What is Design Patterns?
Design patterns are conventional responses to typical issues that arise in software design. To fix a reoccurring design issue in your code, you can modify them like pre-made blueprints.
Patterns and algorithms are sometimes misunderstood since both notions represent familiar solutions to well-known situations. A pattern is a higher-level description of a solution, but an algorithm always specifies a precise set of operations that can accomplish a certain goal.
Why we need Design Patterns anyway?
Even though the methods and languages we use while developing software are different, the problems we face are quite common and similar. One of the best ways to solve common problems is to produce common and inclusive solutions.
On the other hand, while developing iOS mobile applications with Swift, we are likely to encounter similar problems in different projects. The approach we use in one project can work for us in other projects as well. We use Design Patterns to standardize these solutions.
We need Design Patterns for exactly the reasons that I have mentioned. The key point here is “Patterns”.
Creational Design Patterns
We iOS Developers always aim to develop flexible and reusable codes. Creational Design Patterns help us to reach that goal. Thanks to the various mechanisms it offers us, we easily create objects that serve our goal.
Abstract Factory
Let’s say you have a set of related classes. While creating these classes, we do not want to create a dependency between them even though they have relations with each other. What we need to do here is to use abstraction to eliminate the concrete type. Abstract Factory is a creational design pattern that offers us this possibility.
Problem
Let’s say you have a class that is responsible for generating Phones. As you can imagine, your phone consists of different parts, and each different part has various variations. To determine the price of the phone, we need to calculate the price of each variant.
In the future, we can include new parts in our phone production, we can remove some old parts, and we must not break our phone while doing this. In addition, the price calculation should always work correctly.
Examine the diagram below for a clearer understanding.
If we want to create a Phone with this initial setup, it would look like this:
As you can imagine, we will have to make changes to our Phone creation processes for a change made in one of the defined models or when we add a new feature.
Solution
The first thing the Abstract Factory pattern tells us is that we need to define abstract interfaces for each of the concrete types. In this way, our Phone class will not know the implementation details of its subclasses and the dependency between them will be broken. Now our code will be open to improvements and modular.
Below diagram and code are showing the new implementation.
So far, we have only abstracted our models, but we still haven’t created the “Factory” part, which is our main goal.
We will transfer all the Phone creation logic to our Factory class and we will manage the creation process from one place.
Below codes are showing the completed implementation of Abstract Factory design pattern.
Let’s take a look at what we did step by step:
- We made the variables of our PhoneConfiguration interface optional. In case of missing configuration, our Phone creation process will fail.
- We defined PhoneType enum to increase clarity.
- We defined our PhoneCreator interface for our Factory class.
- We created our PhoneFactory class and added our createPhone method. We created our configuration using our Helper configuration method and checked optional values.
- We defined our Phone objects for the type given in our Helper method configuration.
Conclusion
With all these improvements we made, we got rid of the tight coupling between our concrete types and our client code. Our code has also become open to extensions. Each class has become responsible for only one task, so we have created a modular structure.
