6

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

我见过在每个接口上重新定义基本相同的枚举的软件，当它被传递到另一个模块时具有翻译功能。

例如，接口 IModule1 可能有

enum module1_state
{
    Unknown, 
    NotRunning,
    Running
}

和接口 IModule2 可能有

enum module2_state
{
    Unknown,
    NotRunning,
    Running
}

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

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

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

谁能告诉我哪个是最佳实践？

4

2 回答 2

3

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

于 2012-12-22T21:53:25.153 回答
2

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

尽管如此，正如我们许多人所知，代码的形状和架构往往反映了负责组织的形状和架构（康威定律，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，并且任何一个组织都可能不想依赖另一个；结果可能是这样的复制。

于 2012-12-22T21:44:48.907 回答