Fun with protocols

Published May 29, 2017 by sexysoftwareengineer

Back in the old days, people used to communicate with each other by shouting.

struct Person {
    let name: String    
    
    func sendMesage(content: String) {
        print(content)
    }
}

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.

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)
    }
}

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.

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)
    }
}

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.”¹

So our hero started building her solution around an abstraction: a protocol defining a behaviour.

protocol Sendable {
    func send(message: String)
}

protocol Sendable {

func send(message: String)

}

That allowed our hero to model a couple of specific implementations of that behaviour ². 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)

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)
    }
}

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.³

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)
    }
}

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.

/**
 * 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")

/**

* 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.⁴

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.⁵

/**
 *  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)

/**

* 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.

Leave a Comment

Argument labels and parameter names

Published March 9, 2017 by sexysoftwareengineer

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:

final class Item {
    private let id: String
    
    init(id: String) {
        self.id = id
    }
}

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:

final class BetterItem {
    private let id: String
    
    init(id _id: String) {
        id = _id
    }
}

final class BetterItem {

private let id: String

init(id _id: String) {

id = _id

}

And client code would remain unchanged:

let item = Item(id: "First")
let betterItem = BetterItem(id: "Better item")

1 2	let item = Item(id: "First") let betterItem = BetterItem(id: "Better item")

I guess the lesson is, as always, know your tools.

Leave a Comment

Tableview datasources and the decorator pattern

Published February 19, 2017 by sexysoftwareengineer

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

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 solution I have been exploring

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:

struct Task {
    let title: String
}

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:

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
    }
}

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:

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
        }
    }
}

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:

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()
    }
}

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.

What was the problem again?

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.

The Decorator Pattern

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:

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()
    }
}

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:

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
}

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:

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]
    }
}

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:

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)

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:

let sectionFooter = SingleSectionFooterTitle(title: "Fooooooter!!!", source: sectionTitle)

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:

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)

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.

Final words

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.

Leave a Comment

Generics and specialisation

Published December 16, 2016 by sexysoftwareengineer

I am not a big fan of inheritance. I would never say something like “inheritance is evil”, because inheritance, like composition, is just one of the many tools we can reach for, but in my experience, designs based on inheritance tend to be very rigid.

But here is one particular use case where I think the combination of generics and inheritance can provide an interesting solution.

As usual, the example that tries to illustrate this post is not very good. But it is close to my real use case, so I am going to stick with it.

I try to avoid boilerplate as much as possible. That’s why I try to use a generic implementation of the datasource protocols (UITableViewDataSource and UICollectionViewDataSource) to feed all my listings. I even released those datasources as a framework!

The thing is, there is always going to be some particular listing that does not fit completely into that framework. In particular, those listings that require implementing one of the optional methods.

For example, let’s take a look at tableView:titleForHeaderInSection. Do we need a header in every single tableview? Not really, some table views might not even be sectioned.

That method does not seem something that would belong in a generic datasource, because, well, it is there to provide a solution to a very specific use case.

So we could have a generic implementation of the UITableViewDatasource protocol like this (bear in mind I have over simplified it, for brevity):

class DataSource<T>: NSObject, UITableViewDataSource {
    let data: [T]
    
    init(data: [T]) {
        self.data = data
    }
    
    func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return data.count
    }
    
    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        return UITableViewCell()
    }
}

struct Movie {
    let title: String
}

let movies = [Movie(title: "The Quiet Man"), Movie(title: "The Stagecoach") ]
let moviesDS = DataSource(data: movies)

struct Painter {
    let name: String
}

let painters = [Painter(name: "Picasso"), Painter(name: "Monet")]
let paintersDS = DataSource(data: painters)

class DataSource<T>: NSObject, UITableViewDataSource {

let data: [T]

init(data: [T]) {

self.data = data

}

func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

return data.count

}

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {

return UITableViewCell()

}

struct Movie {

let title: String

}

let movies = [Movie(title: "The Quiet Man"), Movie(title: "The Stagecoach") ]

let moviesDS = DataSource(data: movies)

struct Painter {

let name: String

}

let painters = [Painter(name: "Picasso"), Painter(name: "Monet")]

let paintersDS = DataSource(data: painters)

This is generic enough to cover most of our use cases. But know, what if we need to provide a header for a very specific table?

Here is where subclassing to specialise can be handy. Let’s say our “special” listing is the one that displays Appliances. We could do something like this:

struct Appliance {
    let name: String
}

final class ApplianceDataSource: DataSource<Appliance> {
    func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? {
        return "Hello, I'm your header"
    }
}

struct Appliance {

let name: String

}

final class ApplianceDataSource: DataSource<Appliance> {

func tableView(tableView: UITableView, titleForHeaderInSection section: Int) -> String? {

return "Hello, I'm your header"

}

And done. What is generic remains generic, what is specific to a particular data type remains encapsulated in one single class.

Of course, the next question would be “what happens if we want the specific case to apply to more than one type?”. Well, that would be a matter for a separate post…

Leave a Comment

How mutability bit my rear this past week

Published December 12, 2016 by sexysoftwareengineer

Mutability is dangerous and I have been aware of the fact for a long time. However, mutability can be sneaky, and make its way into the code without anyone noticing. Sometimes, with disastrous consequences.

First, a little disclaimer. I am a big fan of dependency injection. I have touched the subject in this very blog maybe too many times. I know it is not a golden bullet, I know it is not the solution to every problem, but still, I believe injecting dependencies is, in general, good.

Once that’s out of the way, let’s move on to today’s story. Imagine a view controller that needs to display data fetched from a backend. The integration with said backend is well encapsulated in a class, abstracted by an interface.

A simplified version of this view controller could look like this:

final class ViewController: UIViewController {
    private let data: DataService 

    init(nibName nibNameOrNil: String?,
                     bundle nibBundleOrNil: Bundle?,
                     data: DataService) {
        self.data = data
        super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
    }


    private func fetchData() {
        data.allItems { items in
            /**
            Provide data to a datasource, or present on screen directly, or...
            */
        }
    }
}

final class ViewController: UIViewController {

private let data: DataService

init(nibName nibNameOrNil: String?,

bundle nibBundleOrNil: Bundle?,

data: DataService) {

self.data = data

super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)

}

private func fetchData() {

data.allItems { items in

/**

Provide data to a datasource, or present on screen directly, or...

}

I like this approach: the view controller is provided with everything it needs to work in the constructor, the origin of the data is well abstracted (it could be a remote server, it could be a local database, it could be core data, we don’t care, because we don’t need to know).

But…

This view controller belongs to a storyboard. Dum dum duuuuum.

Here is another disclaimer. I am not a big fan of storyboards for multiple reasons (and the more I use them, the less I like them). But that does not change the fact that this view controller belongs to a storyboard.

So, now, in order to provide it the data service, you have to do something like this:

final class ViewController: UIViewController {
    var data: DataService?


    private func fetchData() {
        data?.allItems { items in
            /**
                Provide data to a datasource, or present on screen directly, or...
            */
        }
    }
}

final class ViewController: UIViewController {

var data: DataService?

private func fetchData() {

data?.allItems { items in

/**

Provide data to a datasource, or present on screen directly, or...

}

As far as I know, there is no way to avoid the fact that data can not be assigned a value when the view controller is instantiated. No matter how had I tried to work around it, like making the data variable private and providing a public setter, declaring that setter in a protocol and enforcing compliance in an extension, the fact is that, as far as I know, dataService needs to be a variable, and can not be set when this class is instantiated.

And that is a problem. Because if, for example, you have a segue that leads to this view controller, and you forget to set the value in an override prepareforSegue method, data is going to be nil and DataService.allItems() is not going to be called.

And if you have two segues that lead to this view controller, then you have to make sure that you set the value of data in two different places.

And that’s exactly how my rear got bit. I didn’t notice that second segue, so it was possible to instantiate this view controller without data being set.

You might argue, and you wouldn’t be wrong, that it is my fault, that I am the one that was not setting the value of a variable that is necessary for a part of the system to work properly. Yes, but…

If this class was really immutable (like it is in the first sample), the compiler would enforce that for me. If I do not provide a non-nil value to this view controller’s initialiser, the compiler will not build the project.

And that’s important. Because I am not good at remembering details, in particular details that I somehow consider that I should not need to remember.

In any system, in any codebase of a significant size, special cases, exceptions to the rule, and small details that you have to remember, are a recipe for disaster.

Thanks to multiple painful experiences, I have learnt that this apply to everything. If I need to change a url manually before submitting an app for review, there is going to be a moment when I am going to forget, and submit with the wrong url. If an API needs a parameter named data, and returns data in a parameter named values, sooner or later I am going to mess those up. And if I code a class in a way that it can be initialised in an inconsistent state, by code is going to find a way to initialise that class in the most inconsistent state possible.

I won’t day that “mutability is evil”. There is a place for it. But, this week, I got confirmation, one again, that the best way to avoid problems is allowing the compiler to help me as much as possible.

Leave a Comment

The right tool for the job

Published December 6, 2016 by sexysoftwareengineer

This post is about one of the Design Patterns, the Template Method. Except for the fact that, well, it is actually about somethign competely different.

Some time ago, in a galaxy far far away, the team I was with was building an internal framework. Our code was supposed to be an amalgamation of rainbows and unicorns that the rest of the company would use as a starting point to build highly customised projects. Yes, it didn’t end well.

But something today made reminisce of a particular episode in that era. Fair warning, some details have been changed to protect the innocent and or make my example a little more relevant.

We were building a video player. The requirements were quite simple: the UI should be easily customisable, and playback events should be trackable (i.e. play, pause, progress), and should be handled in a way that it should be easy to integrate with a second screen solution. Mind you, the company’s business domain was online video delivery, so as you could imagine, this was kind of a big deal.

So, off we went to build the thing, machete in hand and bug spray in pocket.

The key piece of the design was a “manager”, a block of logic that coordinated the playback status with the player’s UI state, while offering a default integration with a second screen solution (also developed in-house).

Now, and this is important, we needed to provide that integration with a second screen solution due to internal business reasons, but the design should be open enough so that other teams could provide their own integrations (i.e. AirPlay or Chromecast)

After some lively discussions we decided to provide what we believed complied with all the requirements.

So, this was, more or less, our manager, translated to Swift 3. Because those were still the Objective-C days.

open class VideoPlayer {
    init() {
        // initialize all the things
    }
    
    func playbackStarted() {
        // To be overriden
    }
    
    func playbackStopped() {
        // to be overriden
    }
    
    func playbackProgress() {
        // To be overriden
    }
    
    // Bunch of private methods here
    private func play() {
        // do stuff that needs to be done
        // And then allow subclasses to provide their own behaviour
        playbackStarted()
    }
}


class InHouseSecondScreenVideoPLayer {
    override func playbackStarted() {
        // Implementation that uses the in-house thingy
    }
    
    override func playbackStopped() {
        // Implementation that uses the in-house thingy
    }
    
    override func playbackProgress() {
        // Implementation that uses the in-house thingy
    }
}

open class VideoPlayer {

init() {

// initialize all the things

}

func playbackStarted() {

// To be overriden

}

func playbackStopped() {

// to be overriden

}

func playbackProgress() {

// To be overriden

}

// Bunch of private methods here

private func play() {

// do stuff that needs to be done

// And then allow subclasses to provide their own behaviour

playbackStarted()

}

class InHouseSecondScreenVideoPLayer {

override func playbackStarted() {

// Implementation that uses the in-house thingy

}

override func playbackStopped() {

// Implementation that uses the in-house thingy

}

override func playbackProgress() {

// Implementation that uses the in-house thingy

}

The idea was simple. We provided the bulk of the business logic in our manager, and subclasses of our manager should be provided for different integrations with second screen solutions.

Basically, we designed an system modelled after the Template Method Pattern.

If a team wanted to integrate this video player with Chromecast, they would just need to subclass our manager, override the extension points we had provided, and go on their merry way. If another team wanted to integrate with AirPlay, they could do the same.

But, what would happen if a team wanted to integrate with AirPlay and Chromecast?

Well, they could subclass our manager with an integration with Chromecast, and then subclass their Chromecast integration with an AirPlay integration that could call super as part of each method that it overrides.

And that’s my issue with this pattern: it is not exactly what I would consider a very open design.

So, what would be the alternative? As usual, it depends.
To begin with, this pattern can be extremely useful sometimes, and provide very elegant solutions to some problems.

But, in this case, and I guess in any case where an open design is the main goal, it might be better to define an interface for each behaviour that we want to be customisable, and inject them.

For example, we could change the previous design to something like this:

protocol SecondScreen {
    func playbackStarted()
    func playbackStopped()
    func playbackProgress()
}

final class InHouse: SecondScreen {
    func playbackStarted() {
        // Implementation that uses the in-house thingy
    }
    
    func playbackStopped() {
        // Implementation that uses the in-house thingy
    }
    
    func playbackProgress() {
        // Implementation that uses the in-house thingy
    }
}

final class Chromecast: SecondScreen {
    func playbackStarted() {
        // Implementation that uses Chromecast
    }
    
    func playbackStopped() {
        // Implementation that uses Chromecast
    }
    
    func playbackProgress() {
        // Implementation that uses Chromecast
    }
}

final class VideoPlayer {
    private let secondScreen: SecondScreen
    
    int(secondScreen: SecondScreen) {
        self.secondScreen = secondScreen
    }
    
    // Bunch of private methods here
    private func play() {
        // do stuff that needs to be done
        // And then allow let the second screen know
        secondScreen.playbackStarted()
    }
}

let player = VideoPlayer(InHouse())

protocol SecondScreen {

func playbackStarted()

func playbackStopped()

func playbackProgress()

}

final class InHouse: SecondScreen {

func playbackStarted() {

// Implementation that uses the in-house thingy

}

func playbackStopped() {

// Implementation that uses the in-house thingy

}

func playbackProgress() {

// Implementation that uses the in-house thingy

}

final class Chromecast: SecondScreen {

func playbackStarted() {

// Implementation that uses Chromecast

}

func playbackStopped() {

// Implementation that uses Chromecast

}

func playbackProgress() {

// Implementation that uses Chromecast

}

final class VideoPlayer {

private let secondScreen: SecondScreen

int(secondScreen: SecondScreen) {

self.secondScreen = secondScreen

}

// Bunch of private methods here

private func play() {

// do stuff that needs to be done

// And then allow let the second screen know

secondScreen.playbackStarted()

}

let player = VideoPlayer(InHouse())

The original design was not bad. This new design, however, has a couple advantages over the original design.

First, the manager and the different implementations of the second screens are more decoupled. The manager can work with multiple different implementation of the second screen, and those implementations of the second screen can collaborate with something other than the manager.

Second, these implementations of second screens are more cohesive, and therefore are going to be easier to test and maintain in the long term. And this part, in my experience, is extremely important. When classes do one thing and one thing only, and all the logic related to that thing is encapsulated in the same class, it is way easier to go back to it months after the code was written.

And third, and more important, now it is way easier to compose behaviours. For example (and I know this is a bad example, but it helps me illustrate my point), if we were asked to send play/stop events to both our InHouse solution and Chromecast and playback progress events only to Chromecast, we could reuse the implementations we already have, like this.

final class AllTogetherNow: SecondScreen {
    private let inHouse = InHouse()
    private let chromecast = Chromecast()
    
    
    func playbackStarted() {
        inHouse.playbackStarted()
        chromecast.playbackStarted()
    }
    
    func playbackStopped() {
        inHouse.playbackStopped()
        chromecast.playbackStopped()
    }
    
    func playbackProgress() {
        chromecast.playbackProgress()
    }
}

let player = VideoPlayer(AllTogetherNow())

final class AllTogetherNow: SecondScreen {

private let inHouse = InHouse()

private let chromecast = Chromecast()

func playbackStarted() {

inHouse.playbackStarted()

chromecast.playbackStarted()

}

func playbackStopped() {

inHouse.playbackStopped()

chromecast.playbackStopped()

}

func playbackProgress() {

chromecast.playbackProgress()

}

let player = VideoPlayer(AllTogetherNow())

So, I guess, the whole point of this post is “favour composition over inheritance”.

Except, of course, when inheritance provides a better solution to the problem at hand.

So, on second thought, I guess the whole point of this post is that there are trade offs to every approach. A good engineer should try to choose the approach the solves the problem better, with the information she has at hand at that particular moment.

Leave a Comment

Swift’s defaults params, for fun and profit

Published November 25, 2016 by sexysoftwareengineer

Note: This post has been seating in my drafts folder for months. It is about a topic that has been discussed over and over in this blog, but I still feel like it can add some kind of value. So here you have it.

Dependency Injection and the SOLID principles have become, one way or another, an important part of almost ever post in this blog. And today’s post is no exception.

In my experience, one of the biggest challenges when it comes to unit testing view controllers is, well, unit testing view controllers.

UIKit tends to make all of us lean towards the “one screen = one view controller” paradigm, which tends to make each and every one of those view controllers sort of a dark hole that swallows everything related to the screen it corresponds to.

Yes, as soon as a view controller starts doing more than just the thing it should do (controlling a view), and starts doing networking, navigation, model state validation, local persistency and whatever elese you throw at it, things begin to get complicated.

Code becomes tangled, SOLID principles are violated, stuff gets impossible to test, and kittens die.

Oh, no, my view controllers are doing too much!

Well, there is a solution for that: making view controllers do less. Which can be achieved with the help of our old friend, the Single Responsibility Principle. Tell us more about yourself, old friend!

Every module or class should have responsibility over a single part of the functionality provided by the software

Or, the way I understand it:

Every module or class should do just one thing

Or, in the dystopian words of George Orwell:

One thing good, more things bad!

Cool, but wasn’t this post about default parameters?

Indeed it was. And it still is.

The thing about default parameters is that we can use them to help us factor our code in a cleaner and more modular way.

Let’s say that we have a view controller that needs to present a list of Items, fetched from our backend.

We want our view controller to do just one thing, so we will extract the networking to a separate class. Actually, what we do is separate to a different module whatever is related with providing the view controller with the data it needs to display. (See? Single Responsibility Principle FTW!)

So, we could write our view controller like this:

final class List {
    let dataLoader = DefaultDataLoader()
    var dataSource: DataSource?

    overwrite func viewDidLoad() {
        dataLoader.load(completion: dataReceived)
    }

    private func dataReceived(data: [Item]?) {
        dataSource = DataSource(data: data)
        tableView.dataSource = dataSource
    }
}

final class List {

let dataLoader = DefaultDataLoader()

var dataSource: DataSource?

overwrite func viewDidLoad() {

dataLoader.load(completion: dataReceived)

}

private func dataReceived(data: [Item]?) {

dataSource = DataSource(data: data)

tableView.dataSource = dataSource

}

This solution is doing the Single Responsibility Thingy properly, but the dependency between List and DefaultDataLoader is hardcoded.

That is an issue, because it is safe to assume that DefaultDataLoader is somehow going to fetch data from the network. Which means that if I want to unit test List, I needs my tests to fetch data from the network, which is in between not optimal and plainly bad.

But why is networking in the tests bad? First, because there is no way to feed the unit tests with custom data, with data that we expect the view controller to handle in an specific way, for example.

Also, because unit tests should only have one reason to fail (again, the Single Responsibilty Principle, this thing is every-frikin’-where!), and doing networking introduces an extra factor for failure. Now a test ight fail because the production code is failing or because the rails server is down, or because the database is down, or because the office dog stepped over the router’s plug and disconnected it.

Oh, is that the bit about Dependency Injection?

Indeed, it is. Actually, it is more about Dependency Inversion, which happens to be the “D” in SOLID.

Depend upon abstractions, do not depend upon concretions.

Or quoting Napoleon and friends again:

Abstractions good, concretions bad!

In our previous example, List depends on a concretion: a specific instance of DefaultDataLoader. That deendency is hardcoded, and it can not be changed after compilation.

Let’s make List depend on an abstraction. One of the tools we have to model abstractions in Swift, line in many other languages, is protocols (interfaces).

So, let’s begin by defining a DataLoader protocol, by just extracting the public API of the DefaultDataLoader class:

protocol DataLoader {
    func load(completion:([Item]?)-> Void)
}

final class DefaultDataLoader: DataLoader {
   func load(completion:([Item]?)-> Void) {
    // Do whatever is necessary to fetch data from the backend
   }
}

protocol DataLoader {

func load(completion:([Item]?)-> Void)

}

final class DefaultDataLoader: DataLoader {

func load(completion:([Item]?)-> Void) {

// Do whatever is necessary to fetch data from the backend

}

Now, we can inject that dependency into the List class:

final class List {
    let dataLoader: DataLoader
    var dataSource: DataSource?

    init(dataLoader: DataLoader) {
        self.dataLoader = dataLoader
    }

    overwrite func viewDidLoad() {
        dataLoader.load(completion: dataReceived)
    }

    private func dataReceived(data: [Item]?) {
        dataSource = DataSource(data: data)
        tableView.dataSource = dataSource
    }
}

final class List {

let dataLoader: DataLoader

var dataSource: DataSource?

init(dataLoader: DataLoader) {

self.dataLoader = dataLoader

}

overwrite func viewDidLoad() {

dataLoader.load(completion: dataReceived)

}

private func dataReceived(data: [Item]?) {

dataSource = DataSource(data: data)

tableView.dataSource = dataSource

}

Dependency Injection is a 20 dollar word for a 20 cent concept. I wish I had come up with that quote, but I didn’t.

But the point is that DI is as simple as that. If class A needs to use class B, pass to class A a reference to class B.

Why do we type it as an interface though? Well, because we want to rely on abstractions, not concretions, remember? And also, because…

Finally! Here comes the ta-dah!

Indeed it comes. The way List looks now, we would need to do somethign like this when initializing it:

let dataLoader = DefaultDataLoader()
let list = List(dataLoader: dataLoader)

1 2	let dataLoader = DefaultDataLoader() let list = List(dataLoader: dataLoader)

Or if you have a thing for one liners:

let list = List(dataLoader: DefaultDataLoader())

1	let list = List(dataLoader: DefaultDataLoader())

Which is fine, but can become annoying if we only need to provide one concrete implementation of DataLoader. And also because, and we are splitting hairs here, that code could look cleaner and read simpler.

And, finally, this is where we get to discuss default values in parameters.

Let’s rewrite the List initializer like this:

final class List {
    let dataLoader: DataLoader
    var dataSource: DataSource?

    init(dataLoader: DataLoader = DefaultDataLoader()) {
        self.dataLoader = dataLoader
    }

    overwrite func viewDidLoad() {
        dataLoader.load(completion: dataReceived)
    }

    private func dataReceived(data: [Item]?) {
        dataSource = DataSource(data: data)
        tableView.dataSource = dataSource
    }
}

final class List {

let dataLoader: DataLoader

var dataSource: DataSource?

init(dataLoader: DataLoader = DefaultDataLoader()) {

self.dataLoader = dataLoader

}

overwrite func viewDidLoad() {

dataLoader.load(completion: dataReceived)

}

private func dataReceived(data: [Item]?) {

dataSource = DataSource(data: data)

tableView.dataSource = dataSource

}

Now, to create an instance of List:

let list = List()

1	let list = List()

It literally, doesn’t get any simpler than that.

But the best is jet to come.

BYOM (Bring Your Own Mock)

Remember what we discussed about unit tests? Yes, unit tests should not hit the network, and we shoud be able to mock data fetched from the network.

Well, the thing is we can unit test List mocking data like this:

@testable import MyModule
import XCTest

final class MockLoader: DataLoader {
    private struct Constants {
       static let unicorn = Item(id: "")
       static let rainbow = Item(id: "")
    }

    func load(completion: ([Item]?) -> Void) {
       completion([Constants.unicorn, Constants.rainbow])
    }
}

final class MediaUsedListTests: XCTestCase {
    private var list: List?

    override func setUp() {
        super.setUp()
        list = MediaUsedList(dataLoader: MockLoader())
    }

    override func tearDown() {
       list = nil
       super.tearDown()
    }

   func testWhatNot() {
       let something = list.whatever()

       XCTAssertEqual(something, 23)
   }
}

@testable import MyModule

import XCTest

final class MockLoader: DataLoader {

private struct Constants {

static let unicorn = Item(id: "")

static let rainbow = Item(id: "")

}

func load(completion: ([Item]?) -> Void) {

completion([Constants.unicorn, Constants.rainbow])

}

final class MediaUsedListTests: XCTestCase {

private var list: List?

override func setUp() {

super.setUp()

list = MediaUsedList(dataLoader: MockLoader())

}

override func tearDown() {

list = nil

super.tearDown()

}

func testWhatNot() {

let something = list.whatever()

XCTAssertEqual(something, 23)

}

This is Good, with a capital G, because we can provide List with whatever data set we need in order to tests its behaviour, without hitting the wire.

Leave a Comment

Program to an interface, not an implementation

Published November 14, 2016 by sexysoftwareengineer

Something happened today that made me go back to a long long time ago, in a continent far far away, when my mentor at the time said to me “program to an interface, not to an implementation”, and I found myself googling (actually, yahooing, it was that long long ago) what that could possibly mean.

It took me years to have a basic grasp of what he meant. And, as I mentioned, today I read some code that made recall that moment.

Let’s say that we are working on an app that needs to save some data locally. Let’s keep things simple and let’s say we need to save a username locally, to pre-populate a login form.

The simplest thing that could possibly work would be something like this:

final class LoginScreen: UIViewController {
    @IBOutlet weak var username: UILabel!
    //Save the username
    private func save() {
        if let name = username.text {
            let defaults = UserDefaults.standard
            defaults.setValue(name, forKey: "username")
        }
    }
    
    //Read the username
    private func read() {
        let defaults = UserDefaults.standard
        if let name = defaults.value(forKey: "username") as? String {
            username.text = name
        }
    }
}

final class LoginScreen: UIViewController {

@IBOutlet weak var username: UILabel!

//Save the username

private func save() {

if let name = username.text {

let defaults = UserDefaults.standard

defaults.setValue(name, forKey: "username")

}

//Read the username

private func read() {

let defaults = UserDefaults.standard

if let name = defaults.value(forKey: "username") as? String {

username.text = name

}

But now, once we are saving and retrieving the user name, it would not be completely unexpected if we were asked to display that username someplace else. Let’s say, for example, why not, that in a splash screen

final class SplashScreen: UIViewController {
    @IBOutlet weak var username: UILabel!
    
    override func viewDidLoad() {
        let defaults = UserDefaults.standard
        if let name = defaults.value(forKey: "username") as? String {
            username.text = name
        }
    }
}

final class SplashScreen: UIViewController {

@IBOutlet weak var username: UILabel!

override func viewDidLoad() {

let defaults = UserDefaults.standard

if let name = defaults.value(forKey: "username") as? String {

username.text = name

}

I guess by now you already see the problem.

We are duplicating code. And duplicating code is not good.

But, even if we were not duplicating code, there is another issue here, way more subtle in my opinion.

And the issue is that the code is Snippet 1 is highly procedural, and it is a clear example of programming to an implementation, and not to an interface.

Programming to an implementation

The code in sample 1 is highly imperative and extremely specific. It lacks any abstraction.

We are aware, and we express that clearly in the code, that the username is going to be stored in the user defaults. Not only that, we make the LoginScreen class aware of that fact, and what is worse, we make it also aware of how saving stuff to user defaults work, in painful detail.

This code was easy to write, but the fact that we are exposing the details of how the username is saved is going to be a guaranteed source of pain.

What would happen if we needed to save, for example, the user’s phone number as well? Or his score (if this was a game)? Or an authentication token? And what if we also need to display any of that data in more that one place? We would scatter our source code with extremely specific references to the way we read/write that data.

Programming to an interface

The way I see it, programming to an interface is avoiding implementation details to be known by anyone that should not be aware of said details. And the way to achieve that, is by making my code as declarative as possible.

So, what do we have here? We have data that can be used to identify a User, and we need behaviour to make that data persist between app sessions.

Model objects

So, the first thing to do is identify the Model. In this example, the model is not a username or a telephone number, or a token, it is the abstraction that groups all of those together: a User.

So, let’s declare a User:

struct User {
    let name: String
    let phone: String
}

struct User {

let name: String

let phone: String

}

Abstract behaviours

Now, what do we need to do with that User? Persist it. Do we need to know how to persist it? No, we don’t. Do we need to know if we save it to UserDefaults, to a remote server, or to the Keychain? No, we don’t.

And this is the whole point of this post: more often than not, we don’t need to know how something is done, we just need to know that something is going to get done. In this case, we don’t need to know how the user’s data is going to be saved, all we need is to know that someone is going to take care of having that data available for us when we need it.

That way, we shift from writing step by step descriptions of what to do, to write high-level expectations of how things should collaborate with each other. We shift from imperative, to declarative code.

So, what’s the behaviour here? If we describe what we need in the most possible abstract way, we need User data to be available.

Abstract stuff, in Swift, like in any other OO language, is the domain of interfaces. In Swift, though, we call the Protocols.

protocol DataStore {
    func save(user: User)
    func read() -> User?
}

protocol DataStore {

func save(user: User)

func read() -> User?

}

And protocols need an implementation:

final class LocalStore: DataStore {
    func save(user: User) {
        let defaults = UserDefaults.standard
        defaults.setValue(user.name, forKey: "username")
        defaults.setValue(user.phone, forKey: "phone")
    }
    
    func read() -> User? {
        let defaults = UserDefaults.standard
        guard let name = defaults.value(forKey: "username") as? String,
        let phone =  defaults.value(forKey: "phone") as? String else {
            return nil
        }
        
        return User(name: name, phone: phone)
    }
}

final class LocalStore: DataStore {

func save(user: User) {

let defaults = UserDefaults.standard

defaults.setValue(user.name, forKey: "username")

defaults.setValue(user.phone, forKey: "phone")

}

func read() -> User? {

let defaults = UserDefaults.standard

guard let name = defaults.value(forKey: "username") as? String,

let phone = defaults.value(forKey: "phone") as? String else {

return nil

}

return User(name: name, phone: phone)

}

Now, the original code would look like this:

final class LoginScreen: UIViewController {
    @IBOutlet weak var username: UILabel!
    @IBOutlet weak var phone: UILabel!
    
    private let storage: DataStore = LocalStore()
    //Save the username
    private func save() {
        guard let name = username.text,
            let phone = phone.text else {
            return
        }
        let user = User(name: name, phone: phone)
        storage.save(user: user)
    }
    
    //Read the username
    private func read() {
        if let user = storage.read() {
            username.text = user.name
            phone.text = user.phone
        }
    }
}

final class LoginScreen: UIViewController {

@IBOutlet weak var username: UILabel!

@IBOutlet weak var phone: UILabel!

private let storage: DataStore = LocalStore()

//Save the username

private func save() {

guard let name = username.text,

let phone = phone.text else {

return

}

let user = User(name: name, phone: phone)

storage.save(user: user)

}

//Read the username

private func read() {

if let user = storage.read() {

username.text = user.name

phone.text = user.phone

}

Which is better, if you only look at the save() and read() methods.

In fact, you might be wondering if we are actually in a better position now. We have written a protocol, to abstract things, but after all, in LoginScreen we create a concrete class to implement it. And you would be right, if it wasn’t for the coming step.

If we pass LoginScreen the actual implementation of the DataStore protocol that we want it to use, LoginScreen wouldn’t actually know who or how is saving and fetching data. That is called “inverting the dependency”. And I have written about it a couple times before.

final class LoginScreen: UIViewController {
    @IBOutlet weak var username: UILabel!
    @IBOutlet weak var phone: UILabel!
    
    private let storage: DataStore
    
    init(storage: DataStore, nibName: String?, bundle: Bundle?) {
        self.storage = storage
        super.init(nibName: nibName, bundle: bundle)
    }
    
    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    private func save() {
        guard let name = username.text,
            let phone = phone.text else {
                return
        }
        let user = User(name: name, phone: phone)
        storage.save(user: user)
    }
    
    //Read the username
    private func read() {
        if let user = storage.read() {
            username.text = user.name
            phone.text = user.phone
        }
    }
}

final class LoginScreen: UIViewController {

@IBOutlet weak var username: UILabel!

@IBOutlet weak var phone: UILabel!

private let storage: DataStore

init(storage: DataStore, nibName: String?, bundle: Bundle?) {

self.storage = storage

super.init(nibName: nibName, bundle: bundle)

}

required init?(coder aDecoder: NSCoder) {

fatalError("init(coder:) has not been implemented")

}

private func save() {

guard let name = username.text,

let phone = phone.text else {

return

}

let user = User(name: name, phone: phone)

storage.save(user: user)

}

//Read the username

private func read() {

if let user = storage.read() {

username.text = user.name

phone.text = user.phone

}

Now we are getting somewhere. We have one abstraction (DataStore) and we have a class (LoginScreen) that is provided with a concrete, and unknown to it, implementation of that abstraction. We have shifted from something extremely specific and imperative (LoginScreen saving and reading to user defaults) to something abstract and declarative (LoginScreen asks DataStore to save or fetch data, not caring about how it does it).

And, to me, that is what “program to an interface, not an implementation” means.

Leave a Comment

Replacing Type Code with Polymorphism

Published October 17, 2016 by sexysoftwareengineer

Note: In this post I use the terms class, struct and entity to refer to the same thing. Please bear with me!

Replacing type code with polymorphism is one of those refactoring that are, literally, in the book. However, opportunities to refactor to polymorphism can often times be difficult to identify.

Let’s say that we are working on a SaaS system. The system has different account tiers, with different denomination, different prices, and different capabilities.

To be a little bit more specific, let’s assume just to simplify this post, that our service tracks workouts. There are three account tiers: Free, Plus and Premium, according to the following:

Free account:
– Price: free (duh!)
– Can track: runs, hikes and walks
– Number of workouts: 20 per month

Plus account:
– Price: 2 USD a month
– Can track: Everything supported by the Free Tier plus biking, swimming
– Number of workouts: 50 per month

Premium account:
– Price: 10 USD a month
– Can track: Everything supported by the Plus Tier plus yoga, pilates and roller derby.
– Number of workouts: unlimited.

So, a first attempt at implementing this model might look like this:

enum Workout {
    case running
    case hiking
    case walking
    case biking
    case swimming
    case yoga
    case pilates
    case rollerDerby
}

struct Account {
    enum Tier {
        case free
        case plus
        case premium
    }
    
    let id: String
    let tier: Tier   
}

enum Workout {

case running

case hiking

case walking

case biking

case swimming

case yoga

case pilates

case rollerDerby

}

struct Account {

enum Tier {

case free

case plus

case premium

}

let id: String

let tier: Tier

}

Now let’s imagine that we want to present the number of workouts that can be still tracked in the current month in one of our views. Given the previous model, we could do something like this:

final class Current: UIViewController {
    /**
     Returns number of available workouts, according to the user's account tier, to be presented on screen
    */
    func workoutsAvailable(account: Account) -> String {
        let returnValue: String
        switch account.tier {
        case .free:
            returnValue = "20"
            break
        case .plus:
            returnValue = "50"
            break
        case .premium:
            returnValue = "unlimited"
            break
        }
        
        return returnValue
    }
}

final class Current: UIViewController {

/**

Returns number of available workouts, according to the user's account tier, to be presented on screen

func workoutsAvailable(account: Account) -> String {

let returnValue: String

switch account.tier {

case .free:

returnValue = "20"

break

case .plus:

returnValue = "50"

break

case .premium:

returnValue = "unlimited"

break

}

return returnValue

}

I guess you immediately recognise an issue here: the logic in the workoutsAvailable function should be part of the Account object.

There are multiple reasons for that. First, well, that logic is part of the Account abstraction. Second, if we need to present the number of available workouts in two different places in the UI, we would have to duplicate that logic.

So, let’s do the right thing and move that code to the Account entity

enum Workout {
    case running
    case hiking
    case walking
    case biking
    case swimming
    case yoga
    case pilates
    case rollerDerby
}

struct Account {
    enum Tier {
        case free
        case plus
        case premium
    }
 
    let id: String
    let tier: Tier
 
    var workoutsAvailable: String {
        let returnValue: String
        switch tier {
        case .free:
            returnValue = "20"
            break
        case .plus:
            returnValue = "50"
            break
        case .premium:
            returnValue = "unlimited"
            break
        }
        
        return returnValue
    }
 }

final class Current: UIViewController {
    /**
     Returns number of available workouts, according to the user's account tier, to be presented on screen
     */
    func workoutsAvailable(account: Account) -> String {
        return account.workoutsAvailable
    }
}

enum Workout {

case running

case hiking

case walking

case biking

case swimming

case yoga

case pilates

case rollerDerby

}

struct Account {

enum Tier {

case free

case plus

case premium

}

let id: String

let tier: Tier

var workoutsAvailable: String {

let returnValue: String

switch tier {

case .free:

returnValue = "20"

break

case .plus:

returnValue = "50"

break

case .premium:

returnValue = "unlimited"

break

}

return returnValue

}

final class Current: UIViewController {

/**

Returns number of available workouts, according to the user's account tier, to be presented on screen

func workoutsAvailable(account: Account) -> String {

return account.workoutsAvailable

}

It is obvious that the way clients of the Account entity can present the number of available workouts is simpler now. That is important for many different reasons, but to men the most important is readability. Reading and understanding the code in the Current.workousAvailable function takes a second, because there is no complicated logic to understand in there. And as a bonus, when there is no complicated logic to read and understand, it is more difficult to make mistakes.

But now, we also need to present the monthly price in the UI. given our previous experience with the number of available workouts, we might go directly to add that logic to the Account struct

enum Workout {
    case running
    case hiking
    case walking
    case biking
    case swimming
    case yoga
    case pilates
    case rollerDerby
}


struct Account {
    enum Tier {
        case free
        case plus
        case premium
    }
    
    let id: String
    let tier: Tier
    
    var workoutsAvailable: String {
        let returnValue: String
        switch tier {
        case .free:
            returnValue = "20"
            break
        case .plus:
            returnValue = "50"
            break
        case .premium:
            returnValue = "unlimited"
            break
        }
        
        return returnValue
    }
    
    var price: String {
        let returnValue: String
        switch tier {
        case .free:
            returnValue = "Free"
            break
        case .plus:
            returnValue = "2 USD"
            break
        case .premium:
            returnValue = "10 USD"
            break
        }
        
        return returnValue
    }
}

enum Workout {

case running

case hiking

case walking

case biking

case swimming

case yoga

case pilates

case rollerDerby

}

struct Account {

enum Tier {

case free

case plus

case premium

}

let id: String

let tier: Tier

var workoutsAvailable: String {

let returnValue: String

switch tier {

case .free:

returnValue = "20"

break

case .plus:

returnValue = "50"

break

case .premium:

returnValue = "unlimited"

break

}

return returnValue

}

var price: String {

let returnValue: String

switch tier {

case .free:

returnValue = "Free"

break

case .plus:

returnValue = "2 USD"

break

case .premium:

returnValue = "10 USD"

break

}

return returnValue

}

(As a side note, the price should not be typed as a string, but as another struct called Currency, with two properties: the value and the unit it is measured in. But that’s beyond the scope of this post)

Now, notice how the Account struct is basically has the same logic duplicated in two calculated properties. Now, if we add the supported workout types to the mix, we would have three different properties implementing more or less the same logic.

We are turning our Account abstraction into something that can do three different things, depending on a type parameter.

We have code that affects the behaviour of a class, according to an internal enumeration. That is a good indicator that, maybe, the Account struct should be broken down into different classes, each and every one of them modelling only one of those behaviours.

So here is where the refactoring in the post title comes to help.

What do we really need our accounts to provide? Price, number of workouts and a boolean that tells us if that account can track a particular workout type.

Let’s model that as a protocol:

enum Workout {
    case running
    case hiking
    case walking
    case biking
    case swimming
    case yoga
    case pilates
    case rollerDerby
}

protocol Account {
    var workoutsAvailable: String { get }
    var price: String { get }
    func canTrack(workout: Workout) -> Bool
}

enum Workout {

case running

case hiking

case walking

case biking

case swimming

case yoga

case pilates

case rollerDerby

}

protocol Account {

var workoutsAvailable: String { get }

var price: String { get }

func canTrack(workout: Workout) -> Bool

}

Now, and this also might be a matter for another post, there is something in that protocol that I find a little bit annoying: the lack of symmetry. So I am going to refactor it to:

enum Workout {
    case running
    case hiking
    case walking
    case biking
    case swimming
    case yoga
    case pilates
    case rollerDerby
}

protocol Account {
    func workoutsAvailable() -> String
    func price()-> String
    func canTrack(workout: Workout) -> Bool
}

enum Workout {

case running

case hiking

case walking

case biking

case swimming

case yoga

case pilates

case rollerDerby

}

protocol Account {

func workoutsAvailable() -> String

func price()-> String

func canTrack(workout: Workout) -> Bool

}

Now, I shall provide a different implementation of this protocol for each account tier:

enum Workout {
    case running
    case hiking
    case walking
    case biking
    case swimming
    case yoga
    case pilates
    case rollerDerby
}

protocol Account {
    func workoutsAvailable() -> String
    func price()-> String
    func canTrack(workout: Workout) -> Bool
}

struct Free: Account {
    func workoutsAvailable() -> String {
        return "20"
    }
    
    func price()-> String {
        return "Free"
    }
    
    func canTrack(workout: Workout) -> Bool {
        return (workout == .running ||
                workout == .hiking ||
                workout == .walking)
    }
}

struct Plus: Account {
    func workoutsAvailable() -> String {
        return "50"
    }
    
    func price()-> String {
        return "2 USD"
    }
    
    func canTrack(workout: Workout) -> Bool {
        return (Free().canTrack(workout: workout) ||
                workout == .biking ||
                workout == .swimming)
    }
}

struct Premium: Account {
    func workoutsAvailable() -> String {
        return "Unlimited"
    }
    
    func price()-> String {
        return "10 USD"
    }
    
    func canTrack(workout: Workout) -> Bool {
        return true
    }
}

enum Workout {

case running

case hiking

case walking

case biking

case swimming

case yoga

case pilates

case rollerDerby

}

protocol Account {

func workoutsAvailable() -> String

func price()-> String

func canTrack(workout: Workout) -> Bool

}

struct Free: Account {

func workoutsAvailable() -> String {

return "20"

}

func price()-> String {

return "Free"

}

func canTrack(workout: Workout) -> Bool {

return (workout == .running ||

workout == .hiking ||

workout == .walking)

}

struct Plus: Account {

func workoutsAvailable() -> String {

return "50"

}

func price()-> String {

return "2 USD"

}

func canTrack(workout: Workout) -> Bool {

return (Free().canTrack(workout: workout) ||

workout == .biking ||

workout == .swimming)

}

struct Premium: Account {

func workoutsAvailable() -> String {

return "Unlimited"

}

func price()-> String {

return "10 USD"

}

func canTrack(workout: Workout) -> Bool {

return true

}

Now, each struct models a simple behaviour. There is more code, true, but the code is dumber, simpler. Each logical unit (struct) model a single behaviour. That makes the code easier to read, easier to understand, and therefore more robust and easier to maintain.

Leave a Comment

My take on iOS app architecture

Published October 15, 2016 by sexysoftwareengineer

TL;DR;

iOS apps have a single entry point. That single entry point can create and hold a reference to whatever we need to be global, and then inject it everywhere.

Object Oriented Design, or Architecture if you will, is a daunting topic. I believe there is never a right or wrong way to architect a software project, because the number of tradeoffs to consider is huge, so what works for a project might not be the optimal solution for the next one.

That being said, I do believe there are a basic set of practices that help build highly cohesive and decoupled code: single responsibility principle, modularity, a set of domain model objects, and dependency injection.

To illustrate my point, let’s discuss at a very simple app, that reads and writes data from and to a backend. I guess that, conceptually, covers almost 100% of the apps that are developed these days. Let’s say it is a todo list.

Domain model objects

The first step would be looking at the domain (the problem we are trying to solve) and come up with a set of abstractions that model the entities that are part of it.

In our example, we want to display todo’s, create todo’s, present a list of todo’s, and maybe share todo’s… I guess by now we all can see a model object emerging: Todo

struct Todo {
    let id: String
    let title: String
    let due: Date
}

struct Todo {

let id: String

let title: String

let due: Date

}

Data manipulation.

We need to send Todos to a backend. And we need to read Todos from a backend as well. That probably implies dealing with network requests, and also with a good deal of JSON (or protocol buffers).

We don’t want to scatter those responsibilities across the codebase, even if it is just because network operations have to be done in a background thread, to avoid blocking the UI, so it makes sense to deal with all that async calls in just one place.

But, we have a difficult solution here: that one thing dealing with networking will have to be used from multiple places

A common solution to this problem is making the Thing That Handles Networking a singleton. (Note: Since I wrote the first draft of this post, three weeks ago, Soroush Khanlou wrote this excellent post about refactoring out those singletons. Go read it now!)

Singletons, per se, are neither good nor bad. Sometimes, something is a singleton and it makes sense to model it as such.

But, in my experience, it is better to move away from them, for one reason in particular: a singleton is a global variable, and as such it is a dependency that is very hard to get rid of.

Dependency Inversion

But what if we invert that dependency? And we have a huge advantage here: the iOS app architecture.

An iOS app has a single entry point (the AppDelegate, an implementation of the AppDelegate protocol).

That ensures that instances variables of the AppDelegate are going to be unique as well. Well, not completely, but let’s say that we can guarantee that an instance of a regular class is created once and only once.

You might say, and you would be right, that there is nothing preventing a developer from creating as many instances of that class as she wants. I believe the solution to that is, as Uncle Bob said, well, just create one.

Back to Data Manipulation

Another look at the domain will tell us that we want to:
– obtain a list of Todos
– obtain a Todo
– create a new Todo
– edit an existing Todo
– delete a Todo

This nothing more than a list of high level operations. We don’t really care, or need to care, at this stage about how those operations are actually implemented, so we can just declare them as a protocol.

typealias SingleTodo = (Todo?) -> Void
typealias MultipleTodo = ([Todo]?) -> Void

protocol TodoService {
    func all(completion: MultipleTodo)
    func todo(id: String, completion: SingleTodo)
    
    func save(todo: Todo)
    func delete(todo: Todo)
}

typealias SingleTodo = (Todo?) -> Void

typealias MultipleTodo = ([Todo]?) -> Void

protocol TodoService {

func all(completion: MultipleTodo)

func todo(id: String, completion: SingleTodo)

func save(todo: Todo)

func delete(todo: Todo)

}

Notice how this protocol abstracts two different responsibilities: reading and writing. This is a hint that, eventually, we might need to split the protocol in two (again, this post provides a great discussion of why it might be a good idea to do so).

However, I am not going to do it right now, in part because it is one of the points I want to make: modularity, good separation of concerns, empowers us to further break things down whenever we things it is the right moment to do so.

Now all we have to do is provide an implementation of that protocol to our UI. And the easiest way to do that is, again, relying on the fact that we have a single entry point (the App Delegate), and applying the Dependency Inversion principle. Or, if you will, inject all the things!

So a typical AppDelegate looks like this:

class AppDelegate: UIResponder, UIApplicationDelegate {
    var window: UIWindow?
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        // Init UI here
        return true
    }
}

class AppDelegate: UIResponder, UIApplicationDelegate {

var window: UIWindow?

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {

// Init UI here

return true

}

I am not very fond of storyboards, so I usually have a class whose responsibility is bootstrapping the UI, creating the root view controller, the navigation logic (if necessary) and preparing both for collaboration.

I create that bootstrapping logic in the App Delegate, and I would also create an instance of my service, and inject it into the bootstrapping logic:

final class DefaultTodoService: TodoService {
    // Implementation of the TodoService protocol
}

final class AppDelegate: UIResponder, UIApplicationDelegate {
    var window: UIWindow?
    let service = DefaultTodoService()
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        window = UIWindow(frame: UIScreen.main.bounds)
        
        Bootstrap(data:service).start(window: window)
        
        return true
    }
}

final class DefaultTodoService: TodoService {

// Implementation of the TodoService protocol

}

final class AppDelegate: UIResponder, UIApplicationDelegate {

var window: UIWindow?

let service = DefaultTodoService()

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {

window = UIWindow(frame: UIScreen.main.bounds)

Bootstrap(data:service).start(window: window)

return true

}

And then my data service can be injected into any view controller:

final class TodoList: UIViewController {
    private let data: TodoService
    
    init(nibName nibNameOrNil: String?,
         bundle nibBundleOrNil: Bundle?,
         data: TodoService) {
        self.data = data
        super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
    }
}

final class TodoList: UIViewController {

private let data: TodoService

init(nibName nibNameOrNil: String?,

bundle nibBundleOrNil: Bundle?,

data: TodoService) {

self.data = data

super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)

}

Is this approach future-proof?

Nothing is completely future-proof, but I think this approach is flexible enough, and to me, it remains open enough for modification and extension.

There is good separation of concerns. There is one thing that deals with data (fetching and saving), there is one thing that creates UI, and there might or might not be one thing that handles navigation.
There is good modularity. Any of those things in the previous bullet point can be refactored and split into smaller pieces, if necessary. There is a clearly defined interface in between them, so if, say, I noticed that the implementation of my TodoService is starting to mic business logic and pure data transport, I can break it down in two.
There is good testability. Since I am injecting the TodoService into each view controller that needs to collaborate with it, I can inject a mock in my tests.

I have found that by pursuing a dependency graph in the form of a tree, where the root node is the App Delegate, I have more room for adapting to changing requirements, and I can factor and test my code better.

Leave a Comment

The Amazing Adventures of a Sexy Software Engineer Posts

The problem

The solution I have been exploring

What was the problem again?

The Decorator Pattern

Final words

Programming to an implementation

Programming to an interface

Model objects

Abstract behaviours

TL;DR;

Domain model objects

Data manipulation.

Dependency Inversion

Back to Data Manipulation

Is this approach future-proof?