The Royal Wedding is upon us! So many questions in the air: what will the colour scheme be, who will be there and will it have 4 seasons in one day as per the usual in the UK? But the real question that’s burning on simply everyone’s mind is ‘could Megan not save herself lots of stress regarding the seating arrangements if she used a custom iOS app rather than fretting on the day?’ The answer to ‘one’s’ question is of course yes darling!

Let’s imagine that Megan has two options for the app and how the code operates under the hood: for some guests she wants to simply hand them over to the concierge to show them to their seat. However for some special guests she wants a custom seating experience unique to them: you know, where they maybe have a string quartet that dramatically changes the music for them when they walk to their seat and then, just when they notice, the quartet casually switches the music back so that the guests don’t really know what’s going on? Exactly! Cool right? And all whilst Megan enjoys sipping a glass of vintage champagne.

If we talk in code now with this narrative, there are two ways we can separate the work out whilst also learning a bit about the differences between passing a customisable closure to a method and the method returning another method we can pass a customisable parameter to. It boils down to: do you want the ‘takeASeat’ method to be able to take a unique closure (experience) for that user or do you want the ‘takeASeat’ method to do all of the table preparations and simply be passed a guest for the usual seating experience?

I love how realistic this example is and I hope they got a deal on this app…

Let’s begin by making a guest struct for our wedding guests:

struct WeddingGuest {
    var hatChoice: Int
    var isDistinguistedGuest: Bool

Let’s begin with the usual seating arrangement: the one where the method does all the standard prep, doesn’t need special customisation and just wants to be handed a guest and their lovely hat to seat them:

typealias StandardSeatingArrangement = (WeddingGuest) -> Void
func takeASeat() -> StandardSeatingArrangement {
    return { standardGuest in
        // Take guest to their seat in the normal way - they should still be happy to be at the wedding though!

Here we’re returning a function from the original preparation function that expects a guest and seats them. The thing we can customise here is the guest/parameter.

Let’s call it now to seat our guest and see it in action!

let standardGuest = WeddingGuest(hatChoice: 2, isDistinguistedGuest: false)

let standardSeatPrep = takeASeat()
// Do stuff and call this later

Now let’s look at the special seating arrangement for guests where we do some preparation, then get passed a unique ‘experience’ method to make it customisable to them:

typealias SpecialSeatingArrangment = (WeddingGuest) -> Void
func takeASeat(_ guest: WeddingGuest, with arrangment: @escaping SpecialSeatingArrangment) {
    // Tell the quartet to get ready
    // Once they give you the nod then...

Here we’re passing in the guest in the parameters at the start and the customisable part is the closure/callback itself. This is much more flexible of that is what you want. I know I want that string quartet playing the Game of Thrones theme while I skip to my seat!

let specialGuest = WeddingGuest(hatChoice: 9, isDistinguistedGuest: true)

takeASeat(specialGuest) { special in
    print("Do something marvelous for the guest")

You see there are advantages to both approaches here and its a question of: do you want to be able to have a customisable closure or callback and make the method more flexible, or do you want your function to behave more like a unique type of it’s own and just be handed a parameter at the end?

WAIT! Did you just inflict Functional Programming on me without me realising it? Yes darling, one just did.

Leave a Reply

Your email address will not be published. Required fields are marked *