Question

Let’s say I have an interface ICustomerService and this interface requires an enum, e.g. ProcessingMode:

namespace MyServices {
    public enum ProcessingMode { Immediate, Normal, Slow }

    public interface ICustomerService {
        void Process(ProcessingMode mode);
    }
}

The enum can’t be defined inside the interface in C# (but apparently in VB?). But having it outside the interface clutters the containing namespace MyServices. Not good, since other interfaces might also require a different enum called ProcessingMode.

So are there any “best practices” how to solve this?

I can see a few options, but none of them seems quite right to me:

1. Put both the interface and the enum in a service-specific namespace:

   namespace MyServices.CustomerService {
       public enum ProcessingMode { Immediate, Normal, Slow }
   
       public interface ICustomerService {
           void Process(ProcessingMode mode);
       }
   }
   

   While it works and avoids clutter in the containing namespace, it does cause namespace proliferation, and I guess a service implementation might clash with the namespace or duplicate it: MyNamespace.CustomerService.CustomerService. Or where would you put the service implementation and what would you call it?

2. Put just the enum in a separate namespace (or a static class):

   namespace MyServices {
       namespace CustomerServiceTypes {
           public enum ProcessingMode { Immediate, Normal, Slow }
       }
   
       public interface ICustomerService {
           void Process(CustomerServiceTypes.ProcessingMode mode);
       }
   }
   

   Same problems as option 1 but also requires a enum name to be qualified “everywhere”.

3. Prefix the enum name, e.g. CustomerServiceProcessingMode. Avoids namespace proliferation and risk of name clashes with service implementations, but causes long ugly enum names.

So how would you do it?

Answer 1

Just because it is the customer service that does the processing doesn’t mean you have to name the enum “CustomerService…..” – if the enum is for the Customer then just call it CustomerProcessingMode; especially if the enum is going to be a property on the business class.

If there will be many ways of processing the customer which will require different processing modes then you will have to use the name of the service instead, but the reason you don’t like the look of the name is because your service name is rubbish 🙂 “CustomerService” – what does that do exactly?

MailingService (which runs on implementers of an interface) would be a good example for a service, because the name tells you what the service does, NOT what it works on. Even “CustomerRepository” is a good name because the name tells you what it does.

1. Use the namespace MyModel.Services
2. Use a name for your service which explains what it does rather than what it works on
3. Then you end up with a nice descriptive (and unique) enum name like “MailingPriority” instead

Naming services “CustomerService” has no indication of the task of the service, and usually end up performing anything and everything to do with customers – kind of a “Swiss Army Knife” service which should really have a single focussed task rather than be a catalogue of everything one can do with a customer.