组件设计:正确的内聚力

Question

我现在有一组组件，名为DataValues、ValueParsers、ValueFormatters和ValueValidators。第一种方法定义了一个抽象基类DataValue，并包含了全部实现。其他三个组件都在接口中定义了类似于它们的名称(减去"s")，并且还包含了这些实现的一些实现。这3项依赖于DataValues。不再存在依赖关系。

换句话说，每个组件当前包含一个完整的继承层次结构。最近，我重新观看了罗伯特·C·马丁(RobertC.Martin)的“清洁编码器”( EP16 )，他指出，这是包装设计中最常见的错误之一。这让我意识到，对于这里描述的软件包来说，这是一件非常精确的事情。

接下来的问题是如何更好地改进当前的组件设计。幸运的是，这些组件还没有看到它们的第一个版本，所以仍然可以移动，边界仍然可以重新定义。不过，这些版本即将发布，所以我最好现在就开始发布。

我现在想做的是创建一个新的组件来保存所有这些组件的抽象类和接口。它还将包含这些组件的异常以及接口的一些微不足道的实现。

然后，所有当前组件和所有需要当前组件的组件都需要这个新组件。然后，在后面的这个类别中，将有一些组件可以依赖于新的组件，并摆脱它们当前对包含所有接口实现的更加具体和不稳定的组件的依赖。

这对于稳定依赖原则是很好的，对于重用发布等价原则也同样好。然而，在通用闭包和通用重用原则方面，它做得相当糟糕。具体来说，这意味着需要ValueParsers接口但不关心ValueValidators接口的组件仍然依赖于它，就像在同一个包中一样。因此，他们可以毫无理由地受到这种情况的影响。再一次，考虑到这个新组件的抽象/稳定程度，我并不认为这会带来太多问题。

我正在寻找关于如何更好地绘制组件边界的想法，以及关于我所描述的备选方案的关注点或建议。

Answer 1

在与同事讨论了这一点，并从罗伯特·C·马林本人那里得到了一系列建议后，我决定采取以下令人满意的方法：

一个组件保存DataValues、ValueParssers、ValueValidators和ValueFormatters的接口。该组件还保存这些接口的异常和实现，这些异常和实现既琐碎又通用。

第二个组件保存这些接口的通用但更复杂的实现。

这样的分裂已经解决了我们目前存在的大部分问题。第一个组件非常抽象和稳定，并且是许多其他组件所需要的。第二个组件是具体的和不稳定的，只需要几个组件。

第二个组件的进一步拆分可能会在稍后发生。并不是所有从这些接口派生出来的新的具体类最终都是它，有些可能会进入新的或其他现有的组件。