In this article by Jon Hoffman, the author of Mastering Swift 2, we’ll see how protocols are used as a type, how we can implement polymorphism in Swift using protocols, how to use protocol extensions, and why we would want to use protocol extensions.
(For more resources related to this topic, see here.)
While watching the presentations from WWDC 2015 about protocol extensions and protocol-oriented programming, I will admit that I was very skeptical. I have worked with object-oriented programming for so long that I was unsure if this new programming paradigm would solve all of the problems that Apple was claiming it would. Since I am not one to let my skepticism get in the way of trying something new, I set up a new project that mirrored the one I was currently working on, but wrote the code using Apple’s recommendations for protocol-oriented programming and used protocol extensions extensively in the code. I can honestly say that I was amazed with how much cleaner the new project was compared to the original one. I believe that protocol extensions is going to be one of those defining features that set one programming language apart from the rest. I also believe that many major languages will soon have similar features.
Protocol extensions are the backbone for Apple’s new protocol-oriented programming paradigm and is arguably one of the most important additions to the Swift programming language. With protocol extensions, we are able to provide method and property implementations to any type that conforms to a protocol. To really understand how useful protocols and protocol extensions are, let’s get a better understanding of protocols.
While classes, structs, and enums can all conform to protocols in Swift, for this article, we will be focusing on classes and structs. Enums are used when we need to represent a finite number of cases and while there are valid use cases where we would have an enum conform to a protocol, they are very rare in my experience. Just remember that anywhere that we refer to a class or struct, we can also use an enum.
Let’s begin exploring protocols by seeing how they are full-fledged types in Swift.
Protocol as a type
Even though no functionality is implemented in a protocol, they are still considered a full-fledged type in the Swift programming language and can be used like any other type. What this means is we can use protocols as a parameter type or a return type in a function. We can also use them as the type for variables, constants, and collections. Let’s take a look at some examples. For these few examples, we will use the PersonProtocol protocol:
protocol PersonProtocol {
var firstName: String {get set}
var lastName: String {get set}
var birthDate: NSDate {get set}
var profession: String {get}
init (firstName: String, lastName: String, birthDate: NSDate)
}
In this first example, we will see how we would use protocols as a parameter type or return type in functions, methods, or initializers:
func updatePerson(person: PersonProtocol) -> PersonProtocol {
// Code to update person goes here
return person
}
In this example, the updatePerson() function accepts one parameter of the PersonProtocol protocol type and then returns a value of the PersonProtocol protocol type. Now let’s see how we can use protocols as a type for constants, variables, or properties:
var myPerson: PersonProtocolIn this example, we create a variable of the PersonProtocol protocol type that is named myPerson. We can also use protocols as the item type to store in collection such as arrays, dictionaries, or sets:
var people: [PersonProtocol] = []In this final example, we create an array of PersonProtocol protocol types. As we can see from these three examples, even though the PersonProtocol protocol does not implement any functionality, we can still use protocols when we need to specify a type. We cannot, however, create an instance of a protocol. This is because no functionality is implemented in a protocol. As an example, if we tried to create an instance of the PersonProtocol protocol, we would be receiving the error: protocol type ‘PersonProtocol’ cannot be instantiated error, as shown in the following example:
var test = PersonProtocol(firstName: "Jon", lastName: "Hoffman",
birthDate: bDateProgrammer)We can use the instance of any class or struct that conforms to our protocol anywhere that the protocol type is required. As an example, if we defined a variable to be of the PersonProtocol protocol type, we could then populate that variable with any class or struct that conforms to the PersonProtocol protocol. For this example, let’s assume that we have two types named SwiftProgrammer and FootballPlayer, which conform to the PersonProtocol protocol:
var myPerson: PersonProtocol
myPerson = SwiftProgrammer(firstName: "Jon", lastName: "Hoffman",
birthDate: bDateProgrammer)
print("(myPerson.firstName) (myPerson.lastName)")
myPerson = FootballPlayer(firstName: "Dan", lastName: "Marino",
birthDate: bDatePlayer)
print("(myPerson.firstName) (myPerson.lastName)")In this example, we start off by creating the myPerson variable of the PersonProtocol protocol type. We then set the variable with an instance of the SwiftProgrammer type and print out the first and last names. Next, we set the myPerson variable to an instance of the FootballPlayer type and print out the first and last names again. One thing to note is that Swift does not care if the instance is a class or struct. It only matters that the type conforms to the PersonProtocol protocol type. Therefore, if our SwiftProgrammer type was a struct and the FootballPlayer type was a class, our previous example would be perfectly valid.
As we saw earlier, we can use our PersonProtocol protocol as the type for an array. This means that we can populate the array with instances of any type that conforms to the PersonProtocol protocol. Once again, it does not matter if the type is a class or a struct as long as it conforms to the PersonProtocol protocol. Here is an example of this:
var programmer = SwiftProgrammer(firstName: "Jon", lastName:
"Hoffman", birthDate: bDateProgrammer)
var player = FootballPlayer(firstName: "Dan", lastName: "Marino",
birthDate: bDatePlayer)
var people: [PersonProtocol] = []
people.append(programmer)
people.append(player)In this example, we create an instance of the SwiftProgrammer type and an instance of the FootballPlayer type. We then add both instances to the people array.
Polymorphism with protocols
What we were seeing in the previous examples is a form of Polymorphism. The word polymorphism comes from the Greek roots Poly, meaning many and morphe, meaning form. In programming languages, polymorphism is a single interface to multiple types (many forms). In the previous example, the single interface was the PersonProtocol protocol and the multiple types were any type that conforms to that protocol.
Polymorphism gives us the ability to interact with multiple types in a uniform manner. To illustrate this, we can extend our previous example where we created an array of the PersonProtocol types and loop through the array. We can then access each item in the array using the properties and methods define in the PersonProtocol protocol, regardless of the actual type. Let’s see an example of this:
for person in people {
print("(person.firstName) (person.lastName):
(person.profession)")
}If we ran this example, the output would look similar to this:
Jon Hoffman: Swift Programmer
Dan Marino: Football PlayerWe have mentioned a few times in this article that when we define the type of a variable, constant, collection type, and so on to be a protocol type, we can then use the instance of any type that conforms to that protocol. This is a very important concept to understand and it is what makes protocols and protocol extensions so powerful.
When we use a protocol to access instances, as shown in the previous example, we are limited to using only properties and methods that are defined in the protocol. If we want to use properties or methods that are specific to the individual types, we would need to cast the instance to that type.
Type casting with protocols
Type casting is a way to check the type of the instance and/or to treat the instance as a specified type. In Swift, we use the is keyword to check if an instance is a specific type and the as keyword to treat the instance as a specific type.
To start with, let’s see how we would check the instance type using the is keyword. The following example shows how would we do this:
for person in people {
if person is SwiftProgrammer {
print("(person.firstName) is a Swift Programmer")
}
}In this example, we use the if conditional statement to check whether each element in the people array is an instance of the SwiftProgrammer type and if so, we print that the person is a Swift programmer to the console. While this is a good method to check whether we have an instance of a specific class or struct, it is not very efficient if we wanted to check for multiple types. It is a lot more efficient to use the switch statement, as shown in the next example, if we want to check for multiple types:
for person in people {
switch (person) {
case is SwiftProgrammer:
print("(person.firstName) is a Swift Programmer")
case is FootballPlayer:
print("(person.firstName) is a Football Player")
default:
print("(person.firstName) is an unknown type")
}
}In the previous example, we showed how to use the switch statement to check the instance type for each element of the array. To do this check, we use the is keyword in each of the case statements in an attempt to match the instance type.
We can also use the where statement with the is keyword to filter the array, as shown in the following example:
for person in people where person is SwiftProgrammer {
print("(person.firstName) is a Swift Programmer")
}Now let’s look at how we can cast an instance of a class or struct to a specific type. To do this, we can use the as keyword. Since the cast can fail if the instance is not of the specified type, the as keyword comes in two forms: as? and as!. With the as? form, if the casting fails, it returns a nil, and with the as! form, if the casting fails, we get a runtime error; therefore, it is recommended to use the as? form unless we are absolutely sure of the instance type or we perform a check of the instance type prior to doing the cast.
Let’s look at how we would use the as? keyword to cast an instance of a class or struct to a specified type:
for person in people {
if let p = person as? SwiftProgrammer {
print("(person.firstName) is a Swift Programmer")
}
}Since the as? keyword returns an optional, we can use optional binding to perform the cast, as shown in this example. If we are sure of the instance type, we can use the as! keyword. The following example shows how to use the as! keyword when we filter the results of the array to only return instances of the SwiftProgrammer type:
for person in people where person is SwiftProgrammer {
let p = person as! SwiftProgrammer
}Now that we have covered the basics of protocols, that is, how polymorphism works and type casting, let’s dive into one of the most exciting new features of Swift protocol extensions.
Protocol extensions
Protocol extensions allow us to extend a protocol to provide method and property implementations to conforming types. It also allows us to provide common implementations to all the confirming types eliminating the need to provide an implementation in each individual type or the need to create a class hierarchy. While protocol extensions may not seem too exciting, once you see how powerful they really are, they will transform the way you think about and write code.
Let’s begin by looking at how we would use protocol extension with a very simplistic example. We will start off by defining a protocol called DogProtocol as follows:
protocol DogProtocol {
var name: String {get set}
var color: String {get set}
}With this protocol, we are saying that any type that conforms to the DogProtocol protocol, must have the two properties of the String type, namely, name and color. Now let’s define the three types that conform to this protocol. We will name these types JackRussel, WhiteLab, and Mutt as follows:
struct JackRussel: DogProtocol {
var name: String
var color: String
}
class WhiteLab: DogProtocol {
var name: String
var color: String
init(name: String, color: String) {
self.name = name
self.color = color
}
}
struct Mutt: DogProtocol {
var name: String
var color: String
}We purposely created the JackRussel and Mutt types as structs and the WhiteLab type as a class to show the differences between how the two types are set up and to illustrate how they are treated in the same way when it comes to protocols and protocol extensions. The biggest difference that we can see in this example is the struct types provide a default initiator, but in the class, we must provide the initiator to populate the properties.
Now let’s say that we want to provide a method named speak to each type that conforms to the DogProtocol protocol. Prior to protocol extensions, we would start off by adding the method definition to the protocol, as shown in the following code:
protocol DogProtocol {
var name: String {get set}
var color: String {get set}
func speak() -> String
}Once the method is defined in the protocol, we would then need to provide an implementation of the method in every type that conform to the protocol. Depending on the number of types that conformed to this protocol, this could take a bit of time to implement. The following code sample shows how we might implement this method:
struct JackRussel: DogProtocol {
var name: String
var color: String
func speak() -> String {
return "Woof Woof"
}
}
class WhiteLab: DogProtocol {
var name: String
var color: String
init(name: String, color: String) {
self.name = name
self.color = color
}
func speak() -> String {
return "Woof Woof"
}
}
struct Mutt: DogProtocol {
var name: String
var color: String
func speak() -> String {
return "Woof Woof"
}
}While this method works, it is not very efficient because anytime we update the protocol, we would need to update all the types that conform to it and we may be duplicating a lot of code, as shown in this example. Another concern is, if we need to change the default behavior of the speak() method, we would have to go in each implementation and change the speak() method. This is where protocol extensions come in.
With protocol extensions, we could take the speak() method definition out of the protocol itself and define it with the default behavior, in protocol extension. The following code shows how we would define the protocol and the protocol extension:
protocol DogProtocol {
var name: String {get set}
var color: String {get set}
}
extension DogProtocol {
func speak() -> String {
return "Woof Woof"
}
}We begin by defining DogProtocol with the original two properties. We then create a protocol extension that extends DogProtocol and contains the default implementation of the speak() method. With this code, there is no need to provide an implementation of the speak() method in each of the types that conform to DogProtocol because they automatically receive the implementation as part of the protocol. Let’s see how this works by setting our three types that conform to DogProtocol back to their original implementations and they should receive the speak() method from the protocol extension:
struct JackRussel: DogProtocol {
var name: String
var color: String
}
class WhiteLab: DogProtocol {
var name: String
var color: String
init(name: String, color: String) {
self.name = name
self.color = color
}
}
struct Mutt: DogProtocol {
var name: String
var color: String
}We can now use each of the types as shown in the following code:
let dash = JackRussel(name: "Dash", color: "Brown and White")
let lily = WhiteLab(name: "Lily", color: "White")
let buddy = Mutt(name: "Buddy", color: "Brown")
let dSpeak = dash.speak() // returns "woof woof"
let lSpeak = lily.speak() // returns "woof woof"
let bSpeak = buddy.speak() // returns "woof woof"
As we can see in this example, by adding the speak() method to the DogProtocol protocol extension, we are automatically adding that method to all the types that conform to DogProtocol. The speak() method in the DogProtocol protocol extension can be considered a default implementation of the speak() method because we are able to override it in the type implementations. As an example, we could override the speak() method in the Mutt struct, as shown in the following code:
struct Mutt: DogProtocol {
var name: String
var color: String
func speak() -> String {
return "I am hungry"
}
}
When we call the speak() method for an instance of the Mutt type, it will return the string, “I am hungry”.
Now that we have seen how we would use protocols and protocol extensions, let’s look at a more real-world example. In numerous apps, across multiple platforms (iOS, Android, and Windows), I have had the requirement to validate user input as it is entered. This validation can be done very easily with regular expressions; however, we do not want various regular expressions littered through out our code. It is very easy to solve this problem by creating different classes or structs that contains the validation code; however, we would have to organize these classes to make them easy to use and maintain. Prior to protocol extensions in Swift, I would use protocols to define the validation requirements and then create a struct that would conform to the protocol for each validation that I needed. Let’s take a look at this preprotocol extension method.
A regular expression is a sequence of characters that define a particular pattern. This pattern can then be used to search a string to see whether the string matches the pattern or contains a match of the pattern. Most major programming languages contain a regular expression parser, and if you are not familiar with regular expressions, it may be worth to learn more about them.
The following code shows the TextValidationProtocol protocol that defines the requirements for any type that we want to use for text validation:
protocol TextValidationProtocol {
var regExMatchingString: String {get}
var regExFindMatchString: String {get}
var validationMessage: String {get}
func validateString(str: String) -> Bool
func getMatchingString(str: String) -> String?
}
In this protocol, we define three properties and two methods that any type that conforms to TextValidationProtocol must implement. The three properties are:
- regExMatchingString: This is a regular expression string used to verify that the input string contains only valid characters.
- regExFindMatchString: This is a regular expression string used to retrieve a new string from the input string that contains only valid characters. This regular expression is generally used when we need to validate the input real time, as the user enters information, because it will find the longest matching prefix of the input string.
- validationMessage: This is the error message to display if the input string contains non-valid characters.
The two methods for this protocol are as follows:
- validateString: This method will return true if the input string contains only valid characters. The regExMatchingString property will be used in this method to perform the match.
- getMatchingString: This method will return a new string that contains only valid characters. This method is generally used when we need to validate the input real time as the user enters information because it will find the longest matching prefix of the input string. We will use the regExFindMatchString property in this method to retrieve the new string.
Now let’s see how we would create a struct that conforms to this protocol. The following struct would be used to verify that the input string contains only alpha characters:
struct AlphaValidation1: TextValidationProtocol {
static let sharedInstance = AlphaValidation1()
private init(){}
let regExFindMatchString = "^[a-zA-Z]{0,10}"
let validationMessage = "Can only contain Alpha characters"
var regExMatchingString: String { get {
return regExFindMatchString + "$"
}
}
func validateString(str: String) -> Bool {
if let _ = str.rangeOfString(regExMatchingString, options:
.RegularExpressionSearch) {
return true
} else {
return false
}
}
func getMatchingString(str: String) -> String? {
if let newMatch = str.rangeOfString(regExFindMatchString,
options: .RegularExpressionSearch) {
return str.substringWithRange(newMatch)
} else {
return nil
}
}
}
In this implementation, the regExFindMatchString and validationMessage properties are stored properties, and the regExMatchingString property is a computed property. We also implement the validateString() and getMatchingString() methods within the struct.
Normally, we would have several different types that conform to TextValidationProtocol where each one would validate a different type of input. As we can see from the AlphaValidation1 struct, there is a bit of code involved with each validation type. A lot of the code would also be duplicated in each type. The code for both methods (validateString() and getMatchingString()) and the regExMatchingString property would be duplicated in every validation class. This is not ideal, but if we wanted to avoid creating a class hierarchy with a super class that contains the duplicate code (I personally prefer using value types over classes), we would have no other choice. Now let’s see how we would implement this using protocol extensions.
With protocol extensions we need to think about the code a little differently. The big difference is, we do not need, nor want to define everything in the protocol. With standard protocols or when we use class hierarchy, all the methods and properties that you would want to access using the generic superclass or protocol would have to be defined within the superclass or protocol. With protocol extensions, it is preferred for us not to define a property or method in the protocol if we are going to be defining it within the protocol extension. Therefore, when we rewrite our text validation types with protocol extensions, TextValidationProtocol would be greatly simplified to look similar to this:
protocol TextValidationProtocol {
var regExFindMatchString: String {get}
var validationMessage: String {get}
}
In original TextValidationProtocol, we defined three properties and two methods. As we can see in this new protocol, we are only defining two properties. Now that we have our TextValidationProtocol defined, let’s create the protocol extension for it:
extension TextValidationProtocol {
var regExMatchingString: String { get {
return regExFindMatchString + "$"
}
}
func validateString(str: String) -> Bool {
if let _ = str.rangeOfString(regExMatchingString, options:
.RegularExpressionSearch) {
return true
} else {
return false
}
}
func getMatchingString(str: String) -> String? {
if let newMatch = str.rangeOfString(regExFindMatchString,
options: .RegularExpressionSearch) {
return str.substringWithRange(newMatch)
} else {
return nil
}
}
}
In the TextValidationProtocol protocol extension, we define the two methods and the third property that were defined in original TextValidationProtocol, but were not defined in the new one. Now that we have created our protocol and protocol extension, we are able to define our text validation types. In the following code, we define three structs that we will use to validate text when a users types it in:
struct AlphaValidation: TextValidationProtocol {
static let sharedInstance = AlphaValidation()
private init(){}
let regExFindMatchString = "^[a-zA-Z]{0,10}"
let validationMessage = "Can only contain Alpha characters"
}
struct AlphaNumericValidation: TextValidationProtocol {
static let sharedInstance = AlphaNumericValidation()
private init(){}
let regExFindMatchString = "^[a-zA-Z0-9]{0,15}"
let validationMessage = "Can only contain Alpha Numeric
characters"
}
struct DisplayNameValidation: TextValidationProtocol {
static let sharedInstance = DisplayNameValidation()
private init(){}
let regExFindMatchString = "^[\s?[a-zA-Z0-9\-_\s]]{0,15}"
let validationMessage = "Display Name can contain only contain
Alphanumeric Characters"
}
In each one of the text validation structs, we create a static constant and a private initiator so that we can use the struct as a singleton.
After we define the singleton pattern, all we do in each type is set the values for the regExFindMatchString and validationMessage properties. Now we have not duplicated the code virtually because even if we could, we would not want to define the singleton code in the protocol extension because we would not want to force that pattern on all the conforming types.
To use the text validation classes, we would want to create a dictionary object that would map the UITextField objects to the validation class to use it like this:
var validators = [UITextField: TextValidationProtocol]()We could then populate the validators dictionary as shown here:
validators[alphaTextField] = AlphaValidation.sharedInstance
validators[alphaNumericTextField] =
AlphaNumericValidation.sharedInstance
validators[displayNameTextField] =
DisplayNameValidation.sharedInstance
We can now set the EditingChanged event of the text fields to a single method named keyPressed(). To set the edition changed event for each field, we would add the following code to the viewDidLoad() method of our view controller:
alphaTextField.addTarget(self, action:Selector("keyPressed:"),
forControlEvents: UIControlEvents.EditingChanged)
alphaNumericTextField.addTarget(self, action:
Selector("keyPressed:"), forControlEvents:
UIControlEvents.EditingChanged)
displayNameTextField.addTarget(self, action:
Selector("keyPressed:"), forControlEvents:
UIControlEvents.EditingChanged)
Now lets create the keyPressed() method that each text field calls when a user types a character into the field:
@IBAction func keyPressed(textField: UITextField) {
if let validator = validators[textField] where
!validator.validateString(textField.text!) {
textField.text =
validator.getMatchingString(textField.text!)
messageLabel?.text = validator.validationMessage
}
}In this method, we use the if let validator = validators[textField] statement to retrieve the validator for the particular text field and then we use the where !validator.validateString(textField.text!) statement to validate the string that the user has entered. If the string fails validation, we use the getMatchingString() method to update the text in the text field by removing all the characters from the input string, starting with the first invalid character and then displaying the error message from the text validation class. If the string passes validation, the text in the text field is left unchanged.
Summary
In this article, we saw that protocols are treated as full-fledged types by Swift. We also saw how polymorphism can be implemented in Swift with protocols. We concluded this article with an in-depth look at protocol extensions and saw how we would use them in Swift.
Protocols and protocol extensions are the backbone of Apple’s new protocol-oriented programming paradigm. This new model for programming has the potential to change the way we write and think about code. While we did not specifically cover protocol-oriented programming in this article, understanding the topics in this article gives us the solid understanding of protocols and protocol extensions needed to learn about this new programming model.
Resources for Article:
Further resources on this subject:
- Using OpenStack Swift [Article]
- Dragging a CCNode in Cocos2D-Swift [Article]
- Installing OpenStack Swift [Article]