
Null Object Pattern in Swift - ingve
https://medium.com/swift-programming/null-object-pattern-in-swift-1b96e03b2756
======
panic
Why not use optional chaining?
[https://developer.apple.com/library/ios/documentation/Swift/...](https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html)

~~~
andrew_mason1
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.

~~~
sanderjd
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.

------
adamwk
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.

------
peterkelly
Or you could do this:

    
    
        phoneCallRegistry.callWithIdentifier(identifier)?.hangUp()
    

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

------
sjtgraham
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...](http://www.mokacoding.com/blog/functor-applicative-monads-in-pictures/)

~~~
ashark
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.

~~~
cballard
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.

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

------
cballard
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.

~~~
arcticbull
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.

------
mwsherman
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.

~~~
danappelxx
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.

------
zephyz
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?

------
jheriko
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...

