Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

POP Art: Understanding Protocol-Oriented Programming

DZone's Guide to

POP Art: Understanding Protocol-Oriented Programming

Protocol-Oriented Programming seems like something you can quickly dismiss, but there's a lot going on beneath the surface.

· Mobile Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

So, last year when all the excitement was frothing about this Protocol-Oriented Programming “revolution,” First Protocol-Oriented Language and all — did you take a quick look and chuckle to yourself , thinking “Ah, they’ve rediscovered Mixin-Based Programming, isn’t that cute?” and move on? Yeah, us too. But it turns out there is a good bit more depth to plumb! Here’s an excellent tutorial style introduction, released as a teaser for the RWDevCon 2016 Vault video collection:

RWDevCon 2016 Session 303: Introduction to Protocol-Oriented Programming

Here are the key points:

  • protocols with extensions are almost perfectly superior to inheritance
    • you can do almost everything you can with inheritance
    • and, they can work with value types
    • and, they allow retroactive modeling
  • but, protocols with associated types (PATs) are different beasts
    • you give up dynamic dispatch
    • but you can model more intricate type relations

Or if you just want one nugget to mull over, I’d say most of it is in this slide:

POP-comparison.001-480x270.png

And here is an absolutely essential series on associated types from Russ Bishop:

Swift Associated Types

Sometimes I think type theory is deliberately obtuse and all those functional programming hipster kids are just bull-shitting as if they understood one word of it…

Swift Associated Types, cont.

I don’t feel like I fully covered one aspect of protocols with associated types: why can they be such a pain to work with?

Swift: Why Associated Types?

So the philosophical answer to the question of Why Associated Types? is that the Swift core team believes they are a better way to model concepts. They don’t have the problem of multiple conformances, they encapsulate the details of a concept cleanly, and they’re less fragile.

And there you have it. By way of example, here’s a few practical applications of protocols to make common tasks more elegant:

Protocol-Oriented MVVM in Swift 2.0

Protocol Extensions, Meet List Controllers

Stupid Swift Tricks #5: Pickable Enums

Upgrade your TableViews with Loading State

And a wide-ranging selection of other inside baseball style musings on generics and protocols to help you grok the gestalt here:

Swift Protocol Extension Weirdness

Improved Protocol-Oriented Programming with Untyped Type Aliases (part 1) and part 2

Generic Protocols & Their Shortcomings

Trimming Swift generics

Generics and the Art of Inference Part 1 of 3

What the 55 Swift Standard Library Protocols Taught Me

Protocols with Associated Types, and How They Got That Way

Protocol-Oriented Problems and the Immutable ‘self’ Error

The why of nonmutating

Beyond Crusty: Real-World Protocols

Working with Swift: Adopt a Protocol or Pass a Function?

Doubling Down on Protocol-Oriented Programming

Plenty there to keep you pondering for a while we trust!

UPDATES:

Practical Protocol-Oriented-Programming slides from Natasha The Robot

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:
swift

Published at DZone with permission of Alex Curylo, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}