My first implementation of protocol extensions in Swift

Nuno Gonçalves
2 min readJan 6, 2016

--

Protocol oriented programming is the new cool kid on the block in swift. It was first introduced at Apple’s WWDC last year and there are already plenty of articles discussing it. I have to admit it, when I first saw this I couldn’t quite figure how it could change/improve my code structure in practice.

A few days ago I came across this excellent post from @mhollemans that helped me giving it a try again.

This post just shows how I implemented my very first protocol extension, which made me quite happy. Nothing like a very basic thing to make you happy. ☺

My starting point was on network request classes, which had duplicated code. Every class that made a request had the same code. The only different thing was the endpoint url, and how to converting the response dictionary to business objects.

This was the code for a given class (Languages) before the refactor:

This code represents the use case of requesting languages from a external API. The use case receives two callbacks, one for success and another for failure. It changes to a background thread where it calls makeGet method on the requester object. The response handler is an object that exposes the success and failure methods, that will be called back on the main thread after the request finishes. This is the typical way I make network requests.

More classes had almost the same code. The only differences were the request url and converting the API request data dictionary into business objects.

Obviously refactoring this code could also be done with inheritance, but as always, with inheritance you limit that class to the parent’s class behaviour.

With protocol extensions, you are now allowed to add default behaviour to a class without the need to inheritance. This way, the class can “inherit” multiple behaviours from multiple sources without ever needing a super class.

Here’s the way I made my implementation:

I created a protocol, called Getter with three methods, getUrl(), getDataFrom(dictionary) and get(success, failure).

The beauty of this code is that now with extension Getter you are effectively adding behaviour to the get method inside the protocol, which in turn will be available on all conforming classes.

Any conforming class will automatically have the get behaviour without ever needing to implement it. This default implementation depends on the getUrl and getDataFrom(dictionary) methods which are the only concerns the class needs to take care of. So it implements only those two methods making it a lot simpler.

This is a very simple use case to use protocol extensions. Although there might be other ways to do it, I’m very happy with this approach.

The best thing is you are adding default behaviour (also known as “adding a mixin or a trait”) to multiple classes without using inheritance. Using protocol extensions you allow your objects to “inherit” default behaviour from multiple and completely different sources.

If you have questions, think there might be better ways of doing things, or don’t agree with something, leave a comment or let me know on twitter @goncalvescmnuno

--

--