是否应该始终完全封装内部数据结构？

请考虑此类：

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThings(){
        return things;
    }

}

此类将用于存储数据的数组公开给任何感兴趣的客户端代码。

我是在正在开发的应用中完成此操作的。我有一个ChordProgression存储序列Chords的类（并执行其他一些操作）。它有一个Chord[] getChords()返回和弦数组的方法。当必须更改数据结构（从数组更改为ArrayList）时，所有客户端代码都将中断。

这让我思考-也许以下方法更好：

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThing(int index){
        return things[index];
    }

    public int getDataSize(){
        return things.length;
    }

    public void setThing(int index, Thing thing){
        things[index] = thing;
    }

}

现在，不再公开数据结构本身，而是使用委托给数据结构的公共方法，由数据结构提供的所有操作直接由包含它的类提供。

当数据结构更改时，仅这些方法就必须更改-但更改后，所有客户端代码仍然有效。

请注意，比数组更复杂的集合可能需要封闭的类来实现甚至三个以上的方法来访问内部数据结构。

这种方法常见吗？你觉得这怎么样？它还有什么缺点？让封闭的类至少实现三个公共方法以委托给内部数据结构是否合理？

像这样的代码：

   public Thing[] getThings(){
        return things;
    }

没什么意义，因为您的访问方法除了直接返回内部数据结构外什么也不做。您不妨声明Thing[] things为public。访问方法背后的想法是创建一个接口，以使客户端与内部更改隔离，并使客户端无法操作实际的数据结构，除非采用接口允许的谨慎方式。如您所见，当所有客户端代码都损坏时，您的访问方法并没有做到这一点-只是浪费了代码。我认为许多程序员倾向于这样编写代码，因为他们了解到某个地方所有内容都必须使用访问方法进行封装-但这就是我解释的原因。当访问方法没有任何作用时，只是为了“遵循表单”而已。

我绝对会推荐您提出的解决方案，该解决方案可以实现封装的一些最重要的目标：为客户提供健壮，谨慎的接口，以使它们与类的内部实现细节隔离开来，并且不允许他们接触内部数据结构以您认为合适的方式期望-“最低必要特权法”。如果您看看流行的大型OOP框架（例如CLR，STL，VCL），正是由于这个原因，您提出的模式已经很广泛了。

你应该一直这样做吗？不必要。例如，如果您有帮助者或朋友类，它们实际上是您的主要工作者类的组成部分，并且不是“正面”的，则没有必要-这是一个过大的选择，它将添加许多不必要的代码。在那种情况下，我根本不会使用访问方法-如所解释的那样，这是毫无意义的。只需以仅适用于使用它的主类的方式声明数据结构-大多数语言都支持这样做的方法- friend或在与主worker类相同的文件中声明它，等等。

我可以在您的建议中看到的唯一缺点是，编码需要更多的工作（现在您将不得不重新编码消费者类-但您仍然必须这样做。）但这并不是真正的缺点。 -您需要做正确的事，有时这需要更多的工作。

使一个好的程序员变得更好的一件事是，他们知道什么时候额外的工作值得，什么时候不值得。从长远来看，现在投入额外的资金将在将来获得丰厚的回报-如果不在该项目上，那么在其他项目上。学习以正确的方式编码并运用您的头脑，而不仅仅是机械地遵循规定的形式。

请注意，比数组更复杂的集合可能需要封闭的类来实现甚至三个以上的方法来访问内部数据结构。

如果要通过包含类（IMO）公开整个数据结构，则需要考虑一下为什么要封装该类，如果不是简单地提供一个更安全的接口-“包装器类”。您说的是为此目的而存在的包含类-因此，您的设计可能不正确。考虑将您的班级细分为更谨慎的模块并进行分层。

一门课程应该有一个明确而谨慎的目的，并提供一个接口来支持该功能，而不再是。您可能正在尝试将不属于一起的东西捆绑在一起。当您这样做时，每次必须实施更改时，事情都会崩溃。您的课程越小越谨慎，就可以更轻松地改变周围的事物：思考乐高。

您问：我是否应该始终完全封装内部数据结构？

简要答案：是的，大多数时候但并非总是如此。

长答案：我认为课程分为以下几类：

1. 封装简单数据的类。示例：2D点。创建提供获取/设置X和Y坐标功能的公共函数很容易，但是您可以轻松隐藏内部数据而不会带来太多麻烦。对于此类，不需要公开内部数据结构的详细信息。

2. 封装集合的容器类。STL具有经典的容器类。我认为std::string和std::wstring那些中了。它们提供了丰富的接口，以应对抽象，但是std::vector，std::string和std::wstring还提供了可以访问原始数据的能力。我不会急于将它们称为设计不良的类。我不知道这些类公开其原始数据的理由。但是，在我的工作中，由于性能原因，我发现有必要在处理数百万个网格节点和这些网格节点上的数据时公开原始数据。

   公开类的内部结构的重要之处在于，在发出绿色信号之前，您必须认真思考。如果该接口在项目内部，则将来更改它会很昂贵，但并非不可能。如果接口在项目外部（例如，当您正在开发将由其他应用程序开发人员使用的库时），则在不丢失客户的情况下更改接口可能是不可能的。

3. 本质上大多数是功能类。示例：std::istream，，std::ostreamSTL容器的迭代器。公开这些类的内部细节是完全愚蠢的。

4. 混合类。这些是封装某些数据结构但也提供算法功能的类。就我个人而言，我认为这是设计不当的结果。但是，如果找到它们，则必须决定根据情况公开其内部数据是否有意义。

结论：我发现唯一需要公开一个类的内部数据结构的时间是当它成为性能瓶颈时。

尝试直接执行以下操作，而不是直接返回原始数据

class ClassA {
  private Things[] things;
  ...
  public Things[] asArray() { return things; }
  public List<Thing> asList() { ... }
  ...
}

因此，您实质上是在提供一个定制集合，该集合可以呈现所需的任何面孔。在您的新实现中，

class ClassA {
  private List<Thing> things;
  ...
  public Things[] asArray() { return things.asArray(); }
  public List<Thing> asList() { return things; }
  ...
}

现在，您具有正确的封装，隐藏实现细节，并提供向后兼容性（需要付费）。

您应该为这些事情使用接口。由于Java的数组未实现这些接口，因此对您的情况无济于事，但是从现在开始您应该这样做：

class ClassA{

    public ClassA(){
        things = new ArrayList<Thing>();
    }

    private List<Thing> things; // stores data

    // stuff omitted

    public List<Thing> getThings(){
        return things;
    }

}

这样，您可以更改ArrayList为LinkedList或其他任何内容，并且不会破坏任何代码，因为所有具有（pseudo？）随机访问权限的Java集合（数组之外）都将实现List。

您还可以使用Collection，它提供的方法要少于List但可以支持没有随机访问的集合，或者Iterable甚至可以支持流，但是在访问方法方面却不提供太多...

隐藏内部数据结构与外界隔绝是很常见的。有时，这在DTO中是过大的。我建议将此用于域模型。如果完全需要公开，则返回不可变的副本。与此同时，我建议创建一个具有get，set，remove等方法的接口。