Doesn't Protocol Oriented programming bring the same old issue of code duplication which inheritance primarily solved?

Question

Overview

I was trying to get my head around Swift\'s Protocol Oriented Programming paradigm. As per Apple\'s WWDC 2015 video https://developer.apple.com

Answer 1

(Very late to the party though. I came across this thread after having some beginning level knowledge about the POP)

Suppose, you are going to write some bird classes. Like:

• Flappy Bird
• Swift Bird
• Stork Bird
• Penguin Bird
• Ostrich Bird
• Eagle Bird

Some of them can fly and some can't. In OOP, you have various options to design. Most commons are:

1. You design a base class Fly, then by subclassing it you design Bird and then you use this Bird as the base class for all the bird classes in the question. Override the flying/not flying behavior for each bird type.

2. Or, you can have a base class Fly, you subclass it for FlyingBird. And then you have another base class NotFlyingBird. After that you subclass these two classes according to your need.

The above approaches work. But you see for the case 1:

Every time you create a new bird, you are also inheriting some capabilities that you don't need maybe.

And in the case 2:

You create two separate base class of your need! What if you need to write something common for FlyingBird and NotFlyingBird? You will probably end up changing your mind to use the approach 1 here.

And lastly, every time you change your mind in later time you end up inheriting from different base class. Or just adding all of the behaviors in a god-like class

---

Now see, how you can design this with POP approach.

protocol Flyable { ... }
protocol Bird { ... }

struct Flappy: Bird, Flyable { ... } //it's a bird & can fly
struct SwiftBird: Bird, Flyable { ... } //it's a bird & can fly
struct Stork: Bird, Flyable { ... } //it's a bird & can fly
struct Penguin: Bird { ... } //it's a bird but can't fly
struct Ostrich: Bird { ... } //it's a bird but can't fly
struct Eagle: Bird, Flyable { ... } //it's a bird & can fly

See! how POP really shine? So, it’s a good thing you didn’t take the inheritance approach, and make all birds flyable after all!

With protocol oriented programming you just don't magically inherit everything from the Super class. You are enforcing to provide their own. With this approach, you are adding behaviors. So you can keep out the burden off your shoulder.

If you need anything very new, you just add to them and not enforcing every other one to have that very new thing without their actual consent.

This Introducing Protocol-Oriented Programming in Swift 3 article from RayWenderlich may even lighten up you a bit more.

You might even have a look at this answer from a different thread.

---

Let's answer your trailing questions in short:

1. Is protocol programming really an alternative to OOP? -> Not always. But it has it's shine.
2. Is protocol really a replacement to inheritance? -> Again, No. But!! If you are designing from the scratch it's worth it to give this idea a shot.