Introduction to Protocol Oriented Programming in Swift
OOP is okay, but could’ve been better | Update on May 14th, 2017
Introduction
This tutorial is also written for those who have no clear answer to the fundamental difference between Classes and Structs. We all know there is no inheritance in Structs, but why?
If you don’t know the answer, take a couple seconds to read the code below. Again, please excuse me for its format. I tried to have it as concise as possible.
class HumanClass {
var name: String
init(name: String) {
self.name = name }
}var classyHuman = HumanClass(name: "Bob")
classyHuman.name // "Bob"var newClassyHuman = classyHuman // Created a "copied" objectnewClassyHuman.name = "Bobby"
classyHuman.name // "Bobby"
When I changed the name property of newClassyHuman to “Bobby”, the name property of the original object, classyHuman, also changed to “Bobby”.
Now, let’s take a look at Structs
struct HumanStruct {
var name: String
}var humanStruct = HumanStruct(name: "Bob" )
var newHumanStruct = humanStruct // Copy and pastenewHumanStruct.name = "Bobby"
humanStruct.name // "Bob"
Do you see the difference? The change to the name property of the copied object hasn’t affected the original humanStruct object.
In Classes, when you make a copy of a variable, both variables are referring to the same object in memory. A change to one of the variables will change the other (Reference Type). In Structs, however, you simply copy and paste variables by creating a separate object (Value Type)
If you didn’t get it, try to re-read the previous paragraph. If not, you can watch the video I made.
Bye OOP
You might be wondering why I talk about all these seemingly unrelated topics to Protocol Oriented Programming. But, before I talk about certain benefits of using POP over OOP, you just had to understand the difference between Reference type and Value type.
There are certainly benefits of using OOP, but the opposites as well.
- When you subclass, you have to inherit properties and methods which you may not need. Your object becomes unnecessarily bloated.
- When you make a lot of super classes, it becomes extremely hard to navigate between each class and fix bugs/edit.
- Since objects are referencing to the same place in memory, if you make a copy and create a small change its property, it can f up the rest. (Mutability due to reference)
By the way, take a look at how the UIKit framework is written in OOP
If you were to work at Apple as a software engineer for the first time, can you work with this code? I mean we developers have a hard time using it at the surface level.
One said OOP is just a modulized way to write spaghetti code. If you want to find more bad things about OOP, here are rant 1, rant 2, rant 3, rant 4.
Welcome POP
You might have guessed it right, unlike Classes, the fundamental of Protocol Oriented Programming is Value Type. No more referencing. Unlike the pyramid structure you see above, POP encourages flat and non-nested code.
Just to scare you a little, I’m going to pull Apple’s definition.
“A protocol defines a blueprint of methods, properties… The protocol can then be adopted by a class, structure, or enumeration” — Apple
The only thing you need to remember right now is the word, “blueprint”.
A protocol is like a basketball coach. He tells his players what to do, but he doesn’t know how to dunk a basketball.
Getting Real with POP
Firstly, let’s make a blueprint for a human.
protocol Human {
var name: String { get set }
var race: String { get set }
func sayHi() }As you can see, there is no actual “dunking” in the protocol. It only tells you that certain things exist. By the way, don’t worry about { get set } for now. It just indicates that you can set the property value to something different and also access (get) the property. Don’t worry about for now unless you are using a computed property.
Let’s make a Korean 🇰🇷 struct that adopts the protocol
struct Korean: Human {
var name: String = "Bob Lee"
var race: String = "Asian"
func sayHi() { print("Hi, I'm \(name)") }
}Once the struct adopts the Human protocol, it has to “conform” to the protocol by implementing all of the properties and methods belong to it. If not, Xcode will scream and of course, 😡 on the left side.
As you can see, you can customize all these properties as long as you meet the blueprint. You can even build a wall.
