Design patterns: Facade. Real examples in Swift

This article is a part of the design patterns post series. Design patterns, in general, are key to stop reinventing the wheel in most of the common developer challenges. I think that design patterns are great as a resource which can spend your time.

Here you can find a post about the difficulties of a variety of tutorials and courses, and there a gave a list of sharableknowledge and technologies which will be useful on any developer’s job and which you can apply to any platform and stack.

But let’s talk about the Facade pattern

Facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.

From book “Dive into design patterns”. (It is not an ad)

The explanation is pretty simple, but the main problem of all design patterns and shared knowledge, in general, is an abstraction. That means that the same definition can be understood differently. That’s why the main goal here is to understand the pattern principle and apply it to real tasks.

Real examples or situations where the facade in any form of implementation should be applied

Let’s remember the “Back to the Future Part III” movie. There is a huge mechanism in a Doc’s garage.

Looks great, but anyone can’t work with this, except you Doc

And only after launching this machine we understood that it is just a refrigerator. You can imagine that this machine is a software of some difficult but useful library or framework. This difficult form of any mechanism (or software) creates a lot of problems:

  1. Only the creator of the library or framework can quickly launch, setup, or adapt this library of frameworks to work. All other developers should learn the implementation of this event if they don’t have to.
  2. Different developers can setup this library or framework in a wrong, non-optimal way (because they can’t and don’t want to learn the core of this library and framework, they just don’t have time for it).
  3. One day this library or framework can be changed, updated, or replaced on another difficult complex solution, and points 1 and 2 should be repeated, and all code that depends on the old library should be refactored.

Facade Swift implementation part

These problems are pretty common to any software development because we always work with third-party libraries or with custom solutions.

Custom plugin for payments

Let’s imagine that you are working on a project where someone from your team wrote the custom payment library and this library even has documentation. But it is not a key here and you still need to read and understand this documentation, write your setup of this library (or find it in another place in this project). And even if you will be done it is still difficult to replace this library with another later.

This simple facade can solve a lot of problems with difficult complex software. All of these manipulations inside the makePayment function should be written each time in all modules which need payment functionality. But with this facade, you can easily work with it without any knowledge about this library. All that you need here is to understand that you just have a list of customer payment methods and simple function which can do magic for you under the cut.

So this facade should be written by the creator of this library or one developer which can spend time on this. After that, any of the developers only with basic knowledge of this payment system can easily create an instance of this facade class and use it in any place that they need. If the library will be changed (it is important to leave the facade functions signatures as it was before), all places where this facade used will be unaffected. In a worst-case even if the facade will change his functions name, parameters, and return types — that can be anyway easier to rewrite few functions calls then replace all uses of the library without facade.

Third-party libraries

Try to hide third-party libraries behind the facades. Real example. What if we have some ImageSlideshow library. It is super convenient to wrap it in protocol + extension, or some facade class. It easily hides the gallery implementation and you can just easily call this single openGallery method without knowing about ImageSlideshow. If you need to change this library to another — you can just rewrite this class. A library like this should be isolated and then it can be easily changed later.

Photo by DDP on Unsplash

Resources

https://refactoring.guru/design-patterns/book

https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8

My social media

LinkedIn Twitter Original Blog Github HackerRank

iOS Software Developer