With protocol-oriented programming, we should always begin our design with the protocols, but how should we design these protocols? In the object-oriented programming world, we have superclasses that contain all the base requirements for the subclasses. Protocol design is a little bit different.
In the protocol-oriented programming world, we use protocols instead of superclasses, and it is preferable to break the requirements into smaller, more specific protocols rather than having bigger monolithic protocols. In this section, we will look at how we can separate the requirements into smaller, very specific protocols and how to use protocol inheritance and composition. In Chapter 3, Extensions, we will take this a little further and show you how to add functionality to all types that conform to a protocol using protocol extensions.
For the example in this section, we will model something that I enjoy building: robots. There are many types of robots with lots of different sensors, so our model will need the ability to grow and handle all the different options. Since all robots have some form of movement, we will start off by creating a protocol that will define the requirements for this movement. We will name this protocol RobotMovement:
protocol RobotMovement {
func forward(speedPercent: Double)
func reverse(speedPercent: Double)
func left(speedPercent: Double)
func right(speedPercent: Double)
func stop()
}
In this protocol, we define the five methods that all conforming types must implement. These methods will move the robot in the forward, reverse, left, or right directions, as well as stop the robot. This protocol will meet our needs if we only want the robot to travel in two dimensions, but what if we had a flying robot? For this, we would need our robot to also go up and down. To do this, we can use protocol inheritance to create a protocol that adds the additional requirements for traveling in three dimensions:
protocol RobotMovementThreeDimensions: RobotMovement {
func up(speedPercent: Double)
func down(speedPercent: Double)
}
Notice that we use protocol inheritance when we create this protocol to inherit the requirements from the original RobotMovement protocol. This allows us to use polymorphism, as described in the Polymorphism with protocols section of this chapter. This allows us to use instances of types that conform to either of these protocols interchangeably by using the interface provided by the RobotMovement protocol. We can then determine whether the robot can travel in three dimensions by using the is keyword, as described in the Type casting with protocols section of this chapter, to see if the RobotMovement instance conforms to the RobotMovementThreeDimensions protocol or not. Now, we need to add some sensors to our design. We will start off by creating a Sensor protocol that all other sensor types will inherit from. This protocol will contain four requirements. The first two will be read-only properties that define the name and type for the sensor. We will need an initiator that lets us name the sensor and a method that will be used to poll the sensor:
protocol Sensor {
var sensorType: String {get}
var sensorName: String {get set}
init (sensorName: String)
func pollSensor()
}
The sensor type will be used to define the type of sensor and will contain a string, such as DHT22EnvironmentSensor. The sensor name will let us distinguish between multiple sensors and will contain a string, such as RearEnvironmentSensor. The pollSensor() method will be used to perform the default operation by the sensor. Generally, this method is used to read the sensor at regular intervals. Now, we will create requirements for some specific sensor types. The following example shows how to create the requirements for an environment sensor:
protocol EnvironmentSensor: Sensor {
func currentTemperature() -> Double
func currentHumidity() -> Double
}
This protocol inherits the requirements from the Sensor protocol and adds two additional requirements that are unique for environment sensors. The currentTemperature() method will return the last temperature reading from the sensor and the currentHumidity() method will return the last humidity reading from the sensor. The pollSensor() method from the Sensor protocol will be used to read the temperature and humidity at regular intervals. Finally, the pollSensor() method will probably run on a separate thread. Let's go ahead and create a couple more sensor types:
protocol RangeSensor: Sensor {
func setRangeNotification(rangeCentimeter: Double,
rangeNotification: () -> Void)
func currentRange() -> Double
}
protocol DisplaySensor: Sensor {
func displayMessage(message: String)
}
protocol WirelessSensor: Sensor {
func setMessageReceivedNotification(messageNotification:
(String) -> Void)
func messageSend(message: String)
}
You will notice that two of these protocols (RangeSensor and WirelessSensor) define methods that set notifications (setRangeNotification and setMessageReceivedNotifications). These methods accept closures in the method parameters and will be used within the pollSensor() method to notify robot code immediately if something has happened. With the RangeSensor types, the closure will be called if the robot is within a certain distance of an object, and with WirelessSensor types, the closure will be called if a message comes in. There are two advantages that we get from a protocol-oriented design like this one. The first is that each of the protocols only contain the requirements that are needed for their particular sensor type. The second is that we are able to use protocol composition to allow a single type to conform to multiple protocols. As an example, if we had a display sensor that has Wi-Fi built in, we would create a type that conforms to both the DisplaySensor and WirelessSensor protocols. There are many other sensor types; however, this will give us a good start for our robot. Now, let's create a protocol that will define the requirements for the robot types:
protocol Robot {
var name: String {get set}
var robotMovement: RobotMovement {get set}
var sensors: [Sensor] {get}
init (name: String, robotMovement: RobotMovement)
func addSensor(sensor: Sensor)
func pollSensors()
}
This protocol defines three properties, one initiator, and two methods that will need to be implemented by any type that conforms with this protocol. These requirements will give us the basic functionality that's needed for the robots. It may be a bit confusing thinking about all of these protocols, especially if we are used to having only a few superclass types. It usually helps to have a basic diagram of our protocols. The following diagram shows the protocols that we just defined with the protocol hierarchy:
This gives us a basic idea of how to design a protocol hierarchy. You will notice that each of the protocols define the specific requirements for each device type. In Chapter 6, Protocol-Oriented Programming, we will go into greater detail on how to model our requirements with protocols. In this section, we used protocols to define the requirements for the components of a robot. Now it's your turn – take a moment and see if you can create a concrete implementation of the Robot protocol without creating any concrete implementations of the other protocols. The key to understanding protocols is understanding how to use them without the concrete types that conform to them. In the downloadable code for this book, we have a sample class named SixWheelRover that conforms to the Robot protocol that you can compare your implementation to. Now, let's see how Apple uses protocols in the Swift standard library.
