java - 在实例化抽象类时，我的 OOP 设计是否存在缺陷？

Question

在阅读了一些有关抽象类和接口(interface)的问题后，我仍然不确定应该如何设计我的代码，因此冒着错过可能重复的风险，这是我的情况。

我正在开发许多实用程序类，这些类旨在处理特定类型对象的令人讨厌的层次结构。虽然对象的精确细节无关紧要，但足以说明它不是一个通用的解决方案。所以我首先写了一个CustomNode和一个 CustomHierarchy类(class)。

稍后我意识到，生成更通用的解决方案要聪明得多，它可以在不同的上下文中重用，并且可以轻松测试，而无需创建上述复杂类的大量模拟实例。我可以轻松地提供接口(interface)和抽象类中的所有通用代码，并且只提供需要的特定位! (我相信这就是 OOP 的全部意义？)

到目前为止我已经:

• 接口(interface) Relatable它只是保存节点之间可能存在的可能关系的枚举，以及 getRelation(Relatable other) 的方法签名

• 抽象类 Node<E>它实现了 Relatable并包含所有实用方法(例如 addChild() 或 getNextSibling() 。此类缺少的唯一方法是 getRelation(Relatable other) 。

• 具体类 Hierarchy<E>它将定义如何构建节点的层次结构，从Collection<E>开始。它保存数据。

这个想法是扩展Node<E>和Hierarchy<E>根据手头的问题创建具有适当子类的类。前两个是在没有任何重大喧嚣的情况下完成的，但我在Hierarchy<E>方面遇到了问题。类，因为它有一个私有(private)方法 addNodeToHierarchy(E data)它尝试实例化 Node<E>并将其放置在层次结构中。这显然会失败，因为节点类是抽象的并且无法实例化。

我明白为什么这不起作用，但我不确定应该如何规避这个问题。我的设计有缺陷吗？我应该添加静态 createNewNode(E data) Node<E>中的方法并用它代替？我能想到的另一个选择是分离 Node从获取关系并选择 Relator接口(interface)代替。这绝不是一个独特的问题，那么在这种情况下“好的做法”是什么？

提前致谢，

Answer 1

决定谁应该知道如何 Node<E>必须从 E 的实例构造。它可能是 E 的实例，可能是Node类，它可能是层次结构，也可能是 addNodeToHierarchy() 的调用者。

如果是addNodeToHierarchy()的来电者，那么要么让它采用 Node<E> 的实例而不是 E 的实例，或者你让它采用一些 NodeFactory<E> 的实例，该方法将委托(delegate)将数据转换为节点。如果所有节点都是由同一个工厂构造的，则该工厂也可以作为参数传递给层次结构构造函数。