在阅读了一些关于抽象类和接口的问题之后，我仍然不确定我应该如何设计我的代码，所以冒着错过可能重复的风险，这就是我的情况。
我正在研究一些旨在处理特定类型对象的讨厌层次结构的实用程序类。虽然对象的精确细节无关紧要，但只要说它不是一个通用的解决方案就足够了。所以我从写一个CustomNode和一个CustomHierarchy类开始。
过了一会儿，我意识到生成一个更通用的解决方案要聪明得多，它可以在不同的上下文中重复使用，并且可以轻松测试，而无需创建大量上述复杂类的模拟实例。我可以轻松地提供接口和抽象类中的所有通用代码，并在需要它们的地方提供特定的位！（我相信这就是 OOP 的重点吗？）
到目前为止，我有：
一个接口
Relatable，它简单地保存节点之间可能具有的可能关系的枚举，以及一个方法签名getRelation(Relatable other)Node<E>一个实现Relatable并包含所有实用方法的抽象类（例如addChild()或getNextSibling()。这个类唯一缺少的方法是getRelation(Relatable other).一个具体的类
Hierarchy<E>，它将定义如何建立节点的层次结构，从Collection<E>保存数据的 a 开始。
这个想法是根据手头的问题用适当的子类扩展Node<E>和类。Hierarchy<E>前两个完成时没有任何大的麻烦，但我遇到了这个Hierarchy<E>类的问题，因为它有一个私有方法addNodeToHierarchy(E data)，它试图实例化 aNode<E>并将其放置在层次结构中。这显然失败了，因为节点类是抽象的并且不能被实例化。
我理解为什么这不起作用，但我不确定我应该如何规避这个问题。我的设计有缺陷吗？我应该在中添加一个静态createNewNode(E data)方法Node<E>并使用它吗？我能想到的另一个选择是Node从获取关系中分离出来，Relator而是使用接口。这绝不可能是一个独特的问题，那么在这种情况下什么是“好的做法”？
提前致谢，