Create an enum similar to the "Name" property of a class

Question

Our team has been slowly refactoring code to implement SOLID practices and enforce better naming conventions. We have run into a problem where we have an enum that is currently named the same thing as another class we need to create -- "Department."

Right now, we have an enum that represents the different departments, for example:

Department.HumanResource
Department.InformationTechnology

This allows us to use that enum to quickly refer to departments based on a friendly name rather than an underlying integer ID in situations like this:

Employee.IsInDepartment(Department.InformationTechnology)

It's not a "Type" or "Status" or something like that which is a common way to name enums. We thought maybe something like "DepartmentName" but that felt a little strange, because the department class will have the "Name" property, and this enum should also be a property on the Department class.

I realize naming is subjective, so I want to pose the questions:

Are we looking at this from the wrong perspective? Is there another way to accomplish this that we are overlooking?

Answer 1

Since you mentioned wanting to have the "enum" be a representation of functional classes (but not necessarily have the class' data loaded every time you use the reference), you might consider an approach like this. It would enable the code to feel like an enum, function like a class, but not make any unnecessary trips to the data store to fill properties until they're needed.

public class Department
{
  public int ID { get; private set; }

  //follow this pattern for property values that need to be populated from a data store.
  private string name;
  public string Name
  {
     get{ EnsureLoad(); return name; }
     set{ EnsureLoad(); name = value; }
  }

  public static Department HR{ get{ return GetEmptyDepartment( 1 ); } }
  public static Department IT{ get{ return GetEmptyDepartment( 2 ); } }

  private static Department GetEmptyDepartment(int departmentId)
  {
       return new Department()
       {
           ID = departmentId
       };
  }

  private void EnsureLoad()
  {
     //if not loaded
     //lazy load properties using the ID property against the data store.
  }
}

Answer 2

In all those cases (it pops up a lot, though your example is extremely flawed) I generally name the enum as <thing>Type, or in your case DepartmentType. It can be argued whether or not it's 100% correct, but it easily gets the point across.

As to why that's flawed, the actual list of departments should be coming from a database because this list evolves over time. You don't want to keep recompiling your project every time you add a new department in your enterprise.

Answer 3

Sorry this is DepartmentType and also the approach for best practices in naming conventions whether you like it or not, you have a concrete class and this MUST BE NAMED AS Department if you want to follow best practices, that leaves us with the enum that has to be DepartmentType following best practices in naming conventions, so since you need both class and enum, i would implement it like this:

Create Enum:

public enum DepartmentType {IT, HR,..... }

in the Department class, add that Enum as property as well:

public Class Department
{
  public Name {get;set;}
  .
  .
  .

  public DepartmentType {get;set;}

}

Now you can use DepartmentType enum whether you have department object or you want to use it as plain in any method.

EDIT

Another way is to get rid of the Enum and create static int values in your Department Class:

   public class Department
    {
       Public string Name {get;set;}
       ...
       ...
       ...
       public static readonly int IT = 1;
       public static readonly int HR = 2;
     }

so now you can use it as Department.IT , Department.HR,..... without the need to instantiate an object of Department class, in short its used like Enum.

Answer 4

It depends. What are you looking to accomplish with the enum? If you're looking to key off of different department types irrespective of what the department happens to be named, then having enum DepartmentType makes perfect sense. For example:

if (department.Name == "Information Technology")

can be bad if your IT department's name has changed but you still want to perform the same actions on that department. However,

if (department.Type == DepartmentType.InformationTechnology)

doesn't care what the name of the department is; as long as it represents an IT department, your application still works.

Also, as mentioned in other answers, if you're looking to uniquely identify a department you really want to be using its primary key. You can still gain readability in your code by assigning static readonly fields to your class:

public static readonly int InformationTechnology = 1;

which lets you access IDs without referring to the number explicitly:

if (department.Id = Department.InformationTechnology)

although the downside to this approach is that you still have to recompile your code when a new Id is added if you want to continue checking without magic integers.

Answer 5

Use consts inside your class:

public class Department
{

     //Property to hold the department ID
     public int DepartmentID{ get; set; }

     public const int HumanResources = 1;
     public const int InformationTechnology = 2;
     //And so on..

}

Then if the Employee.IsInDepartment expects an int you can use:

Employee.IsInDepartment(Department.HumanResources)...