Protocol Composition in Swift
Learn about two different approaches to achieve cleaner code through separate cohesive protocols in a Swift application.
Join the DZone community and get the full member experience.
Join For FreeIf we want to write clean code, we should split our interface into 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.
Happy reading!
Getting Started
Let’s consider the following protocol:
protocol FileHandlerType {
func read() -> String
func write(_ value: String)
}
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 that are not cohesive. If we want to follow the SOLID principles, we should get rid of FileHandlerType
and split it into two protocols, like these:
protocol FileHandlerReadable {
func read() -> String
}
protocol FileHandlerWritable {
func write(_ 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
:
struct FileHandler: FileHandlerType {
func read() -> String {
return ""
}
func write(_ value: String) {
}
}
let handler: 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
:
protocol FileHandlerType: 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
:
struct FileHandler: FileHandlerType {
func read() -> String {
return ""
}
func write(_ value: String) {
}
}
let handler: 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:
protocol FileHandlerType {
func read() -> String
func write(_ value: String)
}
The difference is that, with this approach, we don’t break Interface Segregation Principle
. We still have an interface split into two protocols: FileHandlerReadable
and FileHandlerWritable
.
Swifty Approach
If you don’t like Basic Approach
, there is 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:
struct FileHandler: FileHandlerReadable, FileHandlerWritable {
func read() -> String {
return ""
}
func write(_ value: String) {
}
}
let handler: FileHandlerReadable & FileHandlerWritable = FileHandler()
handler.read()
handler.write("Hello World")
This approach has a downside. If we combine several protocols, we start having messy code:
let variable: ProtocolA & ProtocolB & ProtocolC & ProtocolD & ProtocolE
For this reason, I would suggest you use a typealias
to clean the declaration of our variables:
typealias FileHandlerType = FileHandlerReadable & FileHandlerWritable
struct FileHandler: FileHandlerType {
func read() -> String {
return ""
}
func write(_ value: String) {
}
}
let handler: FileHandlerType = FileHandler()
handler.read()
handler.write("Hello World")
Note: You can see a real use 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.
Published at DZone with permission of Marco Santarossa, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments