Swift: Alternative to Default Implementations in Protocols

Posted on March 26th, 2017

I recently wrote about why I prefer not to use default implementations in Swift protocols.

TL;DR

I want a lot of conscious thought put in into each method of the protocol – adding a default implementation will make it easy to forget and not think about much. Oh, and the compiler won’t complain!
I want it to be easy to make changes in the implementation. If a method is not included in the file because the implementation is in the protocol, it’s more work to make the decision to add that into the file. The assumption is that the default should win. If it’s already there, it’s easier to just go in and make a small change.
Similar to the above point, I want it to be super readable where each method is coming from. If a bunch of methods are in the default implementation of the protocol, it’s not as clear just by looking at the file.

But there might still be repeating or “default” implementations that are shared across protocol implementations. In my case, I approached this issue by creating an object with some variables that could be shared across protocols:

struct SessionDataDefaults {
        
    let title: String
    let subtitle = "try! Conference"
    let logoImageURL = Bundle.trySwiftAssetURL(for: "Logo.png")!
    let imageURL: URL?
    let location: String
    let summary = Conference.current.localizedDescription
    let twitter = Conference.current.twitter!
    
    init(session: Session) {
        title = session.localizedString(for: session.title ?? "TBD", japaneseString: session.titleJP)
        
        if let url = session.imageWebURL {
            imageURL = URL(string: url)
        } else if let assetName = session.imageAssetName {
            imageURL = Bundle.trySwiftAssetURL(for: assetName)
        } else {
            imageURL = nil
        }
        
        if let location = session.location {
            self.location = location.localizedName
        } else {
            self.location = Venue.localizedName(for: .conference)
        }
    }
}

struct SessionDataDefaults {

let title: String

let subtitle = "try! Conference"

let logoImageURL = Bundle.trySwiftAssetURL(for: "Logo.png")!

let imageURL: URL?

let location: String

let summary = Conference.current.localizedDescription

let twitter = Conference.current.twitter!

init(session: Session) {

title = session.localizedString(for: session.title ?? "TBD", japaneseString: session.titleJP)

if let url = session.imageWebURL {

imageURL = URL(string: url)

} else if let assetName = session.imageAssetName {

imageURL = Bundle.trySwiftAssetURL(for: assetName)

} else {

imageURL = nil

}

if let location = session.location {

self.location = location.localizedName

} else {

self.location = Venue.localizedName(for: .conference)

}

However, when I wrote the article about it, @jckarter tweeted the following:

@NatashaTheRobot Another approach: put the defaults on a separate protocol you conform to when you intentionally want them on your type

— Joe Groff (@jckarter) March 25, 2017

In my case, it didn’t make sense to create a separate protocol with default implementation because the use of the default values is pretty random – there isn’t any type of session that will use all defaults at the same time (this is one reason I didn’t want to include a default implementation in the first place).

But this did spark another idea! I could make my data defaults object conform to the same protocol as the objects where the defaults are being used – in my case, SessionDisplayable:

struct SessionDataDefaults: SessionDisplayable {
        
    fileprivate let session: Session
    
    init(session: Session) {
        self.session = session
    }
    
    var title: String {
        return session.localizedString(for: session.title ?? "TBD", japaneseString: session.titleJP)
    }
    
    var subtitle: String {
        return Conference.current.name ?? "try! Conference"
    }
    

    var logoURL: URL {
        return Conference.current.logoURL
    }
 
    
    var location: String {
        if let location = session.location {
            return location.localizedName
        } else {
            return Venue.localizedName(for: .conference)
        }
    }
    
    var sessionDescription: String {
        return "❤️".localized()
    }
    
    var presentationSummary: String {
        return Conference.current.localizedDescription
    }
    
    var twitter: String {
        return Conference.current.twitter!
    }
    
    var selectable: Bool {
        return false
    }
}

struct SessionDataDefaults: SessionDisplayable {

fileprivate let session: Session

init(session: Session) {

self.session = session

}

var title: String {

return session.localizedString(for: session.title ?? "TBD", japaneseString: session.titleJP)

}

var subtitle: String {

return Conference.current.name ?? "try! Conference"

}

var logoURL: URL {

return Conference.current.logoURL

}

var location: String {

if let location = session.location {

return location.localizedName

} else {

return Venue.localizedName(for: .conference)

}

var sessionDescription: String {

return "❤️".localized()

}

var presentationSummary: String {

return Conference.current.localizedDescription

}

var twitter: String {

return Conference.current.twitter!

}

var selectable: Bool {

return false

}

The best part about this is that when a method needs to use the default implementation, it can use the defaults method that has the same exact name as the method being implemented!

Here is an example of another SessionDisplayable using the new defaults:

struct CoffeeBreakSessionViewModel: SessionDisplayable {
    
    private let session: Session
    private let dataDefaults: SessionDataDefaults
    
    init?(_ session: Session) {
        if session.type == .coffeeBreak {
            self.session = session
            self.dataDefaults = SessionDataDefaults(session: session)
        } else {
            return nil
        }
    }
    
    var title: String {
        if let sponsor = session.sponsor {
            return String(format: "Coffee Break, by %@".localized(), sponsor.name)
        }
        return "Coffee Break".localized()
    }
    
    var subtitle: String {
        if let sponsor = session.sponsor {
            return sponsor.localizedName
        }
        // Matching variable name in the defaults
        // makes it super easy to use!!
        return dataDefaults.subtitle
    }
    
    var logoURL: URL {
        if let imageURL = dataDefaults.imageURL {
            return imageURL
        }
        
        if let sponsor = session.sponsor {
            return sponsor.logoURL
        }
        
        // Matching variable name in the defaults
        return dataDefaults.logoURL
    }
    
    var location: String {
        // Matching variable name in the defaults
        return dataDefaults.location
    }
    
    var sessionDescription: String {
        return "❤️".localized()
    }
    
    var presentationSummary: String {
        // Matching variable name in the defaults
        return dataDefaults.presentationSummary
    }
    
    var selectable: Bool {
        return session.sponsor != nil
    }
    
    var twitter: String {
        let twitter = session.sponsor?.twitter ?? dataDefaults.twitter
        return "@\(twitter)"
    }
}

struct CoffeeBreakSessionViewModel: SessionDisplayable {

private let session: Session

private let dataDefaults: SessionDataDefaults

init?(_ session: Session) {

if session.type == .coffeeBreak {

self.session = session

self.dataDefaults = SessionDataDefaults(session: session)

} else {

return nil

}

var title: String {

if let sponsor = session.sponsor {

return String(format: "Coffee Break, by %@".localized(), sponsor.name)

}

return "Coffee Break".localized()

}

var subtitle: String {

if let sponsor = session.sponsor {

return sponsor.localizedName

}

// Matching variable name in the defaults

// makes it super easy to use!!

return dataDefaults.subtitle

}

var logoURL: URL {

if let imageURL = dataDefaults.imageURL {

return imageURL

}

if let sponsor = session.sponsor {

return sponsor.logoURL

}

// Matching variable name in the defaults

return dataDefaults.logoURL

}

var location: String {

// Matching variable name in the defaults

return dataDefaults.location

}

var sessionDescription: String {

return "❤️".localized()

}

var presentationSummary: String {

// Matching variable name in the defaults

return dataDefaults.presentationSummary

}

var selectable: Bool {

return session.sponsor != nil

}

var twitter: String {

let twitter = session.sponsor?.twitter ?? dataDefaults.twitter

return "@\(twitter)"

}

I’m very happy with this solution. It’s super easy to use the defaults, but still allows for the compiler to complain when a protocol method is not implemented.

Sam Duke

Composing like this looks a little bit painful, especially if the protocol weren’t just vars but were functions requiring variables to be fwded. I left another comment on your other post about abstract classes in Java.

To me it looks like the composition pattern you’re using here looks perfect for the problem, but I don’t think this is a replacement for default implementations on protocols in general
- Jan Le Mann
  
  Well as always in programming, it is a case by case decision the programmer has to make. As you said: in this particular case, the way Natasha did it works really well and has exactly the advantages you’d want to have over a default implementation in the protocol.
  
  This is not intended to be a “protocol default implementation replacement” rather than a nice alternative to consider in one or the other case, where default implementations could have their downsides.
  
  Its always good to have a big toolbox with a lot of tools – oh and of course you also have to know how to use your tools. I say thank you Natasha for another wonderful tool in my personal toolbox.
  - Sam Duke
    
    Indeed, I guess this was a response in the context of “Swift: Why You Shouldn’t Use Default Implementations in Protocols”
Tanya Berezovsky

Natasha, thank you for sharing yours refactoring process! I like your final clear solution. I’m exciting to see how you think when refactoring, I learn from it a lot.