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:

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

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:

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.

And protocols need an implementation:

Now, the original code would look like this:

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.

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.

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:

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:

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

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

(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:

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:

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

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.

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

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.

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:

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:

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

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.