Swift Protocols — Associated types
Protocols
In Swift, protocols are like contracts, in which classes or structures commit to present some attributes and implement some methods. It’s an interesting way to ensure that, even if they are of different types, the instances you create will always have similar characteristics.
To better understand the protocols in Swift, let’s make a clear example, with a very common subject: Super Heroes!
What does it take to be a super hero? In our example, let’s think about some very basic attributes. First: they need to have a strong, striking name (even if it’s ridiculous like “Green Lantern”). Second: they can have one or more super powers.
To ensure that any structure or class has at least these two characteristics, we can create a protocol that looks like this:
Note that, when creating a protocol, we need to determine: which attributes, their types and forms of access.
A structure that could represent a DC Hero, for example, would look something like this:
In this case, the framework implements exactly the minimum stipulated by the protocol. A DC hero, then, could be created like this:
See that we have a variable that meets the requirements of the Hero protocol, as it is an instance of the DCHero type structure.
Nice!
Now, if Marvel wants to use the same protocol, but beyond the minimum stipulated by the protocol, it wants to say whether or not one of its heroes is a deity, we could create the following structure:
See that the basics (name and powers) are guaranteed by the protocol, and we also have added the attribute about the deity. Thor, for example, would be represented something like this:
The great advantage of this protocol would be the possibility of having a list with all the heroes, regardless of their universe. Like this:
This allows us to perform basic operations between them, like comparing their powers, for example (obviously Marvel would win, wouldn’t it?)
Associated types
Well, now that we know the concept of protocols, let’s get down to business: associated types!
Protocols bring us the great advantage of being able to work with different types that have similar attributes and functions. But let’s say we still want to standardize the characteristics of hero teams.
How can we create a protocol in which we have characters from different universes? We could create a protocol that has another type associated with it. It wouldn’t make sense to have a definition of team if we don’t have the definition of hero. Thus, the Team protocol is dependent (associated with) the Hero protocol. Look:
The Team then has a name, a list of heroes, and a basic function for adding new heroes to the team. As the add function is common for teams (it just adds to the list), we created a simple extension here to implement the function at once.
A DC league would have, in addition to the name and the list of heroes, the identification of which of the parallel earths this team is part of. So, we could define its structure as:
The instance of the justice league would be like this:
Similarly, it is possible to create Marvel teams, such as the Avengers for example. Here is a suggested activity: create a playground to test this code and add the Avengers for testing.
Can you see the benefit of using an associated type?
No?
Look: if you decide to create a new universe for comics, you can simply use the Hero protocol, so it will be within the standards established by the industry. And if you want to create a team of heroes, just use the Team protocol.
What if the industry changes the requirements for a hero (like changing the Hero protocol attributes and methods)? Everyone who signed the protocol will have to change their implementations to suit.
What if we want to do a crossover? Do we need to create a new universe? No, we can simply create a new team, once it accepts a Hero as its associated type. We could have all the characteristics of the heroes from DC, Marvel and their new universe together in the same league.
Associated types!
