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

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

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

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

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.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}