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?