Null Object Pattern in Swift | Hacker News Reader

Null Object Pattern in Swift

medium.com

17 pointsingve18 comments

Why not use optional chaining? https://developer.apple.com/library/ios/documentation/Swift/...

I fail to see how optional chaining, Maybe monads (or Optionals, depending on your persuasion), or the Null Object pattern are fundamentally any different from each other.

Well, the Null Object Pattern is clearly the worst of the bunch, since it requires a whole lot of extra code to set up. It also introduces maintenance issues since you need to keep adding methods to it. Basically, it's a horrid idea to use in Swift.

In languages with good type-checking and optional / maybe types (like Swift, Scala, Rust, Haskell, …), the null object pattern seems less useful, because the compiler makes sure you unwrap things in the right places. But the null object pattern seems really useful in languages like Ruby and Python, where attempting to use optionals tends to just replace null object errors with errors from forgetting to unwrap the value.

I now see that my examples are oversimplified. I also don’t think that the Null Object pattern is the ultimate solution for handling nulls. I just found it useful in certain cases.

What I wanted to show here among other things and why optional chaining would not help is if we wanted to have a special case handling on failure. Optional chaining fails silently. So if we wanted to log an error or to terminate the app every time the request fails, we'd have to do it on every function call.

So now, instead of knowing why my access request failed, I just know that it did fail somehow, somewhere. The Null Object Pattern is barely better than runtime null pointer exception; instead of throwing an exception I'm tricking my client into thinking everything is fine.

Or you could do this:

    phoneCallRegistry.callWithIdentifier(identifier)?.hangUp()

The ? means that hangUp() will not be called if callWithIdentifier(identifier) returns nil.

The maybe monad is good way to deal with computations that may fail. Here is a Swift walkthrough http://www.mokacoding.com/blog/functor-applicative-monads-in...

Every time I read about monads I feel stupid, but it's not always for the same reason. Sometimes it's because I don't understand it. Other times it's because I'm pretty sure I do understand it but I can't see what the big deal is.

Ah. The big deal is some languages can abstract over the idea of an arbitrary monad. You are correct though, most monads are not a big deal and fall into the "oh neat that's useful" category, and not the "omfg" one.

The abstracting over them is pretty mind blowing though.

A monad in Swift terms is essentially just a container type with an initializer that lets you put something in it, and implements flatMap. In Haskell, the equivalents are return and >>=. You can do more with it in Haskell because Monad is essentially a protocol, so you can rely on monadic types having those functions defined in terms of them.

Array and Optional are examples. RAC's SignalProducer is... maybe one? Maybe three?

That's really all there is.

Author doesn't seem to be aware you can unwrap multiple optionals in one if let statement?

Just use Optional<T>! This is what it's for!

There's some saying about Java "design patterns" that can just be replaced with closures. There should probably be another for for ADTs.

Agreed completely. The null object with inheritance is particularly difficult to deal with because you're just asking to forget to nerf something dangerous in the superclass leaving you with partially functional objects. Optional<T> is the right way to handle this.

Exploiting the type system to handle nulls is attractive (when that sort of thing is not “native” to the type system) but boy that’s verbose.

I agree. Perhaps it makes the code look cleaner on the outside, but ultimately it makes it harder to maintain. Also, optionals have loads of features (ex: chaining) to make your code much cleaner, though the author doesn't go into that.

It's a neat idea but I don't think it's as good as optionals.

It's like the author doesn't know what he's doing.

Why would you ever want to maintain such code when the language already solves all that for you with optional chaining and flatMap?

i can see why this might be useful in reducing the amount of code typed, but it makes things harder to read and debug by moving the null check somewhere hidden.

i guess its something you could get used to though...

Reply on news.ycombinator.com