在实例化抽象类中导航，我的 OOP 设计是否存在缺陷？答案

【问题标题】：Navigating around instantiating an abstract class, is there a flaw of in my OOP design?在实例化抽象类中导航，我的 OOP 设计是否存在缺陷？
【发布时间】：2012-08-07 14:28:10
【问题描述】：

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

我正在研究一些用于处理特定类型对象的讨厌层次结构的实用程序类。虽然对象的精确细节无关紧要，但只要说它不是一个通用的解决方案就足够了。所以我首先编写了一个CustomNode 和一个CustomHierarchy 类。

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

到目前为止我有：

一个接口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> 并将其放置在层次结构中.这显然失败了，因为节点类是抽象的并且不能被实例化。

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

提前致谢，

【问题讨论】：

标签： java oop generics interface abstract-class

【解决方案1】：

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

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

【讨论】：

到目前为止，我一直在考虑将 addNodeToHierarchy() 作为 Hierarchy 类中的私有方法，在我看来，Node 类是数据 E 绑定到的地方似乎很自然Node<E> 的一个实例。至于 NodeFactory 的想法，我不确定我是否看到它有什么帮助，它本质上是将问题从一个类转移到另一个类，对吧？
正如我所说，您需要决定谁知道如何创建节点。我们无法为您做出决定，因为我们没有问题的全貌。如果 Node 类知道如何从数据中构建 Node 实例，那么可以，让它成为 Node 的静态方法。这是一种经典的工厂方法模式。