Photo by Modestas Urbonas on Unsplash

Split a large class into two separate hierarchies

Swift — Problems Catalogue #8

Problem Definition:

Consider the following scenario. You have to implement a Space Atlas App 🪐🌌 (JSW telescope hype ✨) with the catch that after the astronomer is done inputting the information & images about a particular celestial object, they need to store it based on it’s type in different databases.

But what will happen if changes come in (they usually almost come). What will happen if we need to change databases or we need to include other types of Celestial Objects beside Planets or Stars. Objects like Pulsars, Quasars, Black Holes, Star Nurseries, Potential Artificial Structures 👽. The list can go on and on.

*Disclaimer

Normally, these kind of things happens on the server side. From a mobile App’s perspective, the handling of where & what needs to be stored in a remote environment should happen in an opaque style & not mobile side. If you remove the ViewControllers, you can use part of this code server-side. (Vapor FTW 💧) and from a system design POV, it becomes valid.

Problem Solution:

Solution —Bridge it’s a structural design pattern that divides an abstraction from its implementation. In this way you can split a large class into two separate hierarchies that can be developed independently.

It’s very useful especially when dealing with multiple API providers. It’s a little more complex than the previous ones but do not worry. As soon as you write it yourself, you will start to comprehend it’s utility.

The reason for not making the code snippets below copy-paste-able (if that’s a word) is that some of these concepts are quite difficult to grasp if you don’t write them first yourself. I know it’s a nuisance but it will pay on the long run. There is a difference between knowing something and truly understanding it.

Real-World Usage:

First, let’s start with some protocols. Considering that there are a lot of things in space, we need a protocol in which we need to define some generic things like the name or title, a description, & of course a lot of images ☄️

Second, we need a protocol in which we need to define the operations which we will use from the Apps Perspective like connecting to a database, uploading the content to it & of course deleting it.

Third, we could have multiple databases, one for each type of celestial objects. (A database in California that specialises in Planets, another one in Tokyo that specialises in stars, another one in London that specialises in Black Holes etc). We need some generic services for each and every one of them, like storing and removing.

Protocols

Next, let’s define the domain models. For simplicity sake, I think we can go with just two of them, the PlanetsDomainModel & the StarsDomainModel. We conform to the Content protocol and we add some particularities for each of them. Like numberOfMoons for Planets & classType for stars.

Data Models

Afterwards, we need to define the databases, one for Planets & one for Stars. Of course, using the DatabaseService protocol, we conform to it for both of them.

Types of databases

Then, let’s define a generic BaseViewController and some viewcontrollers (I know using a BaseVC it’s a kinda old fashion but it illustrates the point of simplicity & we can write the connect/upload/delete methods only once and apply them to multiple ViewControllers.)

ViewControllers

Finaly, we can put everything together and as you can see, by separating abstractions from their actual implementations we can develop them independently thus illustrating the two bridge heads and making our life a lot more easier in the long run.

Putting everything together

For the sake of simplicity & clarity for the solution, I’ve choosed to violate some principles like the Single Responsability Principle (see show() method from the SpaceAtlasApp).

This design pattern really shines when you have multiple APIs (databases, social networks etc) to which you need to communicate more or less the same (storing/removing/updating data or liking/sharing/commenting etc)

From this point on, the sky is the limit 🚀 well…almost. Of course, this design pattern has its limitations but used in moderation, it’s a great tool in our development toolbox.

This is the next article in the Swift Problems Catalogue series in which I’ll tackle general software development problems. The aim is to have a quick reference guide that can be easily accessed when having a design/algorithm dillemma.

Let me know what you think and don’t be shy to share where and when this pattern simplified your coding experience 🎶