这个设计在多大程度上违反了封装

Question

我正在用 Java 设计一个图形对象。我是设计师，我怀疑这种设计违反了封装，但我想从其他人那里得到一些见解。

在下面，我们有两个接口 Graph 和 Vertex。

图实现负责管理图中的顶点，包括创建、删除、确保施加约束等。通用参数代表T类型，即存储在一个顶点，W8 是存储在边中的权重类型：

public interface Graph<T, W>
{
    /** Creates and adds a vertex with the value given to this graph */
    Vertex<T> createVertex(T value);

    /** Performs some arbitrary modification to the vertex given */
    void modify(Vertex<T> vertex, ....);

    // some other methods...
}

Vertex 接口用于获取和修改顶点的属性以及保持引用；它的实现由图的实现决定——客户端对其内部实现一无所知。它可能看起来像这样：

public interface Vertex<T>
{
     int getValue();

     /** Performs some arbitrary modification to this vertex - same as
       * as in modify method in graph */
     void modify(...);

     // some other methods
}

我使用顶点接口的原因是客户端可以简单地保留对相关顶点的引用并将引用传递给图形。我也可以有这样的图形界面：

public interface Graph<T, W>
{
    /** Creates and adds a vertex with the value given to this graph */
    void createVertex(T value);

    /** Performs some arbitrary modification to the vertex given */
    void modify(T vertex);

    // some other methods...
}

在这个图形界面中，“修改”方法总是需要搜索顶点；这将是非常不切实际的，尤其是当我们想经常修改同一个顶点时——相反，客户端可以像第一种方法一样保留一个参考通道。

回到我的问题，我对封装非常严格，这是否违反了封装的原则？

我个人认为这不会违反封装，因为客户端不知道图形对象或顶点在内部执行了什么。然而，我们确实泄漏了图以某种方式使用顶点的信息（尽管 exact 内部结构没有暴露），其他库没有这样做。示例可能是作为 Graph 子集的数据结构，例如 Trees 和 LinkedLists：核心 Java 库中的 LinkedList 实现不会让应用程序注意到使用了某些 Node 接口；我在其他各种库中看到的树实现也不公开它们的节点。

那么在严格的面向对象术语下，这种设计是否违反封装？我也欢迎对现有的面向对象库（也在 Java 范围之外）或讨论该主题的文章的其他参考。

Answer 1

我认为这类似于 Map 接口暴露 Map.Entry。图的概念预设了顶点的概念——你不能没有另一个。因此，公开两者是完全合法的。

另一方面，您在这里公开（或可能限制）至少一些实现细节。你的

void modify(T vertex);

在Graph 中假设 vetex 可以通过它们的内容来寻址。情况可能并非总是如此。我觉得这对T的限制太大了。

我想说，为了确保封装，对图本身的唯一询问操作应该是Set<Vertex<T>> getVertices。其余的应该在顶点上。

创建操作应该返回它创建的实体：

Vertex<T> createVertex(T value)

然后您可以添加Graph.createEdge(Vertex<T> v1, Vertex<T> v2) 和removeEdge(Vertex<T> v1, Vertex<T> v2)。

Answer 2

我认为它不违反封装。图的目的通常是管理顶点和边，因此将这些概念作为类型公开和使用是非常有意义的。在您的问题中，您引用了LinkedList，但其主要目的是成为List，而不是暴露节点的数据结构。如果愿意，它可以完全安全地公开其节点，尽管大多数客户端应该只使用它的List API。

破坏封装是您以不安全的方式暴露内部的那一行，例如返回一个可变集合（例如List<Vertex<T>>），它是一种内部数据结构，而不是通过更受控制的 API 来保护它（例如add(Vertex<T>) ， ETC。）。如果你失去了对内脏的控制，全世界都可以玩弄你的私处，而你无能为力。

例如，一些Map 接口公开了一个表示键或值的集合，并将这些实现绑定到映射本身支持的突变。这是安全且方便的曝光。

考虑不公开诸如内部数据结构、布尔或按位标志（可能使用 API 中的枚举或接口以及内部需要的更高效的东西）或具有棘手操作顺序的突变器，例如“第一次调用 init ，然后拨打setup，然后拨打x或y或z，然后确保拨打dispose”。您希望通过便利的结构和常见的设计模式将这种东西融入您的 API。