ephipany: the path to null-safety is the zero-method value object

Or, The Zen Of Zero-Method Value Objects...

I had an ephiphany the other day.

The path to null-safety is the zero-method value object.

Rationale: an interface that defines no methods cannot result in the generation of call-site that causes a NullPointerException for the simple reason that if there is no method, there can be no call. If there is no call, there can be no NullPointerException

Example 1: What you can't call, can't blow up

interface DangerousDateRange
{  
    boolean contains(Date operand);
}
DangerousDateRange dateRange = ...;

...

dateRange.contains(date); // legal, but potentially unsafe



interface SafeDateRange
{  
}
SafeDateRange safeDateRange = ...;

...

safeDateRange.contains(date); // illegal, but very safe

Ok, trivial point you say. But what use is a zero method value object? How useful can that really be? After all, how can a date range answer the contains question if it has no contains() method in the first place?

How useful? Very.

A zero-method object can still be the container of state, namely the value.

Operations can be performed on another interface. The interface can be well defined, even for the null reference.

Example 2: Making a zero-method value interface useful

interface SafeDateRange
{
   // here is where the value contract goes ...

   interface Ops
   {
       boolean contains(Date date);  
       SafeDateRange asValue();
   };

   // here is where we store state ...

   private class Impl extends SafeDateRange
   {
        private final Ops ops;

        private Impl(final Date lower, final Date upper)
        {
            ops = 
                new Ops()
                {
                    boolean contains(Date date)
                    {
                       // ... whatever
                    };

                    SafeDateRange asValue()
                    {
                         return Impl.this;
                    }       
                };
            }

        }            
        Ops asOps()
        {
                return ops;
        }
   }

   // this is how we generate new values

   BinaryOp<Date, Date, Ops> NEW = new BinaryOp<Date, Date,  Ops>()
   {
         Ops apply(final Date lower, final Date upper) { return new Impl(lower, upper); }
   }

   // and this is how we provide access to the behaviour
   // in a null-safe manner

   UnaryOp<SafeDateRange, Ops> OPS = new UnaryOp<SafeDateRange,  Ops>()
   {
        Ops apply(final SafeDateRange ops) 
        {
             if (ops instantof Impl)
             {
                 return ((Impl)ops).asOps();
             }
             else 
             {
                 // and this is how we make it null-safe 

                 return new SafeDateRange.Ops()
                 {
                     boolean contains(Date date)
                     {
                         return true;
                     }

                     SafeDateRange asValue()
                     {
                         return null;
                     }
                 }
             }
         }
   }

}

Example 3: Using A Null Safe Date Range

SafeDateRange safeDateRange = SafeDateRange.NEW.apply(lower, upper).asValue();
SafeDateRange.Impl impl = null; //illegal - can't declare impl

SafeDateRange.OPS.apply(safeDateRange).contains(test); // safe, legal, well-defined
SafeDateRange.OPS.apply(null).contains(test); // safe, legal, well-defined

impl.contains(test);    // illegal: impl can't have been declared in the first place

Example 4: Caveat: There will always be idiots...

class Foo
{
    SafeDateRange     safe;    // always do this
    SafeDateRange.Ops unsafe;  // almost never do this 
}

Foo foolish = new Foo();

...
SafeDateRange.OPS.apply(foolish.safe).contains(test); // legal, safe
foolish.unsafe.contains(test);                        // legal, unsafe

Yep, there will always be idiots. But hopefully you can teach idiots that declaring long-lived references (e.g. member variables) to SafeDateRange.Ops is almost always a bad thing. Exception: if you can guarantee, by construction, that a reference to SafeDateRange.Ops is never null, you can relax this rule. Update: Thinking about this further - declaring a Ops reference is fine and (for performance reasons probably preferable), but you have to ensure that it is never null to use it safely. See my later post for a discussion of this.

Credit Where Credit Is Due

I am almost certain that I am not the first to discover the zen of zero-method value objects so if you have seen this or a similar idea written up before, please let me know and I'll will include a reference to that place.

It would not surprise me, for example, if this is very similar to one of Tony Morris's ideas.

Update:

As suspected, this is something addressed by Tony Morris' functional java, as per this response from him

Hi Jon,
What you are discovering has this catamorphism:
λa.λx. (a -> x) -> x -> x

To translate that to Java:

interface Function { Y apply(X x); }
interface Thunk { X apply(); }
interface Nullable<A> {
  X cata(Function s, Thunk n);
}

It's available in Functional Java

Many (non-total) languages do not have null.

And this:

Haskell calls it Maybe, ML calls it option, Scala calls it Option,
Functional Java calls it Option. Note that it (the type constructor)
is a covariant functor and a monad. The catamorphism is the important
part. You can use languages that simply don't have null, or assume
language subsets without it (many Java users do). You can also write
in languages that guarantee termination i.e. all total functions (with
some sacrifices of course) e.g. Agda, Coq, Isabelle.