We’ve spent the past four episodes taking a deep study of protocols and exploring how their features can be represented using concrete datatypes and functions, and we’ve seen how in doing so we can address some of the shortcomings and complexities of protocols while unlocking a world of composition that was previously hidden. We’ve even suggested that the way we design our APIs could be dramatically improved by eschewing protocols in favor of these concrete datatypes and functions. That’s quite the claim, seeing as we’ve spent four episodes on the subject without ever demonstrating this! So much for “what’s the point,” huh!?

Well this week we finally put our theory to the test! We’re going to refactor a small library to be more flexible and extensible by abstracting away part of its design. We’ll start in the protocol-oriented way because that’s how we’re told to design these kinds of things in Swift. It’ll give us an opportunity to analyze the problems that protocols have that we think concrete datatypes and functions can solve.

We want to stress that we do not consider the actual library we are design to be the most interesting aspect of this topic, although it is quite cool. The real topic we are dissecting here is that of how we approach library design in Swift, and what lessons from our series on protocol witnesses can we apply so that we avoid the pitfalls of protocols.