When can you implement a Null Object? When the return types of your methods are monoids.

This article is part of a series of articles about design patterns and their category theory counterparts. In a previous article you learned how there's a strong relationship between the Composite design pattern and monoids. In this article you'll see that the Null Object pattern is essentially a special case of the Composite pattern.

I also think that there's a relationship between monoidal identity and the Null Object pattern similar to the relationship between Composite and monoids in general:

Set diagram showing identity as a subset of Null Object.

Once more, I don't claim that an isomorphism exists. You may be able to produce Null Object examples that aren't monoidal, but on the other hand, I believe that all identities are Null Objects.

Null Object #

While the Null Object design pattern isn't one of the patterns covered in Design Patterns, I consider it a structural pattern because Composite is a structural pattern, and Null Object is a special case of Composite.

Bobby Woolf's original text contains an example in Smalltalk, and while I'm no Smalltalk expert, I think a fair translation to C# would be an interface like this:

public interface IController
    bool IsControlWanted();
    bool IsControlActive();
    void Startup();

The idea behind the Null Object pattern is to add an implementation that 'does nothing', which in the example would be this:

public class NullController : IController
    public bool IsControlActive()
        return false;
    public bool IsControlWanted()
        return false;
    public void Startup()

Woolf calls his implementation NoController, but I find it more intent-revealing to call it NullController. Both of the Boolean methods return false, and the Startup method literally does nothing.

Doing nothing #

What exactly does it mean to 'do nothing'? In the case of the Startup method, it's clear, because it's a bona fide no-op. This is possible for all methods without return values (i.e. methods that return void), but for all other methods, the compiler will insist on a return value.

For IsControlActive and IsControlWanted, Woolf solves this by returning false.

Is false always the correct 'do nothing' value for Booleans? And what should you return if a method returns an integer, a string, or a custom type? The original text is vague on that question:

"Exactly what "do nothing" means is subjective and depends on the sort of behavior the Client is expecting."
Sometimes, you can't get any closer than that, but I think that often it's possible to be more specific.

Doing nothing as identity #

From unit isomorphisms you know that methods without return values are isomorphic to methods that return unit. You also know that unit is a monoid. What does unit and bool have in common? They both form monoids; bool, in fact, forms four different monoids, of which all and any are the best-known.

In my experience, you can implement the Null Object pattern by returning various 'do nothing' values, depending on their types:

  • For bool, return a constant value. Usually, false is the appropriate 'do nothing' value, but it does depend on the semantics of the operation.
  • For string, return "".
  • For collections, return an empty collection.
  • For numbers, return a constant value, such as 0.
  • For void, do nothing, which is equivalent to returning unit.
What all of these have in common is that they return the identity of the monoid in question. Keep in mind that for some types, such as bool and int, more than one monoid exist, and the identity depends on which one you pick:
  • The identity for the any monoid is false.
  • The identity for string is "".
  • The identity for collections is the empty collection.
  • The identity for the addition monoid is 0.
  • The identity for unit is unit.
Recall what the identity of a monoid is: it's the value that, when applied to another value, doesn't change the other value:

foo.Op(Foo.Identity) == foo

In other words: the identity does nothing!

As a preliminary result, then, when all return values of your interface form monoids, you can create a Null Object.

Relationship with Composite #

In the previous article, you saw how the Composite design pattern was equivalent with the Haskell function mconcat:

mconcat :: Monoid a => [a] -> a

This function, however, seems more limited than it has to be. It says that if you have a linked list of monoidal values, you can reduce them to a single monoidal value. Is this only true for linked lists?

After all, in a language like C#, you'd typically express a Composite as a container of 'some collection' of objects, typically modelled by the IReadOnlyCollection<T> interface. There are several implementations of that interface, including lists, arrays, collections, and so on.

It seems as though we ought to be able to generalise mconcat, and, indeed, we can. The Data.Foldable module defines a function called fold:

fold :: (Monoid m, Foldable t) => t m -> m

Let me decipher that for you. It says that any monoid m contained in a 'foldable' container t can be reduced to a single value (still of the type m). You can read t m as 'a foldable container that contains monoids'. In C#, you could attempt to express it as IFoldable<TMonoid>.

In other words, the Composite design pattern is equivalent to fold. Here's how it relates to the Null Object pattern:

As a first step, consider methods like those defined by the above IController interface. In order to implement NullController, all of those methods ignore their (non-existent) input and return an identity value. In other words, we're looking for a Haskell function of the type Monoid m => a -> m; that is: a function that takes input of the type a and returns a monoidal value m.

You can do that using fold:

nullify :: Monoid m => a -> m
nullify = fold (Identity $ const mempty)

Recall that the input to fold must be a Foldable container. The good old Identity type is, among other capabilities, Foldable. That takes care of the container. The value that we put into the container is a single function that ignores its input (const) and always returns the identity value (mempty). The result is a function that always returns the identity value.

This demonstrates that Null Object is a special case of Composite, because nullify is a special application of fold.

There's no reason to write nullify in such a complicated way, though. You can simplify it like this:

nullify :: Monoid m => a -> m
nullify = const mempty

Once you recall, however, that functions are monoids if their return values are monoids, you can simplify it even further:

nullify :: Monoid m => a -> m
nullify = mempty

The identity element for monoidal functions is exactly a function that ignores its input and returns mempty.

Controller identity #

Consider the IController interface. According to object isomorphisms, you can represent this interface as a tuple of three functions:

type Controller =
  (ControllerState -> AnyControllerState -> AnyControllerState -> ())

This is cheating a little, because the third tuple element (the one that corresponds to Startup) is pure, although I strongly suspect that the intent is that it should mutate the state of the Controller. Two alternatives are to change the function to either ControllerState -> ControllerState or ControllerState -> IO (), but I'm going to keep things simple. It doesn't change the conclusion.

Notice that I've used Any as the return type for the two first tuples. As I've previously covered, Booleans form monoids like any and all. Here, we need to use Any.

This tuple is a monoid because all three functions are monoids, and a tuple of monoids is itself a monoid. This means that you can easily create a Null Object using mempty:

λ> nullController = mempty :: Controller

The nullController is a triad of functions. You can access them by pattern-matching them, like this:

λ> (isControlWanted, isControlActive, startup) = nullController

Now you can try to call e.g. isControlWanted with various values in order to verify that it always returns false. In this example, I cheated and simply made ControllerState an alias for String:

λ> isControlWanted "foo"
Any {getAny = False}
λ> isControlWanted "bar"
Any {getAny = False}

You'll get similar behaviour from isControlActive, and startup always returns () (unit).

Relaxation #

As Woolf wrote in the original text, what 'do nothing' means is subjective. I think it's perfectly reasonable to say that monoidal identity fits the description of doing nothing, but you could probably encounter APIs where 'doing nothing' means something else.

As an example, consider avatars for online forums, such as Twitter. If you don't supply a picture when you create your profile, you get a default picture. One way to implement such a feature could be by having a 'null' avatar, which is used in place of a proper avatar. Such a default avatar object could (perhaps) be considered a Null Object, but wouldn't necessarily be monoidal. There may not even be a binary operation for avatars.

Thus, it's likely that you could encounter or create Null Objects that aren't monoids. That's the reason that I don't claim that a Null Object always is monoidal identity, although I do think that the reverse relationship holds: if it's identity, then it's a Null Object.

Summary #

Monoids are associative binary operations with identity. The identity is the value that 'does nothing' in that binary operation, like, for example, 0 doesn't 'do' anything under addition. Monoids, however, can be more complex than operations on primitive values. Functions, for example, can be monoids as well, as can tuples of functions.

The implication of that is that objects can be monoids as well. When you have a monoidal object, then its identity is the 'natural' Null Object.

The question was: when can you implement the Null Object pattern? The answer is that you can do that when all involved methods return monoids.

Next: Builder as a monoid.


Ciprian Vilcan #

All the examples of using Maybe I recall seeing always wrapped a data type that had a neutral element. So Maybe<int> would resolve to 0 or 1, while Maybe<string> to string.Empty. But what about data types that do not have a neutral element?

Suppose we have this DDD value object, NonEmptyString, written in C#. It has no public constructor and it is instantiated through a static factory method that returns a Maybe<NonEmptyString> containing an initialized NonEmptyString if the given input is not null or whitespace and None otherwise.

How do you treat the None case when calling the maybe.Match method? Since the neutral element for string concatenation is string.empty, an invalid value for this value object, this type has no possibility of having a Null Object.
Can this situation be resolved in the functional way (without throwing an exception) or does it warrant throwing an exception?

2018-05-07 08:21 UTC

Ciprian, thank you for writing. I'm not sure I understand what you man by Maybe wrapping a neutral element. I hope that's not how my introduction to Maybe comes across. Could you point to specific examples?

If NonEmptyString is, as the name implies, a string guaranteed to be non-empty, isn't it just a specialisation of NotEmptyCollection<T>? If so, indeed, there's no identity for NonEmptyString (but it does form a Semigroup).

Since it's a semigroup, though, you can lift it to a monoid my wrapping it in Maybe. If you do that, the identity of Maybe<NonEmptyString> would be nothing.

2018-05-08 1:53 UTC
Ciprian Vilcan #

You are right, Mark. The NonEmptyString class is indeed a semigroup, thus has no neutral element.
This is not what confuses me, but what function to supply in the None case of a Maybe<SomeSemigroup> when calling the .Match method. In the case of Maybe<SomeMonoid>, it's simple and intuitive, as you simply supply a function that returns the neutral element of that monoid.
But what about semigroups?

Here's a couple of generalized examples to better illustrate the question I'm having:
Maybe<SomeMonoid> firstMaybe = someService.GetSomeMonoid();
SomeMonoid value = firstMaybe.Match(Some: containedValue => containedValue, None: () => SomeMonoid.NeutralElement);

Maybe<SomeSemigroup> secondMaybe = someService.GetSomeSemigroup();
SomeSemigroup someSemigroup = secondMaybe.Match(Some: containedValue => containedValue, None: () => /*What to do here? Is it appropriate to throw an exception?*/);

I hope this time my question became clearer. I'm still in the process of wrapping my head around functional and category theory concepts, so my terminology may not be pinpoint accurate.

2018-05-11 06:44 UTC

Ciprian, that's the problem with semigroups, isn't it? There's no single natural element to use in the absence of data.

Lifting a semigroup to a Maybe is one way to resolve that problem. Since Maybe is a functor, you can map the contents of the Maybe until you've mapped it into a value for which an identity exists.

In some cases, you can also fold a Maybe value by supplying a default value that makes sense in the specific context. A default value can be an appropriate fall-back value in a given context, even if it isn't a general identity.

2018-05-12 8:20 UTC
Ciprian Vilcan #

I think I got it!
If you want to process that Maybe<SomeSemigroup> in a functional way, using the .Match(Some: ..., None: ...) method, you actually have to transform the method using it from a mostly statement based one, to a mostly expression based one. You have to pretend you don't know what's inside that Maybe for as long as possible, similar to using Lazy (or lazy evaluation in general).

In this fiddle I've played around and created both an imperative and functional query method for retrieving a book by title and author, in order to prove myself that they can be made isomorphic. These two methods are GetBookFunctional and GetBookImperative.
However, I'm now trying to transform the GetBookImperativeWithoutElses into something functional using that .Match method, but I don't think it's possible.
The .Match method's signature is, practically speaking, equivalent to the if-else statement, whereas the GetBookImperativeWithoutElses method uses the if statement, meaning the functional approach will be forced to treat the elses, whereas the imperative one won't.

Wow, so if you want to use this Maybe of semigroup and/or go fully functional, you really have to go deep down the functional rabbit hole.
Also, my guess is there is no guarantee that going from imperative to functional does not introduce more redundancy (like the elses in the second set of methods) into your system.

Am I right in these regards?

2018-05-12 13:45 UTC

Ciprian, thank you for the link to the code. This explains why you're running into trouble. You absolutely can address the scenario that causes you trouble in a nice functional style, but once you start having the need to keep track of error data as well as happy-path data, Maybe is no longer the data structure you need.

Maybe enables you to model a case where data may or may not be available. It enables you distinguish something from nothing. On the other hand, in the absence of data, you have no information about the reason that data is missing.

In order to keep track of such information, you need Either, which models data that's either this or that.

I'll cover Either in future posts.

2018-05-13 14:44 UTC
Edward Wang #

Hi Mark, your posts are very impressive. I started to learn category theory and try to use it to understand programming.

However, the idea of treating neutral elements as "do nothing" is not so helpful from my point of view. The neutral element is defined under a binary operation. But there is no clue that the return value of methods in the Null Object will be used in such a binary operation.

Also, this idea doens't give us a unique choice of "do nothing". Given a type, there could be more than one binary operations that makes the type a monoid. Why do we choose the neutral element under this binary operation instead of the other binary operation?

2023-10-29 13:28 UTC

Edward, thank you for writing. If you don't find this useful, you are free to ignore it.

Personally, I find the Null Object pattern interesting, because it's a alternative to an if branch. Sometimes, in various programming contexts, you may run into situations where you need to do nothing on various special occasions. By employing the Null Object pattern, you may be able to avoid Shotgun Surgery by replacing scattered if checks with a Null Object.

This, however, begs the question: When is it possible to make a Null Object implementation of a polymorphic type?

This isn't always possible. For example, if the type has a method that returns a date and time, then which value do you return in order to 'do nothing'?

I can't easily answer that question, so a Null Object probably isn't possible with a design like that.

On the other hand, if the polymorphic type only defines monoidal operations, you know that a Null Object is possible.

In reality, to be honest, in API design, I'm more interested in the Composite pattern, but if I can make something a Composite, then the Null Object just comes along for the ride.

Thinking about monoids is, for me, mostly an analysis tool. It gives me guidance on what may be a good design. I don't presume to claim that in a language like C#, having bool og int as return types makes the monoidal operation unambiguous.

Haskell gets around that issue by wrapping the primitive types in distinguishable wrappers. Thus, neither Bool nor Int are Monoid instances, but Any, All, Sum, and Product are.

2023-11-02 21:16 UTC

Wish to comment?

You can add a comment to this post by sending me a pull request. Alternatively, you can discuss this post on Twitter or somewhere else with a permalink. Ping me with the link, and I may respond.


Monday, 23 April 2018 07:55:00 UTC


"Our team wholeheartedly endorses Mark. His expert service provides tremendous value."
Hire me!
Published: Monday, 23 April 2018 07:55:00 UTC