Abstract types and methods in Swift

In object-oriented programming, an abstract type provides a base implementation from which other types can inherit to gain some shared, common functionality. Abstract types differ from ordinary types in that they are never used as is (in fact, some programming languages ​​even prevent abstract types from being directly instantiated), because their only purpose is to serve as a common parent class for a group of related types.

For example, let’s say we want to unify the way we load certain types of models over the network. By providing a shared API, we’ll be able to separate concerns, make dependency injection[1] and mocking[2] easy, and keep method names consistent across our projects.

An abstract type-based approach is to use a base class that will serve as a shared, unified interface for all of our model loading types. Since we don't expect this class to be used directly, we'll make it so that a fatalError is triggered when the base class implementation is called incorrectly:

 class Loadable <Model> { ​ ​
 func load ( from url : URL ) async throws - > Model {
 fatalError ( "load(from:) has not been implemented" )
 }
 }

Each Loadable subclass would then override the load method described above to provide its loading functionality, as follows:

If the above pattern looks familiar, that’s probably because it’s essentially the same as the polymorphism we normally use in Swift with protocols[3]. That is, when we want to define an interface, a contract, that multiple types can conform to through different implementations.

 class UserLoader : Loadable < User > {
 override func load ( from url : URL ) async throws - > User {
 ...
 }
 }

Protocols do have a significant advantage over abstract classes though, in that the compiler will enforce that all of their requirements are implemented correctly - this means we no longer have to rely on runtime errors (such as fatalError) to prevent improper usage because we can't instantiate the protocol.

So if we took a protocol-oriented approach, instead of using abstract base classes, our previous Loadable and UserLoader types might look like this:

 protocol Loadable {
 associatedtype Model
 func load ( from url : URL ) async throws - > Model
 }
 class UserLoader : Loadable {
 func load ( from url : URL ) async throws - > User {
 ...
 }
 }

Notice how we now use an associated type to let each Loadable implementation determine the exact Model it wants to load - this gives us a nice balance between complete type safety and great flexibility.

So, in general, protocols are definitely the preferred way to declare abstract types in Swift, but that doesn't mean they're perfect. In fact, our protocol-based implementation of Loadable currently has two major shortcomings:

• First, since we had to add an associated type to our protocol to keep our design generic and type-safe, this means that Loadable can no longer be referenced directly.
• Second, since protocols cannot include any form of storage, if we want to add any storage properties that all Loadable implementations can use, we must redeclare these properties in each concrete implementation.

This property storage aspect is really a huge advantage of our previous abstract class-based design. So if we revert Loadable back to being a class, we can store all the objects our subclasses need directly in our base class - no more duplicating these properties in multiple types:

 class Loadable <Model> { ​ ​
 let networking : Networking
 let cache : Cache < URL , Model >
 init ( networking : Networking , cache : Cache < URL , Model > ) {
 self .networking = networking
 self .cache = cache
 }
 func load ( from url : URL ) async throws - > Model {
 fatalError ( "load(from:) has not been implemented" )
 }
 }
 class UserLoader : Loadable < User > {
 override func load ( from url : URL ) async throws - > User {
 if let cachedUser = cache .value ( forKey : url ) {
 return cachedUser
 }
 let data = try await networking .data ( from : url )
 ...
 }
 }

So, what we are dealing with here is basically a classic trade-off scenario, where both approaches (abstract class vs. protocol) give us different advantages and disadvantages. But what if we could combine these two approaches and get the best of both worlds?

If we think about it, the only real problem with the abstract class based approach is that we have to add fatalError to the method that every subclass needs to implement, so what if we just use a protocol for this specific method? Then we can still keep our networking and cache properties in the base class - like this:

 protocol LoadableProtocol {
 associatedtype Model
 func load ( from url : URL ) async throws - > Model
 }
 class LoadableBase < Model > {
 let networking : Networking
 let cache : Cache < URL , Model >
 init ( networking : Networking , cache : Cache < URL , Model > ) {
 self .networking = networking
 self .cache = cache
 }
 }

But the main disadvantage of this approach is that all concrete implementations now have to subclass LoadableBase and declare that they conform to our new LoadableProtocol protocol:

 class UserLoader : LoadableBase < User > , LoadableProtocol {
 ...
 }

This might not be a huge problem, but it does make our code arguably less elegant. The good news, though, is that we can actually fix this by using a generic type alias. Since Swift’s composition operator & supports combining a class and a protocol, we can reintroduce our Loadable type as a composition between LoadableBase and LoadableProtocol:

 typealias Loadable < Model > = LoadableBase < Model > & LoadableProtocol

This way, concrete types (like UserLoader ) can simply declare that they are based on Loadable , and the compiler will ensure that all of those types implement our protocol’s load method — while still enabling those types to use the properties declared in our base class:

 class UserLoader : Loadable < User > {
 func load ( from url : URL ) async throws - > User {
 if let cachedUser = cache .value ( forKey : url ) {
 return cachedUser
 }
 let data = try await networking .data ( from : url )
 ...
 }
 }

Great! The only real downside to the above approach is that Loadable still can’t be referenced directly, since it’s still part of the generic protocol. But this might not actually be a problem - if this becomes a situation then we can always use techniques like type erasure to work around these issues.

Another slight caveat to our new type alias-based Loadable design is that this combined type alias cannot be extended, which could become a problem if we wanted to provide some convenience API that we don't want to (or can't) implement directly in the LoadableBase class.

One way to fix this, though, is to declare everything we need to implement these convenience APIs in our protocol, which will allow us to extend the protocol ourselves:

 protocol LoadableProtocol {
 associatedtype Model
 var networking : Networking { get }
 var cache : Cache < URL , Model > { get }
 func load ( from url : URL ) async throws - > Model
 }
 extension LoadableProtocol {
 func loadWithCaching ( from url : URL ) async throws - > Model {
 if let cachedModel = cache .value ( forKey : url ) {
 return cachedModel
 }
 let model = try await load ( from : url )
 cache .insert ( model , forKey : url )
 return model
 }
 } 

 }

These are a few different ways to use abstract types and methods in Swift. Subclassing may not be as popular as it once was (as it is in other programming languages), but I still think these techniques are great to have in our entire Swift development toolbox.

References

• [1] Dependency Injection: https://www.swiftbysundell.com/articles/different-flavors-of-dependency-injection-in-swift .
• 2] Mocking: https://www.swiftbysundell.com/articles/mocking-in-swift.
• [3] Commonly used protocols in Swift: https://www.swiftbysundell.com/basics/protocols.