How Swift Developers Should Be Using Protocol Oriented Programming
I remember in 2015 when Protocol Oriented Programming (POP) became a big thing. David Brahams gave a speech at WWDC about it, and it exploded. All of a sudden, I was seeing articles popping up all over the place crying that as Swift developers we must implement POP in our projects.
Okay, that’s fine. I have nothing against POP. I actually things it's great. But the biggest takeaway for most people from that 2015 talk was this. “Always start with a protocol.”
It’s this phrase that I have problems with. This phrase is a rule. And rules are very dangerous in programming.
Why You Shouldn’t Always Start With A Protocol
Protocols serve a great purpose in swift development. They make your code much more modular. The ability to implement multiple protocols allows you to write code that is more like building blocks. You can put multiple blocks together to create an object. It’s very useful.
But do these advantages mean you should “always start with a protocol”? No.
Some functionality makes sense to use with a protocol. But not all functionality.
How do you know what should be put within a protocol and what shouldn’t?
Content within protocols should be content that is reused within your codebase. If you have specific functionality that will be shared amongst multiple objects, then by all means add it to a protocol.
But oftentimes you don’t know beforehand what functionality will be reused. You only know once you begin reusing something.
This is the issue with the “always start with a protocol” rule.
When you do this, you end up having useless protocols all throughout your code. And it’s irritating because it only adds another layer of complexity. It doesn’t solve any fundamental issue.
Avoid Premature Refactoring
Remember, when writing code, you want to eliminate waste. Any unneeded code is waste and introduces unnecessary complexity. Always starting with a protocol is another form of premature optimization, or premature refactoring. This quote from The Art of Computer Programming illustrates why this is dangerous.
“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.” — The Art of Computer Programming by Donald Knuth
The principles behind the usage of protocols are what need to be followed. Modularity and abstraction. When you sit down to start coding, the expansion of the codebase can’t be predicted with complete accuracy.
One of my favorite programming jokes is this.
When I started coding this project, only two people knew what I was doing. Me and God. 6 months later, only God knows.
It’s a joke, but let’s be honest, it’s true. As the codebase expands it goes in directions we never anticipated or expected. It would be great if we knew what our codebase would look like as it expands, but we don’t.
That’s why premature refactoring is dangerous. It’s too easy to make decisions that end up being waste.
Once you understand the principles though, the pros, and the cons of using protocols, you’re well equipped to implement them when necessary. And for emphasis, Protocols are beneficial when a piece of functionality will be reused across multiple objects, and for polymorphism.
After I heard of POP and read a few articles encouraging always starting with a protocol, I tried it. I was starting a new project at the time, and for every object I created, I started with a protocol and then implemented that protocol. After doing this for a while, I realized it was a waste of time.
I had useless protocols all over the place. And it made my code more difficult to understand. I had tons of functionality within these useless protocols, that didn’t make sense to be there. After realizing this, I stopped with the protocol first rule. But even to this day, the code that I wrote using the “protocol first” mindset is overly complex.
And that’s the issue. The goal is always to reduce complexity, not to increase it. So by deciding first to write a protocol, you’re setting yourself up for increased complexity.
The better path is to write concrete objects first. Then when you see that you’re reusing the same functionality, put that functionality in a protocol. By doing things this way, you’re reducing complexity.
Remember, you want to eliminate waste. Your goal should be to write code that is modular, reusable, easy to read, and easy to modify. By premature refactoring, you make it more difficult to do this.
In programming, always be cautious of ‘rules’. Rules are dangerous because they’re inflexible. But as developers, we know our codebase must be adaptable. Trying to conform to rules, weakens the integrity of your code.
POP is a great design concept. But focus on the principles of POP. Don’t create rules. They’ll only make things more difficult for you.
David Brahams in a Podcast episode on Swift By Sundell said this about the “always start with a protocol” statement:
“In my talk I said start with a protocol, but what that meant was, when you need polymorphism, start with a protocol.” — Swift By Sundell Podcast Episode 71, 32:30
He mentions in that Podcast that many people “widely misinterpreted” what he said. And he mentions that…
“Using a protocol for every type is premature generalization and will weigh you down” — Swift By Sundell Podcast Episode 71
So instead of following the rule of “always start with a protocol”. Make it your goal to follow the principles of good software development when implementing Protocol Oriented Programming in your next project.
If you enjoyed this article, then clap for it. Some people don’t know you can clap up to 50 times for the same article. Try it!