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