NULL Objects...

// I would like to clarify that there is a spelling mistake here!
The customers object is in fact a repository that tries to find a customer named peterson. The customer is not available - the question is: What do we do?

// I removed "option" because it is irrelevant to the domain. I see your point though.
var customer = customers.named('Petersen');

// 1.
var plan = customer.map(c => c.getPlan()).defaultTo(BillingPlan.basic()); // <- your common Maybe/Option stuff

// This is essentially doing this:

// 2.
var plan = customer.getPlan() ?? BillingPlan.basic();

// But in a way that will later be evaluated, isn't that right? So plan is not the actual object in the example at (1.) but a function, that guarnatees me to find an appropriate object to go on?

// It might be that my understanding of FP is too limited. Essentially this says that: Option is a function that guarantees to return something, as soon as it is used. Is this correct?

If so I could rewrite this potentially (if the language supported it) to

customer.getPlan = () => this.getPlan() ?? BillingPlan.basic();



// I think this pulls the problem out of scope and context. Of course, the script could go on like this:

// Something needs to happen with the plan object.
_billingService.Magic(plan);


But the problem is not: How do we get a plan under all circumstances, but how do we avoid checking the customer for null, yet guaranteeing functionality and robustness of the code. Therefore the following example would be breaking.

// If the the function customer.named('petersen') looks like this:

class CustomerRepostiory {
    Customer named(string name) {
        return null;
        }
}

// The following code would also break.

var customer = customers.named('Petersen');
var plan = customer.map(c => c.getPlan()).defaultTo(BillingPlan.basic()); // <- your common Maybe/Option stuff



//

The Idea of having a null object is to produce a value that Guarantees, that the code has something to work with, without exceptionhandling or a breakdown through nullreferences, but still capture this as a special case.

The logic has two possible ways of being treated.

//1
Get the customer named Petersen from the DB.
There is no such customer.
Return null. Null indicates that an object does not exist.
if (customer == null) checks all over guarantee that no function is called on this object.
They shield the special cases for this object.

//2

Get the customer named Petersen from the DB.
There is no such customer.

There is a good reason for this: He is a new Customer.
Rather than just returning a customer, return an object of Type "NewCustomer"
The code looks all the same. No if null checks.
There is always an object which we can call the appropriate methods on.
They act differently for differnt types, thus reducing the procedural state.


I agree that the simplest case is


if(customer != null){
    customer.doSomething();
}


Noting further happens. But ususally we will encounter something like this:


var customer = customers.named('peterson')
if(customer != null)
{
    customer.doSomething();
}
else
{
    customer = customer.create('peterson');
    customer.doSomething();
}

And this is what I am talking about. This example is now going further away from the original, but the pattern poses a value. Show me some code with null checks and I will show you how I can remove all of them. And I do NOT want to hear the stupid argument, that an extra class with extra, empty methods is "Too much code", 'too many lines' or "overcomplicating it". That is like saying that Enumerator is too much code because I can just go

for(int i = 0; i < customers.length; i++)
    customer = customers[i];


It's a pattern.