I’ve been using the null object pattern recently to clean up some legacy code. It works really well with nullable reference types in C# and strict null checks in TypeScript.
Null avoidance and null guards
For a long time I’ve been a fan of null avoidance, avoiding null values whenever possible. In the simplest way, that means using empty string, empty array or zero instead of null. Obviously this isn’t always possible. Sometimes there’s a difference between empty string and null, if you need to specify the absence of string vs. explicit empty string. But you can still get pretty far, and with value types in C# even further. C# and TypeScript made null avoidance and detecting null errors easier by making the IDE enforce checking null objects by default.
So why would you do null avoidance? The main reason is safety, by avoiding those NullReferenceExceptions. That is already alleviated by nullable reference types. But nullable reference type annotations tend to add verbosity. Normally, when dealing with nulls you end up having null guard checks everywhere. Null conditional operator (object?.value) helps a bit, but in reality it’s just propagating the null value. Usually you still need to have the null guard check somewhere later.
Null object pattern
Null object pattern is one elegant way of doing null avoidance. Null object simply means replacing the null value with a special object. Usually this null object is defined as singleton constant. The main difference to null value is that normally when you call any methods or properties of the null value, you can an error. But with null object, you can handle most of the property access and method calls more gracefully. Actually, most of the time you don’t even need to throw exceptions.
In the codebase I was working on, the logged in user was marked as nullable. 99% of the time there is a user. Anonymous user can only access the login page. So having those null checks for anonymous user is unnecessary. I decided to replace the null user with anonymousUser object.
const anonymousUser: User = {
id: "",
email: "",
addresses: [],
isLoggedIn: false
}And this makes the code so much simpler. No need to put user?.email, or even worse, if (user === null) checks everywhere. Most of the code just works.
The code used to be filled with null checks like
function getPostalCodes(user: User): string[] {
if (!user) return [];
return user.addresses.map(a => a.postalCode);
}The null check can be removed, it’s useless.
Or even worse, when no one added the null check, and the code just crashed in the unlikely, but possible, case where there is no logged in user. With nullable reference types, you would at least avoid the crash, because the IDE forces you to add the null check. But even if it’s just a simple if statement here and there, or “!” or “?”, it adds up. The nullable reference types feature also works really well together with null object, because it forces you to use the actual null object, instead of null value. Now, if only C# allowed reference types as default parameter values, you could get rid of nulls completely.
Value types and primitive obsession
And if empty string is not enough, at least on the C# side you can replace plain primitives with value types. For example, instead of string as user ID, consider having UserId type. Records and primary constructors make that really easy. The null object can be a static singleton instance. Usually I would hide the constructor too. Value type has the added benefit of increasing type safety by making sure you’re not mixing IDs of different types. The (anti)pattern of using primitive types everywhere is called primitive obsession, and it’s also unfortunately very common.
Missing language features
Null values often have some special handling involved in programming languages such as JavaScript and C#.
For example, null coalescing only works with actual null values (and undefined, in JavaScript’s case). I would be super happy if one day we could use these features with custom null objects as well.