architecture - 两次实现一个接口(interface)是不好的做法吗？

Question

我对这个建筑难题一无所知，我很想听到一些关于它的批评或建议。

情况:

实体和关系都具有共享(INode)和唯一方法(IEntity 或 IRelation)

类需要了解使用接口(interface) IEntity 或 IRelation 的共享方法和唯一方法。

问题:

尝试使用 S.O.L.I.D 和 DRY 原则进行编程时，以下架构是好还是坏实践？

附加信息:这个问题的主要原因是因为在第一个图中(当前实现的)Entity 和 Relation 都实现了 INode 接口(interface)两次。

情况一:

情况2:

Answer 1

你的图表很好地说明了 separation of concerns 之间的细微差别(概念)和 interface segregation (类(class)设计)。

就您而言，没有两个，而是四个选项:

1. 您的第一个图表表明 IEntity 和 IRelation 是 INode 的特化。 IEntity 始终是 INode。您可以编写将实体和关系作为节点进行处理的代码，但可重用性会降低:IEntity 与 INode 耦合，即使它是两个不同的、不相关的概念。
2. 您的第二张图表明，通过接口(interface)查看时，IEntity 和 IRelation 是不同的、不相关的事物。现在两者都解耦并且可以独立使用，但是您没有意识到它们有一些共同点，因此不得不单独处理它们。
3. 另一种变体是解决方案 1，但接口(interface)之间没有继承。在这种方法中，您拥有独立的接口(interface):IEntity 将实现通用接口(interface)和特定接口(interface)。优点:您可以像 2 中那样进行接口(interface)隔离，但可以更好地分离关注点。不便之处在于 IEntity 可能不再是独立的。
4. 另一种变体(我最喜欢的)是将 INode 拆分为两个独立的接口(interface):通用 INamedObject 和特定的图形接口(interface) INode >。然后，IEntity 和 IRelation 将从 INamedObject 继承，而不是从 INode 继承。优点是您可以真正实现关注点分离:事物不是出于技术原因人为地分离，而是根据它们所代表的概念来分离。

最后，即使我个人建议选择 4，您也必须为自己的设计找到适当的平衡点。因为只有您才能知道您打算如何使用您的接口(interface)和类以及您真正想要表示的概念。