I have to admit, when I saw the syllabus for Day 11 of the 100 Days of Swift I cringed. Today is all about protocols. No offense to Paul Hudson, he does an amazing job with these videos and quizzes, but Protocols and in particular protocols in Swift could be a whole 100 day course in and of itself. If we had a gauge that measured buzzword hype, the word “protocol” would be trending at a fairly rapid rate.
Protocol is one of those words that has a fairly large number of definitions and contexts and you are never quite sure you are talking about the same thing that everyone else is talking about. It is like the classic line by Inigo Montoya from the movie The Princess Bride when he tells Fezzik, “You keep using that word. I do not think it means what you think it means.”
At this point usually someone dusts off their dictionary and looks up the word Protocol and begins reciting what it says like that is going to somehow make all of us raise one finger in the air and yell, “Aha!” The problem becomes the dictionary was never supposed to be the end all be all of meaning. At best it gives us small use cases and contexts for when you might could use the word. But as we have seen, context changes constantly and we are suddenly using terms correctly in ways they were never designed to be used.
With Protocol it is even worse. We now have a relatively recent fad of the day within programming methodologies called Protocol Oriented Programming or POP. Some suggest that POP will replace Object Oriented Programming as the dominant programming methodology but as we discussed yesterday even Object Oriented Programming is in many cases being ignored so why would we think that Protocol Oriented Programming would be any different and we have yet to come up with a consistent definition of what POP is which makes the challenge even greater.
I will admit, the first few times I heard about protocols in Swift and Protocol Oriented Programming I had no clue what they were talking about. After what felt like a rather extensive Google search and more documentation than I care to remember I started to get a handle on this concept but there are times that I still have not wrapped my head around it. Apple attempts to provide a contextual definition in their Swift documentation:
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.
That still felt a little dry to me. I found that the best way to think about Protocols is that they are the behaviors you expect things to have. For example, for the most part we expect that if we are going to go outside in public that people will wear clothing. Granted there are exceptions to this depending on where you are going but for the most part there are behavioral norms that we expect everyone to follow. Likewise, in this country if you are driving on the road in your car you are expected to drive on the right side of the road and follow the appropriate traffic rules.
When you were younger you did not know what those rules were so therefore you were sent to Drivers Education where they taught you what you needed to know to safely drive a car. Once you were sufficiently trained you were sent to the Department of Motor Vehicles where you were given a written test and in most cases a driving test. The state wanted to validate that you could safely operate a car on the roads so no one was hurt or killed.
Protocols help to describe what is required of structs or classes so that whenever one is created that we can expect that it will conform to some standard set of behaviors whether that is that they must have some sort of attribute or some function must be run against them. This allows the application to trust that the structure or class is well behaved in the environment.
And like traffic laws, there can be extensions for special cases. For example, if you want to become a school bus driver you are expected to know more than the typical car driver. You are now carrying more people and driving a different type of vehicle so therefore the state will require additional training or changes to training that they would for someone who just wants to drive a car. Programmatically you can use extensions to extend methods for Protocols that further enhance or come up with additional functionality that is not normally there.
Protocol Oriented Programming is not necessarily a different way of programming and in my opinion, it is not a replacement for Object Oriented Programming. Rather I see it as an extension of it. When you are defining your classes you should be thinking about what kinds of behaviors those classes should follow. This will help you to mitigate some of the complexity and chaos by building in the guardrails of when an object is instantiated that it will inherit some behavioral patterns.
As I said, protocols and Protocol Oriented Programming in itself can be rather complex and warrants more than a small blog post or a few minute lectures and quizzes. But through its inclusion in the 100 Days of Swift challenge it has introduced you to a subject and hopefully inspired some level of curiosity that you will go out and research the subject yourself. Like all behavior patterns they will change over time. What may have once seemed appropriate now is not. That is where protocols will help to allow your code to acknowledge these and conform to new mores.
0 Comments