Protocol vs Inheritance

Well It’s a good question to ask, when to use protocol and when to use Inheritance. We all are familiar with Swift and we know, Swift is a Protocol Orient Programming. However Swift also supports OOPS concept.

We know about Inheritance, where a class can inherit its behaviour and state form base class.

Let’s take an example of a team, where we have Project Manager, Developer, Tester. If we think about this Team Model, they have many things in common. Like, they must have a name, employee id, designation.

class Employee {
    var name: String
    var employeeID: String
    var designation: String
    init(name: String, employeeID: String, designation: String) {
        self.name = name
        self.employeeID = employeeID
        self.designation = designation
    }
}
class PM: Employee {
}
class Developer: Employee {
}
class Tester: Employee {
}

This is an example of inheritance. Where we are not going to write any duplicate code for PM (Project Manager), Developer and Tester. We can say that, this model is good.

If we put below methods to Employee class, these methods will be available to all PM, Developer and Tester class.

func sendDevelopingReport() {
    print("Developer Will send report to Manager")
}
func getDevelopingReport() {
    print("Manager will get development report from Developer")
}
func sendTestingReport() {
    print("Tester will send testing report to Manager")
}
func getTestingReport() {
    print("Manager will get testing report from Tester")
}

However, sendDevelopingReport and sendTestingReport in PM class is irrelevant. PM is not going to send developing report and testing report. Developer and Tester class should use sendDevelopingReport and sendTestingReport simultaneously. PM class should use getDevelopingReport and getTestingReport. This is not a good model. Because if we are using this model in another model, and there we create an instance of Developer class, we will get confuse, how we are going to use getDevelopingReport and from whom we will get this report.

Well, Protocol is the best solution to avoid this confusion. I believe, we all know about protocol.

A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocol can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements. Any type that satisfies the requirements of a protocol is said to conform to that protocol.

In SOLID principle, Interface segregation principle states that,

A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

So, the above model that we created is going against SOLID principle. Now let’s modify our model by creating Manageable, Developable and Testable protocols.

protocol Manageable {
    func getDevelopingReport()
    func getTestingReport()
}
protocol Developable {
    func sendDevelopingReport()
}
protocol Testable {
    func sendTestingReport()
}
// Implementing protcols 
class PM: Employee, Manageable {
    override init(name: String, employeeID: String, designation: String) {
    super.init(name: name, employeeID: employeeID, designation:
         designation)
    }
    func getDevelopingReport() {
        print("Manager will get development report from Developer")
    }
    func getTestingReport() {
        print("Manager will get testing report from Tester")
    }
}
class Developer: Employee, Developable {
    override init(name: String, employeeID: String, designation: String) {
        super.init(name: name, employeeID: employeeID, designation: designation)
    }
    func sendDevelopingReport() {
        print("Tester will send testing report to Manager")
    }
}
class Tester: Employee, Testable {
    override init(name: String, employeeID: String, designation: String) {
        super.init(name: name, employeeID: employeeID, designation: designation)
    }
    func sendTestingReport() {
        print("Tester will send testing report to Manager")
    }
}

In the above code, Manager class has only getDevelopingReport and getTestingReport methods. Similarly, Developer class has sendDevelopingReport and Tester class has sendTestingReport methods.

In this model, we are not forcing Manager class to use Developable and Testable protocol’s method and Developer class is not using Manageable and Testable protocol’s method and Tester class is not using Manageable and Developable protocol’s method.

Conclusion

Inheritance and Protocol, both are required while designing a model. Protocol is powerful, when you want to avoid a rigid hierarchy of model. For more knowledge check out Protocol in Swift.org.