How Swift Developers Should Be Using Protocol Oriented Programming

Adebayo Ijidakinro
Dec 2, 2020 · 5 min read
Image for post
Image for post
Photo by Joshua Aragon on Unsplash

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.

Personal Story

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.

Final Thoughts

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!

Swift Development

Learn programming principles that will make you a better swift developer

Adebayo Ijidakinro

Written by

I’m a 10+ year iOS Developer whose worked with 6 startups. This past year I released 6 iOS and web apps. Follow me and learn how to make your Startup a success.

Swift Development

Tutorials are good, but to really become a better swift developer, you must understand the principles behind good architecture. By applying the principles we cover in this publication you will greatly improve your skills and your salary.

Adebayo Ijidakinro

Written by

I’m a 10+ year iOS Developer whose worked with 6 startups. This past year I released 6 iOS and web apps. Follow me and learn how to make your Startup a success.

Swift Development

Tutorials are good, but to really become a better swift developer, you must understand the principles behind good architecture. By applying the principles we cover in this publication you will greatly improve your skills and your salary.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store