假设有一个在两个层次上开发的库：一个核心，一个低层次和一个高层次。我的设计侧重于减少两者之间的耦合。封装枚举或不？
其中一个高层次的例程接受枚举（例如，FOO = 0，BAR = 1，BAZ = 2）。该枚举由低级例程直接用于其最终目的。
为了设计此，我有三种选择：
您对此案有任何经验吗？我会选择1，因为它会减少耦合，但我也想听听你的经验。
听起来像是你的高层次层接受来自用户的指令或参数，它一起传递低层次，而实际上并不需要知道它说什么。
如果是这种情况，那么选项＃3：“打破它”是一条路。
如果高层需要对命令或参数进行一些处理，并且它必须传递给底层，那么很有可能在选择之间划分了一些界限层。各层不应该关心彼此的内部业务。
如果你确实需要这样做，那么分解就更加重要了，因为你希望BOTH层依赖于枚举，并且你希望枚举中的一个改变迫使（至少）重新编译双方。 （make，dependencies等）
阅读Dijkstra的经典论文“多程序系统的结构”，并反思它对分层哲学的看法。它位于UT Austin CS部门网站的Dijkstra档案中。
我想这取决于你的关卡是层还是层。
如果低级模块位于Web服务接口后面，那么我会选择通过为您生成的代理代码（当然在WCF或amsx服务的情况下）实质上实现的＃1。
如果它们是在同一个进程中运行的不同程序集，那么我会更倾向于采用共享代码解决方案，可能是通过创建具有核心枚举和接口的单独程序集。
我没有得到太多的耦合问题。恕我直言，这两个级别应该看到相同的枚举（更像是选项3）。枚举中的名字应该是高级名称（所以谁读它，可以理解它们，不需要理解低级名称），其值对于高级别部分应该是不重要的。
我看到的第一个问题是更大的维护成本和更容易出错的错误。就像，假设一个枚举值改变了，或者你应该添加另一个元素。您必须记得在两个部分中进行更改，否则，您的应用程序可能会出现意外行为和不一致的数据。此外，您将需要一个转换层，从而导致更多的代码维护
希望它能帮助:)