这是坏耦合吗？

Question

我正在尝试解决 3D 空间中的路径规划问题并且已经成功，但我不知道我的解决方案是否具有足够的松散耦合。我有三个源文件，每个都包含一个公共类：Vertex.java、VertexHeuristicComparator.java 和 PathPlanningUtil.java。

Vertex 包含三个字段：3D 空间中的 Point (location)、对另一个顶点的引用 (parent) 和保存到目标顶点距离的 float (distToGoal)。在路径规划中使用顶点集合来探索环境并找到最佳路径。

VertexHeuristicComparator 实现Comparator<Vertex>。我已经覆盖了 compareTo 方法以在比较中使用 distToGoal 和 parent。该方法有效地定义了最佳顶点是什么，以便路径规划可以优先搜索。

PathPlanningUtil 包含方法planPath(Point start, Point goal)。此方法返回一个ArrayList<Vertex>，表示 3D 空间中从起点到目标的路径。此方法使用VertexHeuristicComparator 来确定如何通过探索 VertexHeuristicComparator 确定为“最低”顶点的顶点来探索环境。

因为VertexHeuristicComparator 是路径规划逻辑的核心。更改 VertexHeuristicComparator 源代码将导致 planPath 返回不同的路径。更改 VertexHeuristicComparator 以彻底改变 planPath 的输出是不是耦合不好？

Answer 1

要回答您的直接问题，

对 VertexHeuristicComparator 的更改是否耦合不好 彻底改变 planPath 的输出？

没有。如果对VertexHeuristicComparator 的更改导致PathPlanningUtil 的更改代码，这只会是糟糕的（紧密）耦合。只要您可以更改一个类的代码而不必更改另一个类的代码，您就实现了合理的松散耦合。

Answer 2

我对耦合的一般理解是，它更多的是不依赖于特定的实现而不是通用接口——例如，显式返回或需要一个 ArrayList 而不是 List，或者将特定事物的使用硬编码到很远在逻辑链中。

对于您的特定示例，我可能会建议您让路径规划接受作为启发式使用的参数（作为比较器）。这将防止您的路径规划的实现具体依赖于您为比较器编写的类，并允许客户端（在本例中为您的主程序）提供它想要用作启发式的比较策略。

所以，在代码示例中总结一下，我会让路径规划方法具有类似于以下内容的签名：

List<Vertex> planPath(Point start, Point goal, Comparator<Vertex> heuristic)

并让调用计划路径的方法成为引用您的 VertexHeuristicComparator 类的方法，将其用作启发式参数。