Swift: Extensions

swift extensions

Like categories in Objective-C, extensions in Swift give you the opportunity to add functionality to a type. This is not only possible for your own types, but also for types for which you don’t have access to the source code.

Hint: This post is using Swift 3 and Xcode 8.3.3

How do extensions work?

So basically it’s very straightforward. Let’s look at an example:

In this example, we have created an extension for Int. On every Int value there is now another function available, that returns the doubled value.

It’s also possible to modify the type itself. If an extension’s function does that, it has to use the mutating  keyword:

You can also create extensions for classes:

In this example we’ve declared a function and a computed property. It’s not possible to declare a stored property or override a function though.

Furthermore, an extension is allowed to confirm to a protocol. Then, the extension has to implement all the protocol’s functions, if the class doesn’t do so already:

As you can see, defining extensions is very straightforward. Now let’s discuss when and how you should use them.

Using extensions for types for which you don’t have access to the source code

If you want to add functionality to a type for which you don’t have access to the source code, extensions are great! Of course there are other possibilities like subclassing or wrapping that type, but in these cases you have to use another type. By using extensions, you can use the original type and you are still able to add that functionality.

This applies to both types that are defined in Apple’s framework and types from third party frameworks.

Using extensions for your own types

So it’s very clear why you want to use extensions for types for which you don’t have access to the source code. Using it for your own code may sound strange in the first place though – after all you could add the behaviour directly to the type.

One reason why you still want to do this is because you are sharing code between several projects. In this case, it may be the cleaner approach to just add the app specific behaviour by using an extension.

Another reason for using extensions is readability and structure. By grouping functions and computed properties into extensions on its own, the actual type has much less code and it’s more clear what’s going on. So in a way, extensions can serve as pragma marks, but in a much more structured way.

A good example for this is using extensions for implementing an UITableViewDataSource.

UITableView example

View controllers tend to become very massive, and I’ve talked about this already in this post. In that post, I propose to create a class on its own, that act as an UITableViewDataSource – and I still like that approach:

But there is also another possibility: You can just write an extension of your view controller and put all the UITableViewDataSource’s methods inside it. Even if you don’t move it to a file on its own – which is possible – your view controller’s code will be structured much better. Take a look at an example:

So which approach is the better one – using an extension or a class on its own? It depends on what you want to achieve. If you want to use your data source for more than one table view, the reusability of the class approach is of course much better. In most cases that will not happen though – simply because different table views tend to be different in both their behaviour and appearance.

By using the class approach, this class can also provide the data. If you are using an extension, that’s not possible because extensions cannot add stored properties.

To make it short in a way, in most cases it’s absolutely fine to take the extensions approach when it comes to separating your UITableViewDataSource’s code from the corresponding view controller. And of course that holds true for other protocols as well.

Title image: @ maradon 333 / shutterstock.com

1 comment

Comments are closed