Protocols, Opaque return types & Extensions (Day 13)

SideQuest - Learn a new language #
I have decided to embark on learning Turbo Native, my first foray into this wasn’t too bad, however I feel like I’m not understanding key concepts so it’s time to go back to the drawing board.
For my next trick, I’m going to learn some swift so that I can learn Turbo Native 🎉
I’ve found a great online resource called 100 Days of Swift - Hacking with Swift and I’m going to try and stick with it. I’m planning on using this site to document little nuances that I need to remember as a set of notes for me to refer back to.
For anyone else reading this, these notes are probably not very useful and I would suggest going to this great resource.
Protocols #
I’m up to this section in the resource How to create and use protocols and for my memory, this is how protocols interact with classes.
Protocols are like interfaces in java. They are used to define a contract that an implementer must adhere to, however they do not implement their methods.
Rules:
- Protocols are types, use a Capital letter to name them.
- List the methods that are needed in the protocol for an implmenter to comply.
- There is no code in the protocol. It is merely a placeholder.
| |
A more concrete example is:
| |
The benefit is now that both a car and a bike conform to type Vehicle, we can ignore implementation details and treat them both as similar objects that respond to certain messages.
| |
Further good information can be found here: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/protocols
Opaque return types #
I’m up to How to use opaque return types.
Opaque return types are an abstraction layer provided by Swift, instead of return the exact type of a method, we can specify the kind of return type it is. This only works because Swift actually knows what is returned by allows us to abstract up a layer.
| |
As both Booleans and Ints conform to the protocol of Equatable, we can actually write
| |
This doesn’t seem that useful, however think about returning a Vehicle protocol rather than a simple class. This suddenly allows you to return from a single method multiple types.
This allows you to be flexible in the internals of the method and allow you to keep the external API consistent.
Extensions #
I’m up to How to create and use extensions
Extensions allow us to extend any type. Kind of like a concern or mixin in Ruby. These are neat!
Here is the ’normal’ way of trimming whitespace from a text string:
| |
instead, our preferred api would be quote.trimmed(). We can achieve this with extensions.
| |
Further, you can mutate and update the original variable by declaring with mutating
| |
ed or ing like reversed(). Use the verb if you are modifying in place.Protocol Extensions #
I’m up to How to create and use protocol extensions.
Protocols let us define contracts that conforming types must adhere to, and extensions let us add functionality to existing types.
As a trivial example, you can check whether an array is populated with:
| |
It would be nice to be able to have have an API that says Array.isNotEmpty. Protocol Extensions to the rescue
| |
Further, this could be used for more types, such as Set, Dictionary. These all conform to a protocol called Collection.
| |
This technique leads to something that apple calls protocol-oriented programming, we can list some required methods in a protocol and then define a default implementation.
For example, you can:
| |