两次实现一个接口是不好的做法吗？答案

【问题标题】：Is it bad practice to implement an interface twice?两次实现一个接口是不好的做法吗？
【发布时间】：2020-02-13 16:42:10
【问题描述】：

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

情况：

Entity 和 Relation 都具有共享（INode）和唯一方法（IEntity 或 IRelation）

类需要知道使用接口 IEntity 或 IRelation 的共享方法和唯一方法。

问题：

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

补充信息：这个问题的主要原因是因为在第一个图中（当前已实现），Entity 和 Relation 都实现了两次 INode 接口。

情况1：

情况2：

【问题讨论】：

【解决方案1】：

您的图表很好地说明了separation of concerns（概念）和interface segregation（类设计）之间的细微差别。

在您的情况下，不是两个，而是四个选项：

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

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

【讨论】：