Nullable Enumeration Values vs. NoValue or Undefined

coding-styleenumnullprogramming practices

I often write code which translates entities in the database to domain objects. These entities often have fields which are constrained and translate to enumerations in the domain objects. In some cases, though, the fields can be null.

For example, imagine I have a PrintJob entity with a Status field that can be New, Submitted, or Completed and a Result field that can be Succeeded, FailedNoPaper, or FailedNoToner but it can also be NULL if the Status is not Completed.

On the one hand, I like having a one-to-one mapping of entity field values to domain object enum values, but on the other hand, it somehow feels "better" to always have values for properties with enumeration types.

My question is: is it better to represent the value of the Result field in my domain object as a nullable value (e.g. MyStatus? in C# or VB.NET) having essentially no value when the corresponding entity field is NULL, or should I create a special enum value along with the others, e.g. NoValue or Undefined?

Best Answer

If a field value is one of a list of predefined values, your domain will have a real-world value that you can correspond to NULL. All you have to do is look for it. If the Status is not completed its result could be 'NotFinished', 'Unavailable', 'DoesNotExist' or 'Unknown'.

Think about this in a non-code way. If you print something and ask a colleague to bring over the stack of papers from the printer, how would he let you know that there is no printout on the printer? He might say it isn't finished yet, it wasn't available yet, there was nothing on the printer...

As far as enums go, I'm not a big fan of nullable enums. Add a single, default field such as 'Unknown' and you NEVER EVER have to worry about it being NULL. Otherwise, you will spend reams of code in your application to first check for NULL before doing anything sensible... Enums, like booleans, should shy away from being NULL.

Related Solutions

C# Programming Practices – When and Why to Use Void Instead of Bool/Int

In the case of a bool return value to indicate the success or failure of a method, I prefer the Try-prefix paradigm used in various in .NET methods.

For example a void InsertRow() method could throw an exception if there already exists a row with the same key. The question is, is it reasonable to assume that the caller ensures their row is unique before calling InsertRow? If the answer is no, then I'd also provide a bool TryInsertRow() which returns false if the row already exists. In other cases, such as db connectivity errors, TryInsertRow could still throw an exception, assuming that maintaining db connectivity is the caller's responsibility.

Java: would you use an EnumSet in this case

I rather avoid things like

ViewStatus viewStatus;

since it introduces a new class without giving you anything in return when compared to

boolean isViewed;

But that's a matter of personal taste.

By setting the reference to null you can have a third value, which is not really good, since you can get an unexpected NPEsomewhere; null is just no "first class value".

EnumSet pretty much exists specifically for this purpose, but... it seems like just two much overhead. Especially when reading the values in the part of the code that builds the HQL.

The overhead of an EnumSet is reasonable, it caches the class and an array of all values, and uses a long for storing the data (as long as the enum is small enought). Its equals method is quite fast, but obviously slower than reference comparison. You mentioned using HQL, so most probably the runtime will be dominated by the database access, so IMHO you're needless and premature optimization.

The mutability of the EnumSet may be a problem sometimes, but there's ImmutableEnumSet in guava.

I'll go for an EnumSet because I want to introduce methods on that enum that wouldn't make sense to be called on ALL. For example ViewStatus.isViewed().

I don't think you stated all your alternatives right. You can have both

enum ViewStatus {VIEWED, UNVIEWED}

and

enum ViewStatuses {VIEWED, UNVIEWED, ALL}

where the second is an replacement for the EnumSet. That said, I agree with your decision.

Best Answer

Related Solutions

C# Programming Practices – When and Why to Use Void Instead of Bool/Int

Java: would you use an EnumSet in this case

Related Topic