Objective C has a concept of a nil object which would accept any method call with any parameters without complaining and silently return another nil.
I have used something similar in Java using easymock and mockito for testing. Is there something similar for main line code? Is it even a good idea to have something like this?
One use-case where I am considering using it is with optional metrics. We have codahale metrics counters on which we call mark() every time an event is generated. This is surrounded by an If/then to check for metrics enabled flag. I could just use a nil object as counter and silently accept the mark call if metrics are not enabled.
5
Java doesn’t have this built in – it’s a programmer error to call a message on null which causes a runtime exception. However, there is a pattern called the Null Object Pattern, which programmers use to provide their own equivalent.
Imagine that you have some interface, representing a connection to a database. You might define the interface like this:
public interface DatabaseConnection {
public void connect(String username, String password, URL databaseLocation);
public void disconnect();
public String executeQuery(String query);
}
Your Null Object might look like this:
public class NullDatabaseConnection implements DatabaseConnection {
public void connect(String username, String password, URL databaseLocation) {}
public void disconnect() {}
public String executeQuery(String query) { return ""; }
}
The disadvantage of doing this compared with the ObjC approach is that you have to write the above code – you can’t automatically get the behaviour by using the nil object. The advantage is that this explicit Null object works as you’d expect in all cases: you can put it into a collection for example, something you can’t do with Objective-C’s nil.
1
This is a fundamental part of the Objective-C runtime. On every single method call, the first thing it does is check if the object reference is nil, and immediately returns if so. The Java runtime surely does a similar check, but responds by throwing a NullPointerException. So you’re asking how to change the fundamental behaviour of the runtime.
There are a couple of ways to achieve a similar effect in Java:
- Create a dummy implementation of your metrics interface that does nothing. Assign this to your metrics object variable.
- or: Create a single, static entry point to your metrics class, and pass in the instance as the first argument, and check if it’s null before doing anything else. e.g.
.
public static void doMetrics(Metrics m, otherArgs ...) {
if (m == null) return;
... do stuff with m ...
}
Both of these come at the minor performance cost of a pointless method call when metrics are switched off.