Summary

The web content discusses the implementation and benefits of the Null Object Pattern as an alternative to null checks in code, ensuring code safety and readability.

Abstract

The article titled "Stop Checking for Nulls" advocates for the use of the Null Object Pattern in software development. It emphasizes the pattern's ability to prevent applications from crashing due to null references by returning a "null" object that does nothing but maintain the application's integrity. The author, Nicklas Millard, provides a practical demonstration using a Person class and a repository to illustrate how this pattern can be applied in production-ready code. The pattern is presented as a three-step process: creating a class, defining a static Factory Method with a private constructor, and implementing a nested sub-class that acts as the "null" object. The article also addresses skepticism about the complexity added by this approach and includes a video tutorial for further understanding. Millard acknowledges that while one cannot control nulls in external code, ensuring that all returns are null-free can significantly improve code quality and maintainability.

Opinions

The author suggests that the Null Object Pattern is superior to traditional null checks for improving code safety and readability.
Millard implies that the pattern is not widely understood or applied, as he notes it may be "against all advice you’ve read so far."
The article conveys that the Null Object Pattern is particularly useful in large-scale applications for clients, hinting at its scalability and robustness in enterprise environments.
There is a recognition that null checks are still necessary for input validation, but the pattern can eliminate the need for them in return values.
The author expresses a belief that the pattern can lead to more maintainable code, as evidenced by the emphasis on the pattern's ability to prevent exceptions and the inclusion of test code in the demonstration.
Millard's provision of additional resources and responses to critics indicates an ongoing dialogue in the software development community about the best practices for handling null values.

APPLIED DESIGN PATTERNS

Stop Checking for Nulls

Let’s have a look at an alternative approach

This is probably against all advice you’ve read so far — unless you’re familiar with the Null Object pattern.

Even if you’ve grasped the concept of NOP, you might still wonder how this is actually done in production ready code.

For anyone who’s still wondering what the null object pattern is all about, read the short introduction below.

Your application explodes when you try invoking methods or accessing properties of a null reference.

Let’s avoid this by applying a very simple but effective pattern. That is, to return a suitable substitution for null. An object that does nothing but improving readability and code safety.

Sounds nice to not having your application explode on you with this screen, right?

Warning: this image might be a PTSD trigger for veteran engineers.

So, how do we avoid these nasty looking exceptions if we aren’t checking for nulls anymore?

We’ll take a look at how I’ve successfully applied the Null Object Pattern in applications for large clients.

It’s basically a three step process

Create your class, whatever it may be
Define a static Factory Method and make the constructor private
Create a nested sub-class — this one will be the “null” class

Demo time, finally I’ve created a Person class to demonstrate this, as I assume everyone can relate to what a Person class might be despite however socially impaired we are as programmers.

Okay, let’s break this one down — I’m sure a lot of you will be very skeptical about the factory method over public constructor shenanigans.

At this point, we’ve just added complexity.

Let’s combine the Null Object Pattern with a repository

Nothing special at all, except one thing.

ThatGetPersonByName()` will always return a person. You won’t have to worry about attempting to access properties or methods of a null reference. The method delivers on its promise to always return a Person type.

If you mistakenly forget to write the infamous if(someObj == null){}` it will not wreck your whole GUI with crazy looking exceptions that’ll have your product owner wondering when it’s possible to have an AI do your work.

Test time

No fun without tests. Stop the video whenever you like to read thru the test code.

But, you check for nulls!

The keen eye has without a doubt caught my lie about not checking for nulls, because I do it myself all over the place e.g. by calling string.IsNullOrEmpty()` and using ??` inside the GetPersonByName` method.

We can’t stop checking other people’s code for nulls, and we shouldn’t expect everyone to play nice and pass non-null values to methods either.

However, you can make sure that all your returns are free from nulls.

Update: I’ve provided additional examples and responded to critics in this post

Additional examples: 3 Reasons Why You Need Null Objects

Let me tell you why this weird pseudo null-object is so great

levelup.gitconnected.com

Some great resources on this pattern

PluralSight Courses
Working with Nulls in C# by Jason Roberts
C# Design Patterns: Null Object by David Starr

Short tutorials
Simple tutorial at TutorialPoint using Java
Simple explanation at SourceMaking using C#

Stop Using If-Else Statements

Write clean, maintainable code without if-else.

medium.com

Don’t Use Database Generated IDs

Stop letting the database be in charge of your application

medium.com

Forget About Constructors

Let’s use an alternative approach to object instantiation

levelup.gitconnected.com

Dynamic command dispatching in C#

Let’s keep this one short and sweet

medium.com

Nicklas Millard is a software development engineer in one of the fastest-growing banks, building mission-critical financial services infrastructure.

Previously, he was a Big4 Senior Tech Consultant developing software for commercial clients and government institutions.

Connect on LinkedIn