How to properly use class extensions in Swift?

Question

In Swift, I have historically used extensions to extend closed types and provide handy, logic-less functionality, like animations, math extensions etc. However, since extensions are hard dependencies sprinkled all over your code-base, I always think three times before implementing something as an extension.

Lately, though, I have seen that Apple suggests using extensions to an even greater extent, e.g. implementing protocols as separate extensions.

That is, if you have a class A that implement protocol B, you end up with this design:

class A {
    // Initializers, stored properties etc.
}

extension A: B {
    // Protocol implementation
}

As you enter that rabbit-hole, I started seeing more extension-based code, like:

fileprivate extension A {
    // Private, calculated properties
}

fileprivate extension A {
    // Private functions
}

One part of me likes the building-blocks you get when you implement protocols in separate extensions. It makes the separate parts of the class really distinct. However, as soon as you inherit this class, you will have to change this design, since extension functions cannot be overridden.

I think the second approach is...interesting. Once great thing with it is that you do not have to annotate each private property and function as private, since you can specify that for the extension.

However, this design also splits up stored and non-stored properties, public and private functions, making the "logic" of the class harder to follow (write smaller classes, I know). That, together with the subclassing issues, makes me halt a bit on the porch of extension wonderland.

Would love to hear how the Swift community of the world looks at extensions. What do you think? Is there a silverbullet?

Answer 1

This is only my opinion, of course, so take what I'll write easy.

I'm currently using the extension-approach in my projects for few reasons:

• The code is much more clean: my classes are never over 150 lines and the separation through extensions makes my code more readable and separated by responsibilities

This is usually what a class looks like:

final class A {
    // Here the public and private stored properties
}

extension A {
    // Here the public methods and public non-stored properties
}

fileprivate extension A {
    // here my private methods
}

The extensions can be more than one, of course, it depends on what your class does. This is simply useful to organize your code and read it from the Xcode top bar

• It reminds me that Swift is a protocol-oriented-programming language, not an OOP language. There is nothing you can't do with protocol and protocol extensions. And I prefer to use protocols for adding a security layer to my classes / struct. For example I usually write my models in this way:

  protocol User {
      var uid: String { get }
      var name: String { get }
  }
  
  final class UserModel: User {
      var uid: String
      var name: String
  
      init(uid: String, name: String) {
          self.uid = uid
          self.name = name
      }
  }
  

In this way you can still edit your uid and name values inside the UserModel class, but you can't outside since you'll only handle the User protocol type.

Answer 2

I use a similar approach, which can be described in one sentence:

Sort a type's responsibilities into extensions

These are examples for aspects I'm putting into individual extensions:

• A type's main interface, as seen from a client.
• Protocol conformances (i.e. a delegate protocol, often private).
• Serialization (for example everything NSCoding related).
• Parts of a types that live on a background thread, like network callbacks.

Sometimes, when the complexity of a single aspect rises, I even split a type's implementation over more than one file.

Here are some details that describe how I sort implementation related code:

• The focus is on functional membership.
• Keep public and private implementations close, but separated.
• Don't split between var and func.
• Keep all aspects of a functionality's implementation together: nested types, initializers, protocol conformances, etc.

Advantage

The main reason to separate aspects of a type is to make it easier to read and understand.

When reading foreign (or my own old) code, understanding the big picture is often the most difficult part of diving in. Giving a developer an idea of a context of some method helps a lot.

There's another benefit: Access control makes it easier not to call something inadvertently. A method that is only supposed to be called from a background thread can be declared private in the "background" extension. Now it simply can't be called from elsewhere.

Current Restrictions

Swift 3 imposes certain restrictions on this style. There are a couple of things that can only live in the main type's implementation:

• stored properties
• overriding func/var
• overidable func/var
• required (designated) initializers

These restrictions (at least the first three) come from the necessity to know the object's data layout (and witness table for pure Swift) in advance. Extensions can potentially be loaded late during runtime (via frameworks, plugins, dlopen, ...) and changing the type's layout after instances have been created would brake their ABI.

A modest proposal for the Swift team :)

All code from one module is guaranteed to be available at the same time. The restrictions that prevent fully separating functional aspects could be circumvented if the Swift compiler would allow to "compose" types within a single module. With composing types I mean that the compiler would collect all declarations that define a type's layout from all files within a module. Like with other aspects of the language it would find intra file dependencies automatically.

This would allow to really write "aspect oriented" extensions. Not having to declare stored properties or overrides in the main declaration would enable better access control and separation of concerns.