Are bitmasks ever a good way to model if a work request has one or more statuses currently applied, and what would work better?

Question

Summary

Need to be able to tell if a work request has one or more statuses currently applied to it, and be able to remove statuses without affecting other statuses applied. Currently, the work request can only have one status at a time, and the code for determining what the 'most important' status is keeps growing.

SQL server back end, C# with EF (mostly) for data access

Background

I'm working on an application where we have a work request where the status changes as people do specific activities until the request is finished. There are close to 30 statuses that the request can have, and there are many instances where we need to know if one or more statuses have been applied to the work request (to determine what happens next).

Currently the request has a single status that reflects the most current status, and when we change the status it has to go through code that looks at other associated data to determine what the 'most important' status is and change the request to that one.

This business problem seems to be perfect for using bitwise calculations, but I don't want to resort to an obsolete practice. The other possibility is to just have a collection of statuses and add/remove from the list.

Thanks

Answer 1

X DO NOT use an enum for open sets (such as the operating system version, names of your friends, etc.).

[Microsoft Framework Design Guidelines].

Your use case sounds like an open set that will be added to over time. So based on that alone I'd say enum's are not right for this use case.

X AVOID creating flag enums where certain combinations of values are invalid.

Additionally it doesn't sound like all the values from your enum can be combined and still be valid.

Lastly here's a comment from Steven Clarke from the published copy of the Microsoft Framework Design Guidelines about the complexity in your proposed use of enums:

I'm sure that less experienced developers will be able to understand bitwise operation on flags. The real question, though, is whether they would expect to have to do this. Most of the APIs that I have run through the labs don't require them to perform such operations so I have a feeling that they would have the same experience that we observed during a recent study - it's just not something that they are used to doing so they might not even think about it. Where it could get worse, I think, is that if less advanced developers don't realize they are working with a set of flags that can be combined with one another, they might just look at the list available and think that is all the functionality they can access. As we've seen in other studies, if an API makes it look to them as though a specific scenario or requirement isn't immediately possible, it's likely that they will change the requirement and do what does appear to be possible, rather than being motivated to spend time investigating what they need to do to achieve the original goal.

What follows are just some thoughts about enums should you go this route:

DO name flag enums with plural nouns or noun phrases and simple enums with singular nouns or noun phrases.

DO use powers of two for the flag enum values so they can be freely combined using the bitwise OR operation.

Answer 2

I don't think there is anything necessarily wrong with using a flagged enum for your status. To clarify, I think there are two things you are talking about. The set of actions that have been done for a request, and then some sort of derived value that you want to communicate to the user as being the most important value. Think this could be handled by doing a flagged enum, and then a property that is derived from your status enum (you might already be doing this). I would also recommend keeping a log of when each status was applied to a request in a separate entity.

As far as enforcing your statuses goes, one thing you could try is to represent your process as a directed graph of each of the steps. Then that data structure can be used to determine if all the conditions are met to move to the next step in your process.

[Flags]
public enum Status
{
    Unknown = 0,
    Completed = 1,
    Blocked = 2,
    Phase1 = 4,
    Phase2 = 8,
    Phase3 = 16,
    Closed = 32
}

public class Request
{        
    public string Name { get; set; }
    public string StatusText { get { return GetStatusText(); } }
    public Status Status { get; set; }

    public Request()
    {
        this.Status = Status.Unknown;
    }

    private string GetStatusText()
    {
        string statusText = "Created";

        if (AnyStatus(Status.Closed | Status.Completed))
        {
            statusText = IsStatus(Status.Closed) ? "Closed" : "Completed";
        }
        else
        {
            if (IsStatus(Status.Blocked))
            {
                statusText = "Blocked";
            }
            else
            {
                if(IsStatus(Status.Phase3)) {
                    statusText = "Phase 3";
                }
                else if(IsStatus(Status.Phase2)) {
                    statusText = "Phase 2";
                }
                else if (IsStatus(Status.Phase1))
                {
                    statusText = "Phase 1";
                }
            }
        }

        return statusText;
    }

    private bool IsStatus(Status checkStatus)
    {
        return ((this.Status & checkStatus) == checkStatus);
    }

    private bool AnyStatus(Status checkStatus)
    {
        return ((this.Status & checkStatus) > 0);
    }
}

Possible class for logging status changes

public class StatusLog
{
    public int RequestId { get; set; }
    public int UserId { get; set; }
    public DateTime Date { get; set; }
    public Status Status { get; set; }
}