Introduction 2
Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as text.
Comparing Protocols to Inheritance
If you really squint, the two approaches are fairly similar. They both allow you to define a blueprint for your types, such as properties and functions. However, the similarities end there. Protocols define the API for types to make it possible to interact with them without caring about the type. Inheritance defines the behavior of types as well as the API.
With inheritance, it’s possible to create an instance of the superclass that doesn’t make any sense. For example, you could write:
let vehicle = VehicleType()
vehicle.move(direction: .forward, duration: 15, speed: 30)
print(vehicle.showDetails())
In this example, you create an instance of VehicleType. But what does that mean? It doesn’t make sense to have a generic vehicle you can instantiate and pass around as a concrete type. Protocols make much more sense in this case.
On the other hand, with protocols, every implementor has to implement all the variables and all the functions, even if they’re the same. This can lead to duplicated code. There are a couple of other disadvantages to superclasses:
- You can only inherit from one superclass. If you want to inherit behavior from two unrelated superclasses — you can’t. It isn’t possible. With protocols, you can conform to as many as you like.
- You have no control over how your superclasses behave. They may change the values of properties that you rely on or perform additional logic that conflicts with your own. Remember, protocols only define the API of the types — the implementation is entirely up to you.
These disadvantages are why Swift favors protocols over inheritance (such as in SwiftUI).
Protocols are very useful for testing your code in this sense. You can define a protocol to retrieve your users from an API. In your tests, you can use a different implementation that returns hardcoded users. With inheritance, you’d need to be careful to ensure that your test subclass doesn’t make network requests, for instance.
Note: In Kotlin, you can create abstract classes. These classes cannot be instantiated; you can only use them by subclassing them. In Swift, you can use protocol extensions to provide a default implementation for a function. You’ll see this in a later lesson.
Protocol-Orientated Programming
Now that you understand the basics of protocols, you can start to learn about how to use them in your code. Protocol-Orientated Programming is a technique where you move different parts of your code to be called via a protocol. This could be a third-party dependency, a database, an API or even different modules for your app.