Build An Expressive Domain With Monads And Polymorphism

Let’s leverage O.O.P. and F.P. patterns to address the Null-Island code smell.

I have recently come across Maximiliano Contieri’s profile and all his insightful posts about various code smells and anti-patterns. Reading through his articles, I found one called “Null Island” and I would like to present you this anti-pattern and two alternative solutions which, in my opinion, helps you enrich your domain model.

The Null Island Code Smell

The “null island” code smell can be succinctly described as code that branches on a nullable field or relies on certain non-null values that are deemed “special by convention”. In the original example written in Kotlin, this location with coordinates (0,0) is one such special value, and it’s meant to represent a person from an unknown location:

val people = listOf(
    Person("Alice", 40.7128, -74.0060), // New York City
    Person("Bob", 51.5074, -0.1278), // London
    Person("Charlie", 48.8566, 2.3522), // Paris
    Person("Tony Hoare", 0.0, 0.0) // Null Island
)

for (person in people) {
    if (person.latitude == 0.0 && person.longitude == 0.0) {
        println("${person.name} lives on Null Island!")
    } else {
        println("${person.name} lives at (${person.latitude}, ${person.longitude}).")
    }
}

After presenting the issue, the article offers a solution that involves implementing new features such as calculating the distance between two Location objects. Notably, the final code handles any exceptions that may arise during this distance calculation by branching out and displaying a different message if the user is coming from an unknown place:

val rio = Coordinates(-22.9068, -43.1729) // Rio de Janeiro coordinates
for (person in people) {
    try {
        val distance = person.location.calculateDistance(rio)
        println("${person.name} is ${distance} kilometers from Rio de Janeiro.")
    } catch (e: IllegalArgumentException) {
        println("${person.name} is at an unknown location.")
    }
}

While this would work, I am trying to stay away from guiding the flow of the application based on exceptions. Moreover, the catch clause “swallows” the exception, leaving no trace of the issue.

In my opinion, there should be no exception here: if a user is allowed not to specify a Location, this represents a perfectly valid flow and it means the domain model should be built in such a way to reflect it.

In light of this code smell, I would like to suggest two expressive solutions. The first approach leverages the power of polymorphism by enabling the Person object to determine what information should be printed. Alternatively, the second solution adopts a monadic approach to Location implementation. By considering these two options, we can effectively tackle this issue and enrich our domain.

The “Polymorphic” Person

As you might have noticed, I’m trying to avoid null as much as possible, almost like it would not exist. I would encourage you to do the same, just don’t ever type the keyword: it will force you to understand your domain better and come up with interesting alternatives.

First solution: since the person can either specify or not a location, we should model two different representations of a Person and avoid aver holding a null reference:

interface Person {
   String name();
}

record GeolocatedPerson ( String name, Location location) implements Person {}

record UnlocatedPerson ( String name ) implements Person {}

Now, let’s “trust” the Person to tell us the distance between him and a different location on the map. We’ll polymorphically implement this in the two representations:

interface Person {
   String name();
   String distanceTo(Location location);
}

record GeolocatedPerson( String name, Location location ) implements Person {
   @Override
   public String distanceTo(Location otherLocation) {
      return "%s is %.2f kilometers from %s".formatted(
          name, location.distanceTo(otherLocation), otherLocation.name()
      );
   }
}

record UnlocatedPerson( String name ) implements Person {
   @Override
   public String distanceTo(Location otherLocation) {
      return "%s lives is at an unknown location, cannot calculate distance to %s".formatted(
          name, otherLocation.name()
      );
   }
}

Now, let’s see how we can use these different implementations of the Person interface:

@Test
void test() {
    var people = List.of(
        new GeolocatedPerson("Alice", new Location("New York", 40.7128, -74.0060)),
        new GeolocatedPerson("Bob", new Location("London", 51.5074, -0.1278)),
        new GeolocatedPerson("Charlie", new Location("Paris", 48.8566, 2.3522)),
        new UnlocatedPerson("Tony")
    );

    var rio = new Location("Rio de Janeiro", -22.9068, -43.1729);
    people.stream()
        .map(pers -> pers.distanceTo(rio))
        .forEach(dist -> System.out.println(dist));
}

The “Monadic” Location

Alternatively, we can encapsulate this logic inside the Location object. To do so, we’ll use an (almost) monadic approach. In other words, the Person will always have a Location, but the location itself can be either known or unknown.

For expressing these two possible states of the Location without keeping a null or Optional reference, we’ll use, yet again, polymorphism:

public interface Location {
    String name();
} 

record KnownLocation( double longitude, double latitude ) implements Location {
    @Override
    public String name() {
        return "(%s, %s)".formatted(longitude, latitude);
    }
}

record UnknownLocation() implements Location {
    @Override
    public String name() {
       return "Null Island";
    }
}

For convenience, we can add some static factory methods in the public interface:

public interface Location {
    String name();

    static Location of(double longitude, double latitude) {
        return new KnownLocation(longitude, latitude);
    }

    static Location unknown() {
        return new UnknownLocation();
    }
}

Lastly, we need to add the method for calculating the distance. If we add it to the common interface, the UnknownLocation will throw an exception while implementing it: this would be a clear violation of Liskov’s Substitution Principle and a bad practice overall. Therefore, we’ll only add this method inside the KnownLocation class:

record KnownLocation(double longitude, double latitude) implements Location {
    @Override
    public String name() {
        return "(%s, %s)".formatted(longitude, latitude);
    }

    public double distanceTo(KnownLocation other) { 
        retrun ...; // the calculation goes here
    }
}

Now that we have this functionality, the next question is how to make the most of it. One potential approach is to adopt a strategy similar to that used by the Optional API. For instance, we can implement methods like ifKnown or ifKnownOrElse to help us leverage the available data in a convenient and effective way:

interface Location {
    String name();

    static Location of(double longitude, double latitude) {
        return new KnownLocation(longitude, latitude);
    }

    static Location unknown() {
        return new UnknownLocation();
    } 

    void ifKnownOrElse(Consumer<KnownLocation> action, Runnable orElse);
}


record KnownLocation( double longitude, double latitude ) implements Location {
    @Override
    public String name() {
        return "(%s, %s)".formatted(longitude, latitude);
    } 
    @Override
    public void ifKnownOrElse(Consumer<KnownLocation> action, Runnable orElse) {
        action.accpet(this);
    }
}

record UnknownLocation() implements Location {
    @Override
    public String name() {
       return "Null Island";
    } 
    @Override
    public void ifKnownOrElse(Consumer<KnownLocation> action, Runnable orElse) {
        orElse.run();
    }
}

Finally, let’s put everything together and see how to use this monadic Location object:

@Test
void test() {
    var people = List.of(
        new Person("Alice", Location.of( 40.7128, -74.0060)),
        new Person("Bob", Location.of( 51.5074, -0.1278)),
        new Person("Charlie", Location.of(48.8566, 2.3522)),
        new Person("Tony", Location.unknown())
    );

    var rio = new KnownLocation(-22.9068, -43.1729);
    people.forEach(pers -> pers.location().ifKnownOrElse(
            loc -> System.out.println("%s is %.2f kilometers from Rio".formatted(pers.name(), loc.distanceTo(rio))),
            () -> System.out.println("%s is at an unknown location".formatted(pers.name()))
        )
    );
}

A Word On Monads

If a hardcore functional programmer will look over this implementation, they will quickly argue that this is not a real monad. We actually followed the pattern but only implemented what we needed for the use case at hand.

To wrap up, if we want to follow the functional patterns in the book, we might want to implement some functions that can change the geolocation itself, without leaving the dual nature of the monadic object.

For instance, this will be an example of a “functor” (similar to Optional.map, Flux.map, or CompletableFuture.thenApply):

interface Location {
    // ...
    Location moveToTheNorth(int kms);
}

record KnownLocation( double longitude, double latitude ) implements Location {
    // ... 
    @Override
    public void moveToTheNorthint(int kms) {
        return new KnownLocation(loc.latitude + kms, loc.longitude);
    }
}

record UnknownLocation() implements Location {
    // ... 
    @Override
    public void moveToTheNorthint(int kms) {
        return this;
        // if it is an UnkownLocation, it will remain unkown
    }
}

Additionally, a “true” monad will also have an equivalent of the flatMap method, but this will be pretty hard to showcase in our context. If you want to read more about Mondas in general, and Optional in particular, I’ll invite you to read one of my previous articles and let me know what you think:

Conclusion

In this article, we’ve discussed the anti-patterns of branching on nullable references or exceptions. Then we leveraged polymorphism and the monad pattern to eradicate null references and unnecessary exceptions from our code.

I invite you to review the two solutions and see how the domain model benefits from avoiding these two. In my opinion, our model is now much more expressive and the optionality of the Location field is now obvious.

I encourage you to check out other articles written by Maximiliano Contieri on his page: https://mcsee.medium.com/about

Thank You!

Thanks for reading the article and please let me know what you think! Any feedback is welcome.

If you want to read more about clean code, design, unit testing, object-oriented programming, functional programming, and many others, make sure to check out my other articles. Do you like the content? Consider following or subscribing to the email list.

Finally, if you consider becoming a Medium member and supporting my blog, here’s my referral.

Happy Coding!

Level Up Coding

Thanks for being a part of our community! Before you go:

• 👏 Clap for the story and follow the author 👉
• 📰 View more content in the Level Up Coding publication
• 💰 Free coding interview course ⇒ View Course
• 🔔 Follow us: Twitter | LinkedIn | Newsletter

🚀👉 Join the Level Up talent collective and find an amazing job