Protocol is a very powerful feature of the Swift programming language.

Protocols are used to define a “blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality.”

Swift checks for protocol conformity issues at compile-time, allowing developers to discover some fatal bugs in the code even before running the program. Protocols allow developers to write flexible and extensible code in Swift without having to compromise the language’s expressiveness.

Swift takes the convenience of using protocols a step further by providing workarounds to some of the most common quirks and limitations of interfaces that plague many other programming languages.

An Introduction to Protocol-oriented Programming in Swift

Write flexible and extensible code in Swift with protocol-oriented programming.

In earlier versions of Swift, it was possible to only extend classes, structures, and enums, as is true in many modern programming languages. However, since version 2 of Swift, it became possible to extend protocols as well.

This article examines how protocols in Swift can be used to write reusable and maintainable code and how changes to a large protocol-oriented codebase can be consolidated to a single place through the use of protocol extensions.

Protocols

What is a protocol?

In its simplest form, a protocol is an interface that describes some properties and methods. Any type that conforms to a protocol should fill in the specific properties defined in the protocol with appropriate values and implement its requisite methods. For instance:

protocol Queue {
    var count: Int { get }
    mutating func push(_ element: Int) 
    mutating func pop() -> Int
}

The Queue protocol describes a queue, that contains integer items. The syntax is quite straightforward.

Inside the protocol block, when we describe a property, we must specify whether the property is only gettable { get } or both gettable and settable { get set }. In our case, the variable Count (of type Int) is gettable only.

If a protocol requires a property to be gettable and settable, that requirement cannot be fulfilled by a constant stored property or a read-only computed property.

If the protocol only requires a property to be gettable, the requirement can be satisfied by any kind of property, and it is valid for the property to also be settable, if this is useful for your own code.

For functions defined in a protocol, it is important to indicate if the function will change the contents with the mutating keyword. Other than that, the signature of a function suffices as the definition.

To conform to a protocol, a type must provide all instance properties and implement all methods described in the protocol. Below, for example, is a struct Container that conforms to our Queue protocol. The struct essentially stores pushed Ints in a private array items.

struct Container: Queue {
    private var items: [Int] = []
    
    var count: Int {
        return items.count
    }
    
    mutating func push(_ element: Int) {
        items.append(element)
    }
    
    mutating func pop() -> Int {
        return items.removeFirst()
    }
}

Our current Queue protocol, however, has a major disadvantage.

Only containers that deal with Ints can conform to this protocol.

We can remove this limitation by using the “associated types” feature. Associated types work like generics. To demonstrate, let’s change the Queue protocol to utilize associated types:

protocol Queue {
    associatedtype ItemType
    var count: Int { get }
    func push(_ element: ItemType) 
    func pop() -> ItemType
}

Now the Queue protocol allows the storage of any type of items.

In the implementation of the Container structure, the compiler determines the associated type from the context (i.e., method return type and parameter types). This approach allows us to create a Container structure with a generic items type. For example:

class Container<Item>: Queue {
    private var items: [Item] = []
    
    var count: Int {
        return items.count
    }
    
    func push(_ element: Item) {
        items.append(element)
    }
    
    func pop() -> Item {
        return items.removeFirst()
    }
}

Using protocols simplifies writing code in many cases.

For instance, any object that represents an error can conform to the Error (or LocalizedError, in case we want to provide localized descriptions) protocol.

The same error handling logic can then be applied to any of these error objects throughout your code. Consequently, you don’t need to use any specific object (like NSError in Objective-C) to represent errors, you can use any type that conforms to the Error or LocalizedError protocols.

You can even extend the String type to make it conform with the LocalizedError protocol and throw strings as errors.

extension String: LocalizedError {
    public var errorDescription: String? {
          Return NSLocalizedString(self, comment:””)
    }
}


throw “Unfortunately something went wrong”


func handle(error: Error) {
    print(error.localizedDescription)
}

Protocol Extensions

Protocol extensions build on the awesomeness of protocols. They allow us to:

  1. Provide default implementation of protocol methods and default values of protocol properties, thereby making them “optional”. Types that conform to a protocol can provide their own implementations or use the default ones.

  2. Add implementation of additional methods not described in the protocol and “decorate” any types that conform to the protocol with these additional methods. This feature allows us to add specific methods to multiple types that already conform to the protocol without having to modify each type individually.

Default Method Implementation

Let’s create one more protocol:

protocol ErrorHandler {
    func handle(error: Error)
}

This protocol describes objects that are in charge of handling errors that occur in an application. For example:

struct Handler: ErrorHandler {
    func handle(error: Error) {
        print(error.localizedDescription)
    }
}

Here we just print the localized description of the error. With protocol extension we are able to make this implementation be the default.

extension ErrorHandler {
    func handle(error: Error) {
        print(error.localizedDescription)
    }
}

Doing this makes the handle method optional by providing a default implementation.

The ability to extend an existing protocol with default behaviors is quite powerful, allowing protocols to grow and be extended without having to worry about breaking compatibility of existing code.

Conditional Extensions

So we’ve provided a default implementation of the handle method, but printing to the console is not terribly helpful to the end user.

We’d probably prefer to show them some sort of alert view with a localized description in cases where the error handler is a view controller. To do this, we can extend the ErrorHandler protocol, but can limit the extension to only apply for certain cases (i.e., when the type is a view controller).

Swift allows us to add such conditions to protocol extensions using the where keyword.

extension ErrorHandler where Self: UIViewController {
    func handle(error: Error) {
        let alert = UIAlertController(title: nil, message: error.localizedDescription, preferredStyle: .alert)
        let action = UIAlertAction(title: "OK", style: .cancel, handler: nil)
        alert.addAction(action)
        present(alert, animated: true, completion: nil)
    }
}

Self (with capital “S”) in the code snippet above refers to the type (structure, class or enum). By specifying that we only extend the protocol for types that inherit from UIViewController, we are able to use UIViewController specific methods (such as present(viewControllerToPresnt: animated: completion)).

Now, any view controllers that conform to the ErrorHandler protocol have their own default implementation of the handle method that shows an alert view with a localized description.

Ambiguous Method Implementations

Let’s assume that there are two protocols, both of which have a method with the same signature.

protocol P1 {
    func method()
    //some other methods
}




protocol P2 {
    func method()
    //some other methods
}

Both protocols have an extension with a default implementation of this method.

extension P1 {
    func method() {
        print("Method P1")
    }
}




extension P2 {
    func method() {
        print("Method P2")
    }
}

Now let’s assume that there is a type, that conforms to both protocols.

struct S: P1, P2 {
    
}

In this case, we have an issue with ambiguous method implementation. The type doesn’t indicate clearly which implementation of the method it should use. As a result, we get a compilation error. To fix this, we have to add the implementation of the method to the type.

struct S: P1, P2 {
    func method() {
        print("Method S")
    }
}

Many object-oriented programming languages are plagued with limitations surrounding the resolution of ambiguous extension definitions. Swift handles this quite elegantly through protocol extensions by allowing the programmer to take control where the compiler falls short.

Adding New Methods

Let’s take a look at the Queue protocol one more time.

protocol Queue {
    associatedtype ItemType
    var count: Int { get }
    func push(_ element: ItemType) 
    func pop() -> ItemType
}

Each type that conform to the Queue protocol has a count instance property that defines the number of stored items. This enables us, among other things, to compare such types to decide which one is bigger. We can add this method through protocol extension.

extension Queue {
    func compare<Q>(queue: Q) -> ComparisonResult where Q: Queue  {
        if count < queue.count { return .orderedDescending }
        if count > queue.count { return .orderedAscending }
        return .orderedSame
    }
}

This method is not described in the Queue protocol itself because it is not related to queue functionality.

It is therefore not a default implementation of the protocol method, but rather is a new method implementation that “decorates” all types that conform to the Queue protocol. Without protocol extensions we would have to add this method to each type separately.

Protocol Extensions vs. Base Classes

Protocol extensions may seem quite similar to using a base class, but there are several benefits of using protocol extensions. These include, but are not necessarily limited to:

  1. Since classes, structures and, enums can conform to more than one protocol, they can take the default implementation of multiple protocols. This is conceptually similar to multiple inheritance in other languages.

  2. Protocols can be adopted by classes, structures, and enums, whereas base classes and inheritance are available for classes only.

Swift Standard Library Extensions

In addition to extending your own protocols, you can extend protocols from the Swift standard library. For instance, if we want to find the average size of the collection of queues, we can do so by extending the standard Collection protocol.

Sequence data structures provided by Swift’s standard library, whose elements can be traversed and accessed through indexed subscript, usually conform to the Collection protocol. Through protocol extension, it is possible to extend all such standard library data structures or extend a few of them selectively.

Note: The protocol formerly known as CollectionType in Swift 2.x was renamed to Collection in Swift 3.

extension Collection where Iterator.Element: Queue {
    func avgSize() -> Int {
        let size = map { $0.count }.reduce(0, +)
        return Int(round(Double(size) / Double(count.toIntMax())))
    }
}

Now we can calculate the average size of any collection of queues (Array, Set, etc.). Without protocol extensions, we would have needed to add this method to each collection type separately.

In the Swift standard library, protocol extensions are used to implement, for instance, such methods as map, filter, reduce, etc.

extension Collection {
    public func map<T>(_ transform: (Self.Iterator.Element) throws -> T) rethrows -> [T] {




    }
}

Protocol Extensions and Polymorphism

As I said earlier, protocol extensions allow us to add default implementations of some methods and add new method implementations as well. But what is the difference between these two features? Let’s go back to the error handler, and find out.

protocol ErrorHandler {
    func handle(error: Error)
}


extension ErrorHandler {
    func handle(error: Error) {
        print(error.localizedDescription)
    }
}


struct Handler: ErrorHandler {
    func handle(error: Error) {
        fatalError("Unexpected error occurred")
    }
}


enum ApplicationError: Error {
    case other
}


let handler: Handler = Handler()
handler.handle(error: ApplicationError.other)

The result is a fatal error.

Now remove the handle(error: Error) method declaration from the protocol.

protocol ErrorHandler {
    
}

The result is the same: a fatal error.

Does it mean that there is no difference between adding a default implementation of the protocol method and adding a new method implementation to the protocol?

No! A difference does exist, and you can see it by changing the type of the variable handler from Handler to ErrorHandler.

let handler: ErrorHandler = Handler()

Now the output to the console is: The operation couldn’t be completed. (ApplicationError error 0.)

But if we return the declaration of the handle(error: Error) method to the protocol, the result will change back to the fatal error.

protocol ErrorHandler {
    func handle(error: Error)
}

Let’s look at the order of what happens in each case.

When method declaration exists in the protocol:

The protocol declares the handle(error: Error) method and provides a default implementation. The method is overridden in the Handler implementation. So, the correct implementation of the method is invoked at runtime, regardless of the type of the variable.

When method declaration doesn’t exist in the protocol:

Because the method is not declared in the protocol, the type is not able to override it. That is why the implementation of a called method depends on the type of the variable.

If the variable is of type Handler, the method implementation from the type is invoked. In case the variable is of type ErrorHandler, the method implementation from the protocol extension is invoked.

Protocol-oriented Code: Safe yet Expressive

In this article, we demonstrated some of the power of protocol extensions in Swift.

Unlike other programming languages with interfaces, Swift doesn’t restrict protocols with unnecessary limitations. Swift works around common quirks of those programming languages by allowing the developer to resolve ambiguity as necessary.

With Swift protocols and protocol extensions the code you write can be as expressive as most dynamic programming languages and still be type-safe at compilation time. This allows you to ensure reusability and maintainability of your code and to make changes to your Swift app codebase with more confidence.

We hope that this article will be useful to you and welcome any feedback or further insights.

About the author

Alexander Gaidukov, Russia
member since January 25, 2016
Alexander has over 9 years experience in developing applications and over 5 years with the iOS platform (iPhone and iPad). He has worked in teams of various sizes from small teams to very large groups. He also has experience working freelance on and off over the past 5 years. Alexander is a self-motivated and communicative professional who can work well independently and with a team. [click to continue...]
Hiring? Meet the Top 10 Freelance Swift Developers for Hire in February 2017

Comments

Dusan
Hey, so wouldn't this be closely coupled code? Wouldn't having loosely coupled code through composition be better?
Alexander Gaidukov
Hey. I don't see any closely coupled code here. Could you clarify what you mean?
Dusan
Yeah, maybe my understanding of protocols is bad since I have not had the chance to try swift yet but it sounds like the relationship it creates is inheritance right? I kinda feel like the idea of programming to protocols a lot meant loosing flexibility down the line and I guess I think it might lead to less experienced people typing code that implements protocols it should not. Like anything that implements a protocol must confront to it making it closely coupled with that protocol, right?
Alexander Gaidukov
Fo sure, like any other programming patterns, it should be used in appropriate way. You don't need to implement Queue protocol in case if your type doesn't work as a queue and so on. More over, in some particular case using protocols leads to loosing flexibility (you can read about it here http://chris.eidhof.nl/post/protocol-oriented-programming/ ). But if you use it properly, protocol extensions increase flexibility of your code. They works like a base classes, but with several advantages, that I described in the article. "Like anything that implements a protocol must confront to it making it closely coupled with that protocol, right?". No, they are not coupled with protocol, they conform to it (like inheritance). Any View controllers in your code are inherited from UIViewController base class, but it is not a coupling.
Dusan
Cool, great post! So protocol is just an abstraction of the interface :) I don't think it changes anything but I would personally totally put inheritance into very closely coupled code, and as the project grows I can totally see huge class hierarchies becoming unmaintainable. Can't wait to try swift in the future!
comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant Technologies
About the author
Alexander Gaidukov
Objective-C Developer
Alexander has over 9 years experience in developing applications and over 5 years with the iOS platform (iPhone and iPad). He has worked in teams of various sizes from small teams to very large groups. He also has experience working freelance on and off over the past 5 years. Alexander is a self-motivated and communicative professional who can work well independently and with a team.