Question

在过去，你经常有一个“低级别”的数据模块，不依赖于任何其他模块，但可以被它们引用，例如获取整个系统中使用的枚举。
现在，我们在模块之间具有面向对象的接口，具有调用和事件。我的问题是，我们是否还应该在一个地方定义整个系统中使用的枚举，这些枚举应该由需要它们的每个接口引用？

我见过的软件在每个界面上重新定义了相同的枚举，并在传递到另一个模块时使用了转换函数。

例如，接口IModule1可能有

enum module1_state
{
    Unknown, 
    NotRunning,
    Running
}

和IModule2接口可能有

enum module2_state
{
    Unknown,
    NotRunning,
    Running
}

其中模块1例如收集数据，模块2执行一些逻辑，然后将数据进一步传递给第三模块，例如，模块。一个GUI。

在许多情况下，枚举会真正不同，因为例如，第二个模块可以抽象掉第三个模块不需要的一些信息，并传递简化版本。
但在某些情况下，它们并没有什么不同，我认为枚举仍然在每个界面上重新定义。一个示例是作为几个不同用例的一部分执行的操作。操作是相同的，但根据用例，几个小细节是不同的。携带用例细节的枚举通过接口传递到高级逻辑模块，然后通过另一个接口传递到较低级别模块。它在每个接口上重新定义，因此必须在高级逻辑模块中进行转换。

还有一些其他模块只是将较旧的现有接口转换为较新的接口，同样，两个接口都重新定义了相同的枚举。

谁能告诉我哪种是最佳做法？

Answer 1

这是代码组织，模块化和重用的问题。对于两个模块重用第三个模块（在同一个解决方案中考虑项目）可能是有意义的，但如果它们是单独的bounded contexts（思考解决方案）的一部分，它们会独立发展并且通常应该使用单独的定义。您看到的映射在单独的有界上下文之间应该是正常的，但是枚举应该可以在相同的上下文中统一。

Answer 2

C＃和Java的现代DLL机制都允许重构将常见的东西 - 在您的问题的情况下，枚举 - 移动到其他人共享的公共DLL中;正如你所指出的那样，利用这一点似乎毫无疑问。

尽管如此，正如我们许多人所知，代码的形状和架构往往反映了负责组织的形式和架构（Conway定律，http://en.wikipedia.org/wiki/Conways_Law）;代码不只是满足要求，而是关于作者，控制和责备（时间表和项目管理），以及维护责任;这些导致代码结构反映组织结构图的结构。

（另请参阅http://blogs.gartner.com/ray_valdes/2008/09/19/organizational-structure-vs-product-architecture-which-one-wins/）

所以，当我看到你正在描述的东西时，我想知道是否有一些组织结构和政治在起作用。有人必须拥有共同的DLL，并且org可能都不想依赖于另一个;结果可能是这种复制。

在C＃中的每个面向对象的接口上重新定义相同的枚举

2 个答案: