More on (protocol) extensions

Today I’ve found myself in what I would consider a funny situation: having to explain what protocol extensions are to an Android developer that has just started to get some exposure to Swift.

In fact, the whole concept of extensions (the good old categories in the not so good old Objective-C times) are a little bit difficult to grasp. So I decided to the best way to explain the whole thing would be to start from scratch, with one protocol, one extension, and a class implementing the protocol:

Neat!. Now, on to the next step: overriding the default implementation provided by the protocol extension:

Good. Now, we understand how protocol extensions work, how we can use them to add behaviour to entities, and how we can override that behaviour, when needed.

But there is more to it. Protocol extensions can also be applied to specific types. In particular, we can apply a protocol extension to one type and only one type that implements said protocol.

But there is more to it. Extensions can also enforce types to implement a protocol. So, we can modularise the previous example even more:

And now we have two axis of customisation. We can force a type to implement a protocol, and we can change the implementation of the methods in that protocol according to the type that is implementing it.

And yes, Soundable, as a protocol name, is horrible.

Leave a Reply

Your email address will not be published. Required fields are marked *