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

Question

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

情况：

一个实体和关系都已经共享（i节点）和独特的方法（IEntity或IRelation）

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

题：

在尝试使用 SOLID & DRY 原则进行编程时，以下架构是好还是坏？

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

情况一：

情况二：

Answer 1

您的图表很好地说明了关注点分离（概念）和接口分离（类设计）之间的细微差别。

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

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

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