Introduction

If we want to write clean code, we should split our interface in little protocols with cohesive properties and methods. The problem of having several protocols is that we often need to use some of them together. For example, we may want to declare a variable of a type which combines some protocols together. The solution is using protocol composition.

In this article, we’re going to see two approaches to achieve protocol composition in Swift.

Contents

Getting Started

It has a method to return the content of a file and a method to write a String inside a file.

The problem of this protocol is that it breaks the Interface Segregation Principle. FileHandlerType is a fat interface, it contains methods not cohesive. If we want to follow the SOLID principles, we should get rid of FileHandlerType and split it in two protocols like these:

1

2

3

4

5

6

7

8

protocolFileHandlerReadable{

funcread()->String

}

protocolFileHandlerWritable{

funcwrite(_value:String)

}

This refactoring brings us a problem. Before the refactoring, we could declare a variable of type FileHandlerType and use its methods read and write:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

structFileHandler: FileHandlerType{

funcread()->String{

return""

}

funcwrite(_value:String){

}

}

lethandler:FileHandlerType=FileHandler()

handler.read()

handler.write("Hello World")

After the refactoring, we no longer have FileHandlerType. We have two protocols. How can we declare a variable of a type which combines FileHandlerReadable and FileHandlerWritable? Protocol composition can save our day.

In the next sections, we’re going to see two approaches to manage protocol composition. A basic one—which is a generic object-oriented programming approach—and a more “Swifty” one.

Basic Approach

This approach is very generic. We can use it also in other languages like Java.

We can create an empty protocol FileHandlerType which extends both FileHandlerReadable and FileHandlerWritable:

1

2

3

protocolFileHandlerType:FileHandlerReadable,FileHandlerWritable{

}

In this way, FileHandlerType inherits the methods of both FileHandlerReadable and FileHandlerWritable. At this point, we can finally declare a variable of type FileHandlerType:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

structFileHandler: FileHandlerType{

funcread()->String{

return""

}

funcwrite(_value:String){

}

}

lethandler:FileHandlerType=FileHandler()

handler.read()

handler.write("Hello World")

Note:

We may have the concern that this approach is similar to having only a single protocol FileHandlerType like this:

1

2

3

4

5

protocolFileHandlerType{

funcread()->String

funcwrite(_value:String)

}

The difference is that, with this approach, we don’t break Interface Segregation Principle. We still have an interface split in two protocols FileHandlerReadable and FileHandlerWritable.

Swifty Approach

If you don’t like Basic Approach, there are good news for you. Swift provides a more “Swifty” way to achieve protocol composition.

If we want to combine two or more protocols together, we can use the operator &. We can combine FileHandlerReadable and FileHandlerWritable like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

structFileHandler:FileHandlerReadable,FileHandlerWritable{

funcread()->String{

return""

}

funcwrite(_value:String){

}

}

lethandler:FileHandlerReadable&FileHandlerWritable=FileHandler()

handler.read()

handler.write("Hello World")

This approach has just a downside. If we combine several protocols, we start having a messy code:

1

2

letvariable:ProtocolA&ProtocolB&ProtocolC&ProtocolD&ProtocolE

For this reason, I would suggest you to use a typealias to clean the declaration of our variables:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

typealiasFileHandlerType=FileHandlerReadable&FileHandlerWritable

structFileHandler: FileHandlerType{

funcread()->String{

return""

}

funcwrite(_value:String){

}

}

lethandler:FileHandlerType=FileHandler()

handler.read()

handler.write("Hello World")

Note:

You can check a real usage of this approach in the file StorageContext.swift of the open source library StorageKit.

Conclusion

I usually prefer using the Swifty Approach. In this way, I can avoid creating a new empty protocol only to combine different protocols together. Then, I always use a typealias to clean the concatenation of protocols.

Share this:

Related

Marco Santarossa

Hi there, I'm Marco and I'm an Italian developer. I moved to London in 2016 to work at Sky as iOS developer.
I've been an iOS Developer since 2011 and I sometimes write embarrassing PHP/JS code.
I'm keen to learn new things and I spend most of my spare time learning as self-taught.
When I don't develop, I like watching MMA fights and cooking Italian food.