I have had numerous conversations about what exactly is
Protocol Oriented Programming since my
Protocol Oriented Programming with Swift book was released.
Everyone I spoke to seemed to have his or her own opinion about what POP
is.
Out of all of those conversations I
think this is the best explanation that I heard “
Programming with an
orientation toward the use of protocols for abstraction”.
So what do we mean when we say that POP is “Programming with
an orientation toward the use of protocols for abstraction”? Quite simply my interpretation of this is
with POP we should be programming to a protocol and not to an
implementation. This is very similar to
other languages where we use interfaces however Protocols in Swift take a more
predominate role within the language itself where as other languages, like C#
and Java, the interface really takes a back seat to the class hierarchy.
In my
POP vs OOP post I demonstrated a lot more than just the protocol so you may be asking yourself
what are all of the other features that I talked about.
This is very similar to saying that Object
Oriented programing is based on the concept of programming with objects.
Now we all know that good OOP design is about
a lot more than just the object, similarly good POP design is about more than
just the protocol which is why I think Apple introduced Protocol Extensions
during their POP presentation (I could be wrong about and it is just my
opinion).
So what makes for a good POP design?
The post that I wrote that compared OOP to
POP
really showed what I think is good
POP design.
You could also pick up my
Protocol OrientedProgramming with Swift book on the subject as well
:).
In this post rather than going in
depth in to POP design I would like to touch on a couple of points that people
have brought up to me based on my book and earlier post.
Protocol Extensions are simply syntactic sugar
When people say that Protocol extensions are simply
syntactic sugar they are absolutely correct however there is nothing wrong with
syntactic sugar. There are other ways
that we can avoid duplicate code when using value types however protocol
extensions are very convenient and also gives us good code organization however
for good code organization we do want to avoid having multiple extensions for a
single protocol or type. For example we
should avoid this unless each extension has different constraints defined.
protocol Foo {
var x: Int {get set}
}
extension Foo {
func add(y: Int) -> Int {
return x + y
}
}
extension Foo {
func sub(y: Int) -> Int {
return x - y
}
}
Use Protocol Extensions with caution and use
constraints where necessary
It is very ease to simply add a protocol extension without
thinking too much about the types that conform to the protocol.
For example in my
POP book I used the
following example of how to extend the
CollectionType
protocol.
I then followed it
up in my book up by pointing out how this
extension does not work for all types that conform to the
CollectionType
protocol like the
Dictionary
type therefore we either needed to use a constraint to limit the implementations that received this functionality or only extend the specific
implementation that needs this functionality..
extension CollectionType {
func
evenElements() -> [Generator.Element] {
var index = self.startIndex
var result:
[Generator.Element] = []
var i = 0
repeat {
if i % 2 == 0 {
result.append(self[index])
}
index = index.successor()
i += 1
} while (index != self.endIndex)
return result
}
func shuffle()
-> [Self.Generator.Element] {
return sort(){ left,
right in
return arc4random() < arc4random()
}
}
}
Avoid getting to granular with your protocols
To me, making smaller more specific protocols and using
protocol inheritance and composition as I illustrated in my
POP vs OOP post is an advantage that POP design has over OOP design however it was pointed out
to me by a very smart person that we need to avoid getting to granular with our
protocol designs.
In OOP we have the
problem where we get large monolithic super classes and sometimes this can not
be avoided however with POP we as programmers and architects need to avoid
making our protocols to granular.
The
following code illustrates what we want to avoid.
protocol FooAdd {
func add(x: Int, y: Int) -> Int
}
protocol FooSub {
func sub(x: Int, y: Int) -> Int
}
protocol FooMul {
func mul(x:Int, y: Int) -> Int
}
struct Bar1: FooAdd, FooSub, FooMul {
func add(x: Int, y: Int) -> Int {
return x + y
}
func sub(x: Int, y: Int) -> Int {
return x - y
}
func mul(x:Int, y: Int) -> Int {
return x * y
}
}
In this example, FooAdd, FooSub and FooMul protocols only
contain one function each and those functions are related (mathematical
operation) therefore it really makes since to put them into a single
protocol. If you have multiple protocols
that you are always grouping together, you may want to consider combining them
into a single protocol.
Error Handling in POP
In my
Protocol Oriented programming with Swift book, I have
a chapter on error handling.
I have been
questioned about this since error handling is really part of the language
itself and not really part of the POP paradigm.
These people are absolutely 100% correct however anytime we write or
design an application we need to worry about how we will respond to and recover
from errors therefore to me error-handling needs to be a part of any good
design.
With this in mind, in my
opinion, a book that talks about design, with a specific language, should include
something on error handling.
That really
is just my opinion and hopefully explains why I included a chapter on error
handling in my book.
My Books and Posts
I received a one star review of my Protocol Oriented
Programming with Swift book with a comment about my writing style. Another person responded to the comment
saying “The writing style in this
book is actually very good. It is written so even the non-programmer can
understand and grasp the concepts behind POP.” That is really my goal not only in my books
but also in this blog. I try to write in
a way that everyone can grasp the concepts discussed. My favorite review that I have received for
any of my books was one for my Mastering Swift 2 book where the reviewer said,
“This book is simple
enough my 13 years old has started reading it and while I do not anticipate him
reading past chapter 12...it is easy enough for him to follow.” I hope that I will always continue that
writing style.
You see to me programming is something that is fun and
magical. I still remember the feeling I
had as a 13 year old kid and writing my first Brickout game on a Commodore
VIC-20. Programming does not need to be
overly complicated however we do need to ensure that our code works properly
and can be easily maintained. I really
hope my posts and my books have helped.
