Handling "unspecified" values in software

Question

So I'm working on a software product where we have a number of fields that the customer can leave blank, some of which are numeric. To persist these in the database we use nullable columns. Easy peasy.

I'm considering the utility of an object oriented domain model and one thing that bugs me is the issue of nullable fields.

The reason is, in the world of Java and C# one often finds advice against having null values and indeed writing code with null checks all over the place sucks. And then you get null reference exceptions when you forget to check for null. And it's a mess. So a "good" approach is to initialize everything when you declare it.

Now, the idea of null actually makes sense for these fields... the customer did not enter a value thus it has "no" value (not 0, not -1, etc). But application programmers and programming languages seem to be configured for binary rather than ternary logic, and also for variables just darn well having a value rather than maybe having a value but also maybe not.

With object oriented design I presume one could come up with some clever system of representing cases where there is "no" value but I personally haven't done the analysis yet and the reason is I find incremental change more successfully sells to people than radical change does, so proposing an object oriented domain model that's "too object oriented" might kill the idea and thus my hopes of improving the structure of our software. I'd rather propose a "version 0" domain model that works and is easy to sell internally... and so this whole thing about null values weighs heavy on my mind.

Since we are using C# I could just define nullable numbers, its very easy one just adds a question mark. But I'm not convinced that just because it's possible it's also the best approach.

So, with all this background junk out of the way my question is: how have you/your company handled "nonexistent" values in an object oriented domain model, in what ways did you find it effective and in what ways did you find it ineffective?

My selection criteria for the "answer" will be the one that seems most "sellable" as defined in the background junk. But really I'd like to see what people come up with and learn some new things so any answer with some thought behind it will receive an upvote from me.

Note: I've seen other discussions about null values in other threads but nothing that quite lines up with what I want to talk about, hence a new question.

EDIT: My question's scope includes value typed properties like numbers. So in C# one way to allow for representation of a null purchase price would be to declare "PurchasePrice" as "decimal?" which is the nullable decimal type. I just see a number of disadvantages to numbers (for example) that can also be null, so I'm looking for an alternative.

EDIT 2: The Null Object Pattern makes sense for references, and using a nullable type for values appears as if it may be tractable with coalescing. What bothers me about coalescing null types is "what if someone forgets to coalesce and we're exposed to a null reference exception?"... and I suppose I could maybe use a static analysis tool which ensures that coalescing is used where expected to allay that worry.

EDIT 2': In a sense, if someone has made a conscious decision to make a field nullable they are adding the ability to represent an extra piece of information that would otherwise need another field to represent it such as a boolean HasValue. Does that mean the "anti-null" zealots I've met in the past were perhaps incorrect, and measured use of nullity can in fact improve a design?

Answer 1

I think you are mistaking something here. The problem of null in languages like Java and C# is that reference types are null by default. Eg, the null is implicit. That means there is no way to express idea of reference type always having a valid value. You always have to check for null. Even if you are sure the value cannot possibly be null, the Murphy's law says it will happen sometime, so checking is necessary. There is no way to have compiler do the checking for you. Of course there are ways like code contracts, but those are relatively new in those languages and require additional work from developer to do right.

The way Nullable value types work is exactly how it should work. The compiler knows there is one additional state and knows how you work with the variable. So it can create an error when it sees there is possibility dereferrencing this null state. For example, you cannot add Nullable<int> and int simply because compiler knows there is possibility of first value being null. So it forces you to do the checking before hand. Even simple assignment from nullable to non-nullable type is checked by compiler simply thanks to it's type. No such thing is possible for reference types. Of course there is problem of programmer just adding .Value to every access and be done with it, but that is problem of programmer's discipline that no tool can fix.

Summed up. Your worries about nullable value types are completely unjustified because null is only problem when it is implicit and compiler cannot check for possible errors of accessing null value. Which is not the case of Nullable value types.

Answer 2

There is a pattern called NullObject.

The only reason why I would say this can sell is that your tests whether this object is NUll or not are in the NUll object and thus... When your software grows there is exactly one place to look for NULL-value-behaviour. Code duplication is removed suppose:

function1(x) {
    if x is NULL {
        handleit(x)
    }
}

function2(x) {
    if x is NULL {
        handleit(x)
    }
}

The two functions are in a different location or class so the handleit(x) can not be reused (forgotten/typechecks) if it is not in the Null-Object.

There are other people to reason about software quality and why it is good. Be aware that your design decision is about your developers now and future developers.

I used this pattern once and it worked quite well. I think if you answer the following question with yes then the Null Object is not too far from your choice:

Should the code that affects the object be in the object?

Edit1: value types

Seeing http://msdn.microsoft.com/en-us/library/ms173104.aspx you can create own value types. So you can create own value type null objects. Value types are an optimization of the programming language. For code pieces where optimization is necessairy you can use them. And otherwise use the reference types.