C# - Correct way to convey Null Object design pattern via an interface for client/service?

Question

I've just learnt about the Null Object design pattern, which recommends that the service either return a default null object or throw an null related exception itself so that the client need not worry about checking for null or throwing a null exception.

The thing is, as far as I understand a client/service relationship should take place via an interface. How can the information that "the service handles null checking so the client not need have to" be conveyed via the interface? In C# the interface provides a method signature that can be expected, but the fact the service does null checking seems like an extra piece of arbitrary information that cannot be passed through the interface.

My concern is if the client assumes the service does null checking even though the interface has no way to specify such, that this may lead to "leaky abstraction" and the client is now taking for granted a specific implementation detail of the service, thus coupling itself to it.

What is the correct way for a client to be aware that the service is doing null checking so that it does not need to, without breaking the principles of encapsulation?

Answer 1

Best way would be to have a type system that doesn't have "implicit null" for reference types. That means, that all references are non-nullable by default and can only contain null when explicitly defined.

This is possible in C# 8 with never version of a compiler using Nullable reference types. This way, the client knows if returned reference value can or cannot contain null and can handle it accordingly.

Something similar would be difficult in older versions of C#. Only option that I'm aware of is to set a convention that all references are non-nullable and only way to return null is through Option monad. And enforce this during code reviews or using static analysis tool.

Answer 2

A null object, in the context of the Null Object Pattern, is simply an object that does nothing when some operation is invoked.¹ The idea is to avoid dealing with special cases - this includes, but is not limited to, avoiding null checks; e.g., you may want to do nothing if a certain set of conditions is not met. The calling code (client code) is written against an interface implemented by both the null object and by other objects that do have behavior. Because of polymorphism, the one that it (client code) gets to work with can turn out to be either one of those.

For this to work, client code has to have no knowledge about how exactly the interface is implemented, and, specifically, it cannot know if the concrete object it calls is null object or not. So, generally speaking, you cannot convey the specific idea of a null object through the design of the interface.

It's not an interface-level / single-object abstraction, it's an abstraction that involves a combination of objects, and the null object is usually, from a certain point of view, meant to be an internal detail.

It's important to consider what exactly are you exposing to client code. If you are writing some code that exposes an interface that others can implement, then you cannot force them to use the Null Object pattern (and you shouldn't). If you provide some class (let's call it MyClass) that uses this interface as a dependency, then you can do a couple of things. E.g., you could provide an optional null implementation for clients to use if they wish to do so, and note that down in the documentation of MyClass. Or, you could decide that MyClass requires its dependencies to not be null and to not throw exceptions, document that requirement, and mention the Null Object Pattern as an option, but leave the implementation to clients. Or you could do both. Or, you can check for null in the constructor and use a corresponding null object for that parameter (without providing any way for clients to retrieve this null object; it's just to provide certain default behavior, and it should be internal to your class).

If the interface is internal to your code, or if clients are not able to extend it (either directly or indirectly), and you have a class that, again, has this interface as a dependency, then you have full control over how it all works, and you can decide internally when it's appropriate to use a null object, based on some parameter (or lack thereof). Clients don't have to know about this at all; you'd just provide one or more ways to construct the object, and document what each of these constructors and factory methods does; you don't even have to mention that you are using the Null Object Pattern internally.

---

¹ Also, just to clear a misconception, throwing a null reference exception is not a part of this pattern. Instead of removing special cases, this would actually introduce one, since client code would (ultimately) need to handle this exception.