TIL this builds:
|
1 2 3 4 5 6 7 8 9 |
protocol WizardStep { var header: UIViewController { get } } final class SiteSegmentsStep: WizardStep { lazy var header: UIViewController = { return UIViewController() }() } |
Swift never ceases to amaze me
One of the things I like most about Swift is that almost every day I learn something new, more often than not, something new that makes me write more readable and cleaner code.
Today I realised that protocol composition, which I kind of knew could be used to compose a SuperClass and a Protocol, can help remove some downcasts at runtime, and substitute those downcasts by the compiler yelling at you when writing the code.
Let’s take this code. As usual, it is difficult for me to come up with a relevant example that illustrates what I want, but is also simple enough to be understood without too much context.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
protocol Presentable { func present() } class Device { func turnOn() { print("turn device on") } } final class Screen: Device, Presentable { func present() { print("presenting stuff on screen") } } final class Telegraph: Device { } final class Presenter { func deliverPresentation(screen: Device) { screen.turnOn() if let screenPresentable = screen as? Presentable { screenPresentable.present() } } } let screen = Screen() let telegraph = Telegraph() let presenter = Presenter() presenter.deliverPresentation(screen: screen) presenter.deliverPresentation(screen: telegraph) |
Notice how I have to check, at runtime, that the parameter I pass to deliverPresentation implements the Presentable protocol.
If we rewrite the Presenter to be like this, we can make the compiler enforce that whatever we pass to deliverPresentation as a parameter also implements Presentable, so we can avoid the downcast.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
final class Presenter { func deliverPresentation(screen: Device & Presentable) { screen.turnOn() screen.present() } } let screen = Screen() let telegraph = Telegraph() let presenter = Presenter() presenter.deliverPresentation(screen: screen) // The following line will trigger a compiler error presenter.deliverPresentation(screen: telegraph) |
A real life example? From this:
|
1 2 3 4 5 6 7 8 |
private func showDocumentPicker(origin: UIViewController) { let docTypes = [String(kUTTypeImage), String(kUTTypeMovie)] let docPicker = UIDocumentPickerViewController(documentTypes: docTypes, in: .import) if let delegate = origin as? UIDocumentPickerDelegate { docPicker.delegate = delegate } origin.present(docPicker, animated: true, completion: nil) } |
To this:
|
1 2 3 4 5 6 |
private func showDocumentPicker(origin: UIViewController & UIDocumentPickerDelegate) { let docTypes = [String(kUTTypeImage), String(kUTTypeMovie)] let docPicker = UIDocumentPickerViewController(documentTypes: docTypes, in: .import) docPicker.delegate = origin origin.present(docPicker, animated: true, completion: nil) } |
The joys of jet lag. Here I am, at 2:43 am, trying to finalize a post that I started writing a couple days ago, while flying over the Pacific Ocean.
This is about dependencies, those third party libraries that often provide out of the box solutions to complex problems we need to solve.
Importing a third party library will save time and effort. Just add a line to a pod or Carthage file, and boom! We have saved days, weeks or months of development.
There are multiple benefits in relying on a third party library. Popular libraries are often well tested, and contain the knowledge of many developers about a given problem. Third party libraries save development time. Third party libraries avoid reinventing the wheel.
But third party libraries are code that you have not written, code that you don’t actually own, but that you somehow have to start maintaining as soon as you import it into your codebase.
Let’s take an example. Loading images, asynchronously, without blocking the main thread, in a table or collection view cell is a complex problem. We need to cancel image downloads when cells are not visible anymore, we might need to handle cell reusability, and ideally we should cache images. None of those problems are trivial to solve, and might require time and finesse to get right.
On he other hand, we could just import a third party library, like, for example, Kingfisher.
All we’d need to do would be adding a line to a pod / carthage file.
We have created a subtle problem here: our cell’s code depends on Kingfisher. We need to call a specific method in that library, passing a set of specific parameters, in the way that library expects.
That be not be a problem if we only have one cell. But things start getting dangerous as soon as we have more than one cell.
Let’s say there are 10 different cells that present images in our codebase. Kingfisher is so convenient that we will repeat the same code in the 10 of them.
What would happen if, for some reason, Kingfisher stops being maintained? Or a new version of Swift breaks source compatibility again, and this library does no get updated? Or a new library comes by, that is twice as efficient as Kingfisher.
Then we would have a bit of a problem. Our code is strongly coupled with the specific api of a very specific library, and updating our code to use a different library might require getting into shotgun surgery mode.
How do we switch? Well, we could just do a search and replace, or search all the calls to Kingfisher and update them to use the new, hottest library.
But that is not very efficient, obviously.
So how do we avoid the problem?
The same way that we have tools and mechanism to decouple some parts of our code from some other parts of our code, we have tools and mechanisms to decouple or code from third party libraries.
And the best tool for decoupling things is, as usual, a layer of indirection.
In this case, we could add a layer of indirection by encapsulating the call to the third party library in an extension to UIImageView. This extension would be code under our control, and will contain a single point of dependency with the third party library.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
import UIKit import Kingfisher extension UIImageView { func presentImage(_ imageURL: URL?) { guard imageURL == imageURL else { return } self.kf.setImage(with: imageURL) } } |
Our cells will load images by calling a method that belongs in our side of the codebase, not in the library’s side of it.
Now if we want, for whatever reason, to switch to a third party library, all we have to do is modify the implementation of our extension. Import a different library, update the presentImage method to that third party library’s API, and we are good to go.
Introducing seams between our code and third party libraries decouples our code from external dependencies. That way, we are free to modify those dependencies without having a big impact in our codebase.
Kingfisher is a great library that solves a complex problem in an elegant way. I strongly recommend considering it.
Everybody that knows me in real life knows that my favourite jokes are always those about Java being slow and bloated. But still, in all fairness, Java has some good things.
One of them, rendered obsolete by Java 8’s Lambda Expressions, that I always liked and that I really wish was possible in Swift, is Anonymous classes.
The way I see it, an anonymous class is just a syntax shortcut to declare and instantiate, inline, an instance of a specific interface. It is a quick way to create lightweight objects at the moment they are going to be used, or passed to another object.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
interface Command { public void execute(); } class AThing { public void doAThing(Command command) { command.execute(); } } class Untitled { public static void main(String[] args) { AThing thing = new AThing(); thing.doAThing(new Command() { public void execute() { System.out.print("Hello"); } }); } } |
Anonymous classes have access to the members of its enclosing class, and local variables in its enclosing class marked as final, which makes them great candidates to be used, in particular, to declare callbacks in particular.
To me, their greatest advantage is that anonymous classes allow you to encapsulate behaviour in a way that you only declare implicit types when you expect to actually reuse them.
Still, Lambda Expressions, similar if not equal to what in Swift we know as closures, might make code more concise in some situations. So, as usual, it comes down to knowing your tools, and careful considering which tool is the best for the job.
Updated on Sept 24th.
Joe Fabisevich points out that something similar to what the sample code does could be achieved in Swift by typealias-ing a closure, and typing AThing’s doAThing parameter as said typealias.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
typealias Command = () -> Void class AThing { func doAThing(_ command: Command) { command() } } let thing = AThing() thing.doAThing { print("hello") } |
Which is quite similar to a solution based on Java lambdas.
If we need to declare more than one method in the Command interface, though, this approach would fall sort.
Joe also suggests another option in Swift:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
protocol Command { func execute() } struct AThing { func doAThing(command: Command) { command.execute() } } class Main { init() { struct Commander: Command { func execute() { print("Hello") } } let thing = AThing() thing.doAThing(command: Commander()) } } Main() |
This still requires making a type, but it is (or can be) private to the Main class, which in a way achieves the same goal as an anonymous class. It would be a concrete type, yes, but known only to the type enclosing it.
I was re-reading Effective Java (it is a rainy Sunday afternoon in Vancouver, and if you are stuck at home, and you happen to be European, and therefore you don’t really care about what Americans call “football”, re-reading Effective Java is not as bad as it sounds) when I soon stumbled upon an example that I think highlights the elegance of Swift (and, to be completely fair, also Kotlin’s).
Effective Java’s Item #2 says: Consider a builder when faced with many constructor parameters. Which makes total sense, if you ask me.
I am not going to discuss or justify the Builder Pattern now, but let’s just assume that it is more than justified.
The canonical implementation of the pattern, and I am going to take the liberty of using the code sample used in Effective Java without any modification, would read like the following (servings and servingSize are the only mandatory parameters, the rest are all optional)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 |
public class NutritionFacts { private final int servingSize; //required private final int servings; //required private final int calories; //optional private final int fat; //optional private final int sodium; //optional private final int carbs; //optional public static class Builder { //Required private final int servingSize; private final int servings; //Optional private int calories = 0; private int fat = 0; private int sodium = 0; private int carbs = 0; public Builder(int servingSize, int servings) { this.servingSize = servingSize; this.servings = servings; } public Builder calories(int val) { calories = val; return this; } public Builder fat(int val) { fat = val; return this; } public Builder sodium(int val) { sodium = val; return this; } public Builder carbs(int val) { carbs = val; return this; } public NutritionFacts build() { return new NutritionFacts(this); } } private NutritionFacts(Builder builder) { servingSize = builder.servingSize; servings = builder.servings; calories = builder.calories; fat = builder.fat; sodium = builder.sodium; carbs = builder.carbs; } } class Untitled { public static void main(String[] args) { NutritionFacts cocaCola = new NutritionFacts.Builder(240,8) .calories(100) .sodium(35) .carbs(27) .build(); } } |
If we follow the pattern to the letter, it translates into Swift like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
final class NutritionFacts { private let servingSize: Int private let servings: Int private let calories: Int private let fat: Int private let sodium: Int private let carbs: Int init(builder: Builder) { servingSize = builder.servingSize servings = builder.servings calories = builder.calories fat = builder.fat sodium = builder.sodium carbs = builder.carbs } class Builder { let servingSize: Int let servings: Int private(set) var calories = 0 private(set) var fat = 0 private(set) var carbs = 0 private(set) var sodium = 0 init(servingSize: Int, servings: Int) { self.servingSize = servingSize self.servings = servings } func calories(value: Int) -> Builder { calories = value return self } func fat(value: Int) -> Builder { fat = value return self } func carbs(value: Int) -> Builder { carbs = value return self } func sodium(value: Int) -> Builder { sodium = value return self } func build() -> NutritionFacts { return NutritionFacts(builder: self) } } } let facts = NutritionFacts.Builder(servingSize: 10, servings: 1) .calories(value: 20) .carbs(value: 2) .fat(value: 5) .build() |
Which is a lot of boilerplate, no matter how you look at it.
We have discussed Swift’s Default Parameters before in this blog, but in the context of Dependency Injection, in particular when focusing on testability.
But the thing is that Default Parameters, like many other Swift artifacts (or constructs, or whatever is the right word to refer to “stuff that Swift provides and makes your life easier”) can make code much more concise, readable and easier to understand and reason about while removing some of the bloating that certain languages (I’m looking at you, Java) are known for.
Because when providing default values to all the optional parameters, this is how our NutritionFacts look.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
final class NutritionFacts { private let servingSize: Int private let servings: Int private let calories: Int private let fat: Int private let sodium: Int private let carbs: Int init(servingSize: Int, servings: Int, calories: Int = 0, fat: Int = 0, sodium: Int = 0, carbs: Int = 0) { self.servingSize = servingSize self.servings = servings self.calories = calories self.fat = fat self.sodium = sodium self.carbs = carbs } } let facts = NutritionFacts(servingSize: 10, servings: 1, calories: 500) let otherFacts = NutritionFacts(servingSize: 10, servings: 1, calories: 1500, sodium: 2) |
Much better, eh?
This one might be obvious, but it was a very pleasant surprise.
Let’s say we have something like this:
|
1 2 3 4 5 |
struct Receiver { func doAThing(_ closure:() -> Void) { closure() } } |
And a regular function like:
|
1 2 3 |
func theClosure() { print("Body of the closure") } |
Then, Xcode will provide this code hint:
And now I can do:
|
1 2 3 4 5 6 |
let aReceiver = Receiver() aReceiver.doAThing { print("an specific thing that is not what theClosure does") } aReceiver.doAThing(theClosure) |
Which I guess is not that unexpected. But still, a pleasant surprise.
In the previous post, we discussed how protocols 1 are the foundation of polymorphism, and how using protocols we can define a contract, an expectation, that can be implemented in many different ways.
Today we are also to explore how we can use protocols as a way to use code that does not exist yet, as a boundary between what we know (our code) and what we don’t know (other people’s code).
In an ideal world (maybe not ideal for everyone, but that would be a different discussion) we don’t develop our software in isolation. We have team mates, or we use modules or frameworks developed by other teams within the same company.
Some time ago, I was with a time developing a set of Video On Demand applications. We had to implement a new feature: add support for recommendations based on user’s content consumption habits. The recommendations engine was not developed yet, in fact there was no team assigned to build it at that time.
We knew were our side of the solution started and ended. We knew we were going to need to tell the recommendations engine that a user had watched a particular item, and we were going to need to get a list of recommended items from the engine.
We started by defining our own interface for that recommendations engine. We looked at the problem from ur side of it, and wrote the interface we wished the recommendations engine had.
Did we know how the actual interface of the actual recommendations engine would look? Not at all. Did we care? We did not.
But we could start working on our side of the solution using fake data.
Having a clear boundary, clear separation between our side and their side, allowed us to build our side completely decoupled from the recommendations engine.
Having a clear boundary also gave us the confidence that we would be able to adapt to whatever the actual interface of the recommendations engine would look. And why I mean by adapt is literally write an adapter between our interface and the actually interface of the engine, if necessary (see the Adapter Pattern)
Also, having a clear boundary allowed us to unit test our solution from day one, giving us the confidence we needed to move forward fast.
It’s not rocket science. But it is worth remembering that protocols are not just those things that you use for table views data sources and delegates, but that they are probably the most powerful tool in our reach.
Back in the old days, people used to communicate with each other by shouting.
|
1 2 3 4 5 6 7 |
struct Person { let name: String func sendMesage(content: String) { print(content) } } |
But soon, people found that shouting was not practical. The receiver of a message could just be too far away, or sleeping, so humanity invented written messages. And so snail mail was born.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
struct Person { let name: String let mail = SnailMail() func sendMesage(content: String) { mail.send(message: content) } } struct SnailMail { func send(message: String) { print("sending snail mail. ", message) } } |
Fast forward a few hundred years, to the early ages of the internet. Someone, somewhere, invented email, so now people could communicate like this.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
struct Person { let name: String let emailClient = Email() func sendMesage(content: String) { emailClient.send(message: content) } } struct Email { func send(message: String) { print("sending email ", message) } } |
Soon, people realized that even though email was great, there were other forms of communication. What’s even more remarkable, people were happy sending emails, but they soon realized that what they really wanted was to be able to do something slightly different. Instead of sending emails, they just wanted to send messages.
Some of those messages would be emails, some of them would be snail mail, some others might even be some unknown technological marvel soon to be discovered. But what all people knew is that they did not wan to be constrained by being able to send emails and only emails.
And here is when people realized that the way they had been approaching communications was slightly unadaptable.
One of the few software engineers on the face on earth at that time, decided to do something about it. She started thinking about what people wanted, and why they could not have it, and soon realized that the actual problem was that there was a hardcoded dependency between a Person, and the way that person was able to communicate.
Our hero also realized that the reason why that was a problem was that what people really wanted was freedom of choice, and flexibility, and being able to send messages by multiple different mechanisms, not only email.
And that made her think: “maybe what people expect are not things, but behaviours”. Indeed, People seemed to have a clear expectation: “we should be able to send a message”, but different people wanted that expectation to be fulfilled differently.
Our hero thought “what people want to rely upon is an abstraction, not something specific.”1
So our hero started building her solution around an abstraction: a protocol defining a behaviour.
|
1 2 3 |
protocol Sendable { func send(message: String) } |
That allowed our hero to model a couple of specific implementations of that behaviour 2. For example, an email, an SMS, an iMessage (aka Apple Message, to avoid lowercasing a class, apparently all our hero firmly believes in coding standards)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
struct Email: Sendable { func send(message: String) { print("sending email ", message) } } struct SMS: Sendable { func send(message: String) { print("sending SMS ", message) } } struct AppleMessages: Sendable { func send(message: String) { print("sending iMessage ", message) } } |
So now, a Person could be taught to blindly rely on the abstraction our hero modelled, trusting it to know how to fulfill her expectations.3
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
struct Person { let name: String /** * Person does not know exactly what it depends on. All it knows is that it depends on something that willl provide a send() method (as declared in the protocol) */ let sendable: Sendable /** * Inject the dependency */ init(name: String, sendable: Sendable) { self.name = name self.sendable = sendable } /** * And rely on the abstraction, provided as a parameter (aka injected), to do its thing */ func sendMesage(content: String) { sendable.send(message: content) } } |
That way, Cesar can send emails while Jodelle can send emails, or a hipster can send a Messenger Pigeon.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
/** * Cesar Sends SMSs */ let smsSender = SMS() let me = Person(name: "Cesar", sendable: smsSender) me.sendMesage(content: "Hey Jodelle!") /** * Jodelle Sends Emails */ let emailSender = Email() let jodelle = Person(name: "Jodelle", sendable: emailSender) jodelle.sendMesage(content: "Hey Cesar!") /** * Hipsters send pigeons */ struct Pigeon: Sendable { func send(message: String) { print("sending this message with a pigeon ", message) } } let pigeon = Pigeon() let aHipster = Person(name: "It's ironic!", sendable: pigeon) aHipster.sendMesage(content: "Hello world") |
Our hero was satisfied with her implementation of the solution, specially because she realized that this design allowed her to provide as many means of sending messages as she wanted, without having to change the way a Person sends a message.4
Also, our hero soon realized that she could only test that messages are actually sent, by providing a very specific type of Sendable that did not actually send any message.5
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
/** * Mock objects usually do not have any actual behaviour, other than fulfilling an expectation. In this case, we want this mock object to mark itself as "sent" when the send() method is called */ class MockSendable: Sendable { var sent: Bool = false func send(message: String) { sent = true } } /** * Now we inject the mock into a Person, ask that person to send a mesage, and check that the mock has been marked to "sent". That, in the context of unit testing, is called the AAA (Arrange, Act, Assert) */ //Arrange. Create a Mock, and inject it let mock = MockSendable() print("mock initial state ", mock.sent) let personUnderTest = Person(name: "Test", sendable: mock) // Act. Call the method that triggers the behaviour we want to test personUnderTest.sendMesage(content: "Testing testing") // Assert. Verify that our expectation (the mock is marked as sent) has been fulfilled. This way, we can test Person in isolation, without any dependencies print("Did the mock get called? ", mock.sent) |
And that’s the power of protocols. A protocol defines a contract, declares a behaviour, but does not define the way that contract of behaviour is implemented. A protocol is abstraction, and the details, the nitty gritty of how those contracts or behaviours are implemented are left to concrete implementations of the protocol.
Relying on abstractions instead of concretions, in general, makes designs more decoupled, open for extension and closed for modification, and highly testable.
Today I learned that something that has been annoying me significantly when working in Swift, has a very simple solution, if only I knew my tools better.
This is a class. I have written a bunch of classes similar to this one:
|
1 2 3 4 5 6 7 |
final class Item { private let id: String init(id: String) { self.id = id } } |
That self in the constructor, annoys me to no end. I like how self is explicit in Swift, I think it makes the code more readable, less verbose, simpler. So, having it in the constructor, again, annoys me.
The solution is quite simple. Functions can have not only parameter names, but also argument labels.
Each function parameter has both an argument label and a parameter name. The argument label is used when calling the function; each argument is written in the function call with its argument label before it. The parameter name is used in the implementation of the function. By default, parameters use their parameter name as their argument label.
Adding an argument label:
|
1 2 3 4 5 6 7 |
final class BetterItem { private let id: String init(id _id: String) { id = _id } } |
And client code would remain unchanged:
|
1 2 |
let item = Item(id: "First") let betterItem = BetterItem(id: "Better item") |
I guess the lesson is, as always, know your tools.
Fair warning: Coming up with an example relevant enough to illustrate the topic, but simple enough to fit in about 1500 words is challenging. Take this code as a starting point, as a way to illustrate a discussion, and not as a drop-in solution ready to apply to a codebase.
Also, this solution can be applied to collection views. But again, for brevity, I will only discuss table views.
The previous post in this very blog was about going from the abstract and generic to the concrete and specific. It was, in a way, about specialising something abstract and generic, by subclassing it and providing a specific implementation for a specific type.
The sample code I used was more or less copied and pasted (with some info removed to protect the innocent) from the codebase I am currently maintaining. At the time I posted it it was holding well, but soon after that post I started having the feeling that there had to be a better way.
The problem I am trying to solve is a fairly common problem when it comes to iOS development: presenting lists of data without having an a lot of boilerplate code repeated again and again.
The usual way to present a list would be having a UIViewController that implements some or all of the methods in UITableViewDataSource.
That could be fine if there was only one data collection to render on screen, but usually, iOS apps are a sequence of screens that present data collections. Not only that, but usually, those screens are not that different from each other.
Sometimes, what changes from one data screen to another is the way a data item is rendered on screen (different UITableViewCells), some other times what changes from one screen to another is the presence or absence of section headers, or section footers, or both headers and footers.
So, if we approach the problem trying to abstract it as much as possible, what we would have would be a core behaviour (presenting data) that we might want to customise (i.e. adding headers or footers). And to make things more interesting, we want to do that in a way that reduces boilerplate and duplication and makes the solution testable.
The first step would be finding a way to factor out data management from view controllers. First, because it makes sense (a view controller should control a view, not manage a collection of data), and second, because by doing so we can remove a lot of boilerplate and duplication.
Shameless self promotion here: some time ago I published a framework to do precisely that.
There are other solutions, but I am sticking to mine for now, not because I think it’s better, but because, so far, it works for me. Basically, the implementation of the UITableViewDataSource protocol does not populate cells outlets, but provides cells with a model object, and trusts cells to know how to render that model object themselves. Tell, don’t ask!
So let’s start there. Let’s assume we are working on a task manager. We have a Task:
|
1 2 3 |
struct Task { let title: String } |
And we have a class to manage tasks as flat arrays. In real life, this data manager should be able to handle sections, but, again, for brevity, this one will be all flat:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
final class FlatArrayDataManager<T> { fileprivate var data: [T] init(data: [T]) { self.data = data } convenience init() { self.init(data: [T]()) } func itemCount() -> Int { return data.count } func item(_ indexPath: IndexPath) -> T? { guard indexPath.row < data.count else { return nil } return data[indexPath.row] } func sectionCount() -> Int { return 1 } } |
Now, let’s move to the other end of the problem: the UI. As mentioned, cells will know what to do to render themselves when they are provided with data. We can model that assumption with a protocol that indicates that a cell will accept a model object, and a concrete implementation of that protocol:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
protocol DataSettableCell { associatedtype DataType var data: DataType? {get set} } extension DataSettableCell { static func cellReuseIdentifier() -> String { return String(describing: self) } } final class AwesomeCell: UITableViewCell, DataSettableCell { var data: Task? { didSet { //populate cell, set outlets } } } |
A class implementing the required methods in UITableViewDataSource will look like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
class Required<T, U>: NSObject, UITableViewDataSource where U: DataSettableCell, U: UITableViewCell, T == U.DataType { private let data: FlatArrayDataManager<T> init(data: FlatArrayDataManager<T>, cellType: U.Type) { self.data = data } func numberOfSections(in tableView: UITableView) -> Int { return data.sectionCount() } func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return data.itemCount() } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { if var cell = tableView.dequeueReusableCell(withIdentifier: U.cellReuseIdentifier(), for: indexPath) as? U { let dataItem = data.item(indexPath) cell.data = dataItem return cell } return U() } } |
We provide it with a data manager, and a cell type. Notice how the implementation of the cellForRowAtIndexPath method only dequeues the cell, and passes it the model object that corresponds to its index.
So far, none of this solves the actual problem: customising data listings. But it send the foundation for a solution.
Let’s say that we have to render two different task lists, one of them without any section headers, and another one with a single section header. Let’s say also that we need a third listing with a section footer.
If we go all abstract, what we want is our datasource to behave slightly differently in different situations, while maintaining a core behaviour unchanged. Or, in other words, what we want is to add behaviour to an individual object without affecting the behaviour of other objects of the same class.
And that is, literally, the definition of the Decorator Pattern. So, let’s explore the Decorator Pattern a little bit more, and see if it can actually be a good solution to our problem.
(UML taken from wikipedia)
The pattern’s intent is clear: extending the behaviour of a certain object, independently of other instances of the same class. That will fit our case: we want some behaviour to remain unchanged but we also want to be able to customise some other behaviours, but only for specific cases.
There is another subtle detail here: the core behaviour, what we do not want to change, happens to be what is provided by the required methods in the UITableViewDataSource protocol, and what we want to customise, happens to be declared in optional methods.
That fits the pattern quite well. The ConcreteComponent could provide the behaviour we don’t want to change, provided by the require methods in the UITableViewDataSource protocol, and we could add ConcreteDecorators for each behaviour we wanted to add or customise.
So, just to recap, there seems to be a one to one relationship between the elements of the pattern and our use case: the Component would be the UITableViewDataSource protocol, the ConcreteComponent would be the Required class, and we can provide ConcreteDecorators that also implement the UITableViewDataSourceProtocol.
Let’s get to it!
This is the starting point:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
final class Required<T, U>: NSObject, UITableViewDataSource where U: DataSettableCell, U: UITableViewCell, T == U.DataType { private let data: FlatArrayDataManager<T> init(data: FlatArrayDataManager<T>, cellType: U.Type) { self.data = data } func numberOfSections(in tableView: UITableView) -> Int { return data.sectionCount() } func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return data.itemCount() } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { if var cell = tableView.dequeueReusableCell(withIdentifier: U.cellReuseIdentifier(), for: indexPath) as? U { let dataItem = data.item(indexPath) cell.data = dataItem return cell } return U() } } |
We would also need an implementation of the UITableViewDataSource protocol that aggregates an instance of the UITableViewDataSource type, implements all the methods in the protocol and forwards them to the instance it aggregates:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
class TableDecorator: NSObject, UITableViewDataSource { let source: UITableViewDataSource internal init(source: UITableViewDataSource) { self.source = source } func numberOfSections(in tableView: UITableView) -> Int { return source.numberOfSections!(in: tableView) } func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return source.tableView(tableView, numberOfRowsInSection: section) } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { return source.tableView(tableView, cellForRowAt: indexPath) } func sectionIndexTitles(for tableView: UITableView) -> [String]? { return source.sectionIndexTitles?(for: tableView) } func tableView(_ tableView: UITableView, sectionForSectionIndexTitle title: String, at index: Int) -> Int { return source.tableView?(tableView, sectionForSectionIndexTitle: title, at: index) ?? NSNotFound } func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? { return source.tableView?(tableView, titleForHeaderInSection: section) } func tableView(_ tableView: UITableView, titleForFooterInSection section: Int) -> String? { return source.tableView?(tableView, titleForFooterInSection: section) } // Implement all methods in UITableViewDataSource } |
And now we can start encapsulating the different behaviours we want to provide in subclasses of that TableDecorator. For example, if we need to provide a header title for a single section, a footer title for a single section, and header titles for multiple sections:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
final class SingleSectionHeaderTitle: TableDecorator { private let title: String init(title: String, source: UITableViewDataSource) { self.title = title super.init(source: source) } override func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? { guard section == 0 else { return nil } return title } } final class SingleSectionFooterTitle: TableDecorator { private let title: String init(title: String, source: UITableViewDataSource) { self.title = title super.init(source: source) } override func tableView(_ tableView: UITableView, titleForFooterInSection section: Int) -> String? { guard section == 0 else { return nil } return title } } final class MultipleSectionFooterTitle: TableDecorator { private let titles: [String] init(titles: [String], source: UITableViewDataSource) { self.titles = titles super.init(source: source) } override func tableView(_ tableView: UITableView, titleForFooterInSection section: Int) -> String? { guard section < titles.count else { return nil } return titles[section] } } |
The beauty of this solution is that now we can add behaviours to the core behaviour of our datasource, in a composable way. Each behaviour would be well encapsulated, which in turn means that it can be easily tested, and it could also be reused eventually.
And what is even better is that we can mix and match behaviours without modifying the code in the core datasource, and without adding any conditional logic.
For example, if we want a table with section header and no footer, we can do this:
|
1 2 3 4 5 6 7 8 9 10 |
let tableView = UITableView() let tasks = [ Task(title: "First"), Task(title: "Second"), Task(title: "Third") ] let data = FlatArrayDataManager(data: tasks) let required = Required(data: data, cellType: AwesomeCell.self) let sectionTitle = SingleSectionHeaderTitle(title: "Yo!", source: required) |
But if we want a table with header and section header and footer we can do this:
|
1 |
let sectionFooter = SingleSectionFooterTitle(title: "Fooooooter!!!", source: sectionTitle) |
And if for some reason we wanted a table with a section header that is a slight modification of the previous one, we could just add another decorator like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
final class EmojiHeader: TableDecorator { private let emoji: String init(emoji: String, source: UITableViewDataSource) { self.emoji = emoji super.init(source: source) } override func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? { guard section == 0 else { return nil } guard let title = source.tableView?(tableView, titleForHeaderInSection: section) else { return nil } return emoji + title } } let emoji = EmojiHeader(emoji: "♂️", source: sectionFooter) |
That is the way we can compose optional behaviours: by adding them one by one, as layers of an onion, to a core behaviour.
I have ambivalent feelings about Design Patterns. I do agree that these patterns tend to be overused, and I have found myself a few times at that stage where all you can see are design patterns everywhere, and you try to solve any possible problem with an implementation of the Visitor Pattern.
But if design patterns are taken as what I believe they are, which is just one more tool, being able to identify them, and being able to consider the trade-offs of implementing or not implementing them can make a huge difference in the quality of a codebase.
In this particular example, having a collection of highly cohesive, loosely coupled and highly testable behaviours, that can be applied to modify a core behaviour at will, seems like a win.
