We all know that composition is better than inheritance. Apple made a big push in this direction at WWDC15 by officially declaring protocols the next big paradigm in programming. If you haven’t already seen it, go watch Protocol-Oriented Programming in Swift, it’s definitely worth your time.

Like someone with a new hammer i immediately went trying to hit a particular nail, a problem that everyone trying to make a game for the first time has to deal with sooner or later: How to compose your game objects without duplicating code while avoiding deep inheritance hierarchies?

Consider the following example:

protocol Bird { }

protocol Flyable {
    func fly()
}

struct Penguin: Bird { }

struct Eagle: Bird, Flyable {
    func fly() {
        print("huiii")
    }
}

let birds: [Bird] = [Penguin(), Eagle()]

for bird in birds {
    if let bird = bird as? Flyable {
        bird.fly()
    }
}

This game has several birds a characters, some of which fly, some of which don’t. We would like every flying bird to update its flying state. The problem: We only know the base class of our game objects, so we do a lot of typecasting, which feels like a workaround.

Turns out the solution was another way of implementing composition: An Entity-Component architecture.

protocol Component {
    func update()
}

struct Flying: Component {
    func update() {
        print("huiii")
    }
}

protocol Bird {
    var components: [Component] { get }
}

extension Bird {
    func updateAll() {
        for component in components {
            component.update()
        }
    }
}

struct Penguin: Bird {
    let components: [Component] = []
}

struct Eagle: Bird {
    let components: [Component] = [Flying()]
}

let birds: [Bird] = [Penguin(), Eagle()]

for bird in birds {
    bird.updateAll()
}

Apple actually provides helper classes for this paradigm in GameplayKit, also released at WWDC15. Although that session got a lot less attention. At my day-job we used Entity-Component to break up an AppDelegate, so this doesn’t only apply to games 😉

I guess my point here is, that there is no silver bullet. You should always choose the tool that’s best suited for your problem, not try to bend your tool to solve your problem.

Today i got into a situation where i realised that i was writing the same extensions for various enums over and over again.

Let’s say we’re parsing JSON. JSON often promises to only return specific values for a key, like an enum, but we’re actually parsing strings. So we would define an enum like this:

public enum Foobar: String {
    case foo = "FOO"
    case bar = "BAR"
}

And then parse the JSON string like this:

let blub = Foobar(rawValue: "FOO")

Sometimes we would like the parser to act a little more fuzzy, so we do:

extension Foobar {
    public static func fromStringIgnoringCase(string: String) -> Foobar? {
        return Foobar(rawValue: string.uppercaseString)
    }
}

Let’s do this more elegantly and make it reusable. Instead of extending all enums with a String raw value (which, to my knowledge, is currently not possible in Swift), we can make our enums with String raw values conform to a type like:

public protocol StringEnumType {
    var rawValue: String { get }
    init?(rawValue: String)
}

public enum Foobar: String, StringEnumType {
    case foo = "FOO"
    case bar = "BAR"
}

Note that the enum already conforms to the protocol, no need to write repetitive boilerplate code. Now we can just extend the StringEnumType protocol:

public extension StringEnumType {
    public static func fromStringIgnoringCase(string: String) -> Self? {
        return Self.init(rawValue: string.uppercaseString)
    }
}