Reusability With Swift Protocols

Aaaaaand I am back from the holidays… Christmas was great. I got a chance to spend time with my beautiful wife and two sons visiting “The German City” – Leavenworth. It was great to just chill for a bit… slay ride with kids was amazing. Seeing horses brought all my childhood memories back.

Anyway, I would like to kick off this year by spending a bit more time talking about Swift protocols. We’ve already covered it briefly here. Take a look if you are interested in what i cleverly titled as “Practical Protocol-Oriented Programming”. Even if you think you already know what protocols are, take a few minutes to read this article. There are some cool things I bet you didn’t know about.

Let’s begin by defining what protocol is. It is simply a template you use to define a set of behaviors that can later on be adopted by classes, structs and even enums. Protocols are insanely powerful especially in Swift 2.0 considering their added ability to be extended – provide default implementation.

In addition to being able to define methods – functions inside a named type such as class or a struct for example – in a protocol, you can define properties as well. Defining a protocol is very simple. But before we dive into the actual details, let’s talk about what we are trying to achieve in this article.

Let’s assume we are building a very simple persistent store manager that uses NSKeyedArchiver to persist data to disk. We can use Core Data, same principle applies, but for the sake of simplicity and being that I simply want to demonstrate the power of protocols, NSKeyedArchiver will suffice. We also want to build it as a reusable component for other projects we might build in the future.

Since this approach is essentially a protocol-oriented way to implementing / enforcing behavior, we will begin by creating a protocol first. We know that we will need a couple of methods from the start; methods such as save, add, remove come to mind. Here is a protocol definition is Swift:

There are a couple of things that I should mention off the bet.

First, we defined a protocol named ObjectStoreDelegate.

Second, inside of this protocol we defined a couple of methods, a variable of type array and typealias.

Why typealias? Using typealias defers type definition of the exact type to our protocol adopter. Our protocol adopter weather it’s a class or a struct is responsible for defining the exact type, not the protocol itself. Think about it for a minute… think what it really means. It means we can write our ObjectStoreDelegate protocol to work with different types of objects as long as those objects inherit from BaseObject and implement NSCoding protocol. Really awesome.

It is also important to note that protocol variables are required to mark themselves as ether get, set or both and that’s what you see above.

Array in this example will store our objects that need archiving / unarchiving.

So since we defined our protocol, let’s move along by creating a protocol extension. We can use this extension to provide default implementation for methods we declared earlier.

While here, I would like to mention another awesome feature of Swift protocols – Type constraint. Type constraint simply enforces our protocol adopter to also adopt methods and properties of specified type.

Our protocol extension, by choice, will provide implementation for all methods but will leave up to protocol adopter to define the Object and initialize the array that will be used for storing our custom type objects.

The next step in building our ObjectStore is to declare a singleton we can access from anywhere in our code.

But before we do that, let me show you what our model looks like so you have a point of reference:

Now, let’s build our Store singleton.

As you can see, the only thing our Store is concerned with is specifying Object to be the Item and also initilizing the array that will hold given Items. That’s it. Take a moment and step back to appreciate this… this was simply not possible before protocol extensions in Swift and not possible in Objective-C at all.

Using protocol-oriented programming approach offers so much… reusability being at the top of the list.

You can find the entire project on my Github page.

Reusability With Swift Protocols