POP (Protocol-Oriented Programming) – an introduction


A computer is a complex machine made up of several hardware components. Then there is a software layer which efficiently makes use of these components to perform the desired task. These complex machines, many of the times, talk to each other to share the information or to delegate some tasks. All these tasks, at some point in time, deal with the data. The study of this whole ecosystem is widely known as Computer Science. A field of science where the entire focus is to automate a set of tasks. We keep on evolving and improving the existing ecosystem and expect it to do more for us. Every now and then there are commendable improvements in the hardware components. Subsequently, we evolve our software methodologies to fully utilize these hunky components. We invent Operating systems, Kernels, Compilers and gradually improve them to match up with the hardware. To build these powerful pieces of software,  new programming languages evolve, with more features and more capabilities. Every programming language exists for the set of purposes and supports one or more programming paradigms.

One such paradigm is an Object-Oriented Programming (OOP), introduced in the early 1960s and has been widely used since then. This paradigm demanded us to think everything in terms of the objects. OOP has a tremendous capability of solving real-world problems through its core principles – Abstraction, Encapsulation, Inheritance & Polymorphism. Due to this, many programming languages have topped OOP as a prime paradigm. OOP languages like C++, JAVA, Objective-C etc. have supported the core principles through Classing, Subclassing, Method overloading, Abstracting (protocols) etc.

There are some caveats though –

  1. All of these features are solely available to the objects (reference types). Value types like structs and enums cannot utilize these features and hence they remain nothing much but just a data store.
  2. We lose a big advantage of value types being a thread-safe. Resultantly, we relentlessly focus on to tackle thread safety with objects(references).
  3. Also, most of the OOP languages do not support multiple-inheritance due to the complexity of its nature which causes irrelevant subclassing. For example: Suppose, a Singer and an Actor inherit from their parent, Artist, they both get the common functionality implemented by the Artist for free.
Class Diagram for Artist.png

But if the requirement says that some singers could be an actor too then the inheritance tree would look something like –

Class Diagram for Artist - Page 2.png

Here, we are making every Singer an Actor too, which forces irrelevant functionality when a Singer is not an Actor.


There should be a way for these amazing OOP features to be available for value types too so that we do not have to worry about the cost of tackling the thread safety. Also, if we could bring the multiple-inheritance without much complexity for our types, then we could totally avoid the problem mentioned above.

Solution – A Protocol-Oriented approach

Time demands a different thinking approach. Thinking beyond OO way. A Protocol-Oriented approach. But first, What is Protocol? A protocol is a set of rules and requirements (methods and properties), which a type(value or reference) needs to fulfill. Consider protocol as an abstract blueprint of its requirements. A type can implement these requirements accordingly and said to conform to a protocol. Additionally, a type can conform to multiple protocols.

Let’s try to solve the above problem through a protocol-oriented approach –

Protocol Diagram for Artist.png

We declared three protocols, Artist, Actor and Singer. Actor and Singer inherit from Artist protocol. Each protocol has declared their requirements. For example, a type conforming to Artist protocol needs to define name and age in its implementation. Similarly, a type conforming to Singer protocol needs to provide the implementation for name, age, songs and addSong().

Protocol Diagram for Artist - Page 2.png

Next, we defined a class named OnlySinger which conforms to Singer protocol. We defined another class SingerActor which inherits from OnlySinger such that it gets all the implemented functionality of Singer protocol and also made it conform to Actor protocol so that it can implement the required functionality of it.

This is how it looks in Swift –

protocol Artist {
        var name: String {get set}
        var age: Int {get set}
    protocol Actor: Artist {
        var movies: [String] {get set}
        func addMovie(movie: String)
    protocol Singer: Artist {
        var songs: [String] {get set}
        func addSong(song: String)
    class OnlySinger: Singer {
        //OnlySinger conforms to Singer protocol
        //Hence it needs to implement its requirements
        var songs: [String] = []
        var name: String = ""
        var age: Int = 0
        func addSong(song: String) {
            //Add song to singer's song list

This approach looks much cleaner as against to the subclassing approach. We are not leaking any extra functionality. This is a Protocol-Oriented approach where the major things are driven by the protocols. They set the rules and requirements and types need to implement those as per their need.

An advantage with protocols is that they can be extended to provide a default implementation of its requirements. For example, if some requirements of the protocol have common implementation across all of its conforming types, those requirements can be implemented by the protocol itself. All the conforming types get the default implementation for free and they do not need to implement it again.

A protocol is a language construct available in Swift and Objective-C programming language. Not all the features of it are available in Objective-C though. Though Swift supports OOP and Functional programming paradigms, it is a Protocol-Oriented language at its heart. Most of the value types in Swift like Array, Dictionary, String etc are based on protocols and built upon this paradigm.


  1. I don’t see anything new here. Yes, you can use protocols or interfaces or just classes ( in languages that make no distinction between class and interface ) to simulate multiple inheritance in languages that don’t support it, like swift. That’s been around since Java and C# removed multiple inheritance from C++ ( well actually even way before that ). It only seems “new* to swift because now you have a different keyword, ie “protocol”. That’s the only difference, syntax, it’s not a different flavor of programming at all.

    >> Swift surely gave birth to the new programming paradigm to overcome the caveats of OOP

    LOL. OK. IMHO, it seems to me all swift did was to remove multiple inheritance ( from it’s flavor of OOP ) so now you have to implement functionality with protocols instead, ie functionality that maybe better implemented with multiple inheritance ( but that’s unavailable in swift ). Nope, swift didn’t give birth to anything.

    Cheers! Happy Programming!


  2. Write more, thats all I have to say. Literally, it seems as though you relied on the video to make your point. You clearly know what youre talking about, why throw away your intelligence on just posting videos to your weblog when you could be giving us something enlightening to read?


  3. I’m now not sure the place you are getting your info, but great topic. I needs to spend a while learning more or understanding more. Thanks for great information I used to be looking for this information for my mission.


Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.