假设我有一个接口ICustomerService
,这个接口需要一个枚举,例如ProcessingMode
:
namespace MyServices {
public enum ProcessingMode { Immediate, Normal, Slow }
public interface ICustomerService {
void Process(ProcessingMode mode);
}
}
无法在C#中的界面内定义枚举(但显然在VB中?)。但是将它放在界面之外会使包含的命名空间MyServices
变得混乱。不好,因为其他接口可能还需要一个名为ProcessingMode
的不同的枚举。
那么有什么“最佳实践”如何解决这个问题?
我可以看到一些选项,但对我来说似乎都没有:
将接口和枚举放在特定于服务的命名空间中:
namespace MyServices.CustomerService {
public enum ProcessingMode { Immediate, Normal, Slow }
public interface ICustomerService {
void Process(ProcessingMode mode);
}
}
虽然它可以工作并避免包含命名空间中的混乱,但它确实会导致命名空间扩散,我想服务实现可能会与命名空间冲突或复制它:MyNamespace.CustomerService.CustomerService
。或者您将服务实现放在哪里以及您将其称为什么?
将枚举放在单独的命名空间(或静态类)中:
namespace MyServices {
namespace CustomerServiceTypes {
public enum ProcessingMode { Immediate, Normal, Slow }
}
public interface ICustomerService {
void Process(CustomerServiceTypes.ProcessingMode mode);
}
}
与选项1相同的问题,但也要求枚举名称“无处不在”。
作为枚举名称的前缀,例如CustomerServiceProcessingMode
。避免命名空间扩散以及与服务实现发生名称冲突的风险,但会导致长丑陋的枚举名称。
那你怎么做呢?
答案 0 :(得分:3)
只需将interface和enum放在一个名称空间下即可。在任何情况下,您都必须制作enum
public
,因为您在服务中使用它。因此,通过将interface和enum放在一个名称空间下,使接口的实现者只包含一个名称空间。
赞System.Drawing
有Color
枚举。
答案 1 :(得分:2)
仅仅因为客户服务处理并不意味着您必须将枚举命名为“CustomerService .....” - 如果枚举是针对客户的,那么只需将其称为CustomerProcessingMode;特别是如果enum将成为商务舱的财产。
如果有许多处理客户的方法需要不同的处理模式,那么您将不得不使用服务的名称,但是您不喜欢名称外观的原因是因为您的服务名称是垃圾:)“CustomerService” - 这究竟是做什么的?
MailingService(在接口的实现者上运行)将是服务的一个很好的例子,因为该名称告诉你服务的作用,而不是它的作用。甚至“CustomerRepository”也是一个好名字,因为名称会告诉你它的作用。
命名服务“CustomerService”没有任何关于服务任务的指示,并且通常最终会执行任何与客户有关的事情 - 这种“瑞士军刀”服务应该真正具有单一的重点任务,而不是是一个可以与客户做的一切的目录。
答案 2 :(得分:1)
我可能会使用两者的组合:
我不会担心碰撞名称,你的枚举名称是服务合同的一部分,就像接口名称一样。您真的不担心有人在同一名称空间中定义相同的接口,对吗?对于作为合同一部分的枚举和其他公共类型也是如此。
答案 3 :(得分:0)
我会选择#3。名称应该是描述性的,乍一看显示它们的用途。这个名字的长度对我来说不是标准。如果有多个具有不同含义的ProcessingMode
枚举,我会觉得更加恼火。
只是我的2岁......