Charlie and the Factory Method Pattern
When reading documentation about Design Patterns or Design Principles, I find that most of the times the examples are created to be really simple, just enough to understand the essence of it. The inconvenience of this approach is that, then, lots of times you don’t see a real application of what it is explained. And, because of that, it is quite hard for you to see how you could apply those principles and patterns in real life with real problems.
The other day I started to develop an Apple TV weather app to both practise Swift and learn how to develop an app for the tvOS platform. The idea, for making it a little bit funnier and original, is to let the user choose the weather service provider from a list of implemented weather services.
From the first moment I realised that this was a very good example for explaining how the Factory Method Pattern works and how to implement it in Swift.
From the Wikipedia:
In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created.
A real example
The first step will be to specify the interface of the objects we want to create within the factory method, in this case a Weather Service. We will also need a method that will return a Weather struct with the weather forecast in a completion handler, for the passed city and its country.
At this point, we can create as many services as we want, with its own implementation, conforming to that protocol. For example, we could create implementations to provide the weather forecast from the services Open Weather Map and World Weather Online (full implementation in the GitHub repository):
The last step would be to create the factory itself:
Now every time we want to add a new service we just have to:
- Create it and implement the WeatherServiceProtocol
- Add a case to the enum and return the instantiation of it in its corresponding case of the switch
Therefore, when we want to use a weather service we can do it as follows:
Now when the user selects a different service, we just need to replace .WorldWeather with the new service enum case.
Wrapping up
We’ve implemented an example of a Factory Method Pattern to create weather services objects without having to specify the exact class of the object that will be created. We achieve that by using a very important design principle: “Program to an interface, not an implementation.”, in this case by programming to the WeatherServiceProtocol instead of to the different concrete implementations.
The Design Patterns are general ideas and there is not a unique way of implementing each one of them. There may be different and even cleaner ways of implementing this pattern in Swift, in which case I would love to know about it. So do not hesitate to leave a comment with your own ideas.
Resources:
You can find the code of the WeatherTV project in this GitHub repository: https://github.com/dadederk/WeatherTV
Swift 2 Design Patterns -> Chapter 1: Creational Patterns -> The Factory Method Pattern: http://www.amazon.co.uk/gp/product/1785887610/ref=as_li_tl?ie=UTF8&camp=1634&creative=19450&linkCode=as2
