定义访问修饰符的意义是什么？

Question

我了解它们之间的差异（至少在 C# 中）。我知道它们对分配给它们的元素的影响。我不明白的是为什么实施它们很重要 - 为什么不将所有内容公开？

我读到的关于这个主题的材料通常是关于类和方法如何不应该对其他人进行不必要的访问，但我还没有遇到一个例子来说明为什么/如何这是一件坏事。这看起来像是一个安全问题，但我是程序员；我创建方法并定义它们将（或不会）做什么。为什么我要花费所有的精力来编写一个函数来尝试更改不应该更改的变量，或者尝试读取另一个类中的信息，如果那样会很糟糕？

如果这是一个愚蠢的问题，我深表歉意。这只是我在阅读有关 OOP 的第一篇文章时遇到的东西，但我从来没有觉得它真正引起了我的注意。

Answer 1

仅当您是唯一的程序员时，我是程序员才是正确的假设。

在许多情况下，其他程序员会使用第一个程序员的代码。他们以他不希望的方式使用它，通过摆弄他们不应该的字段的值，他们创建了一个可行的黑客，但当原始代码的生产者更改它时就会中断。

OOP 是关于创建具有明确定义的契约的库。如果所有变量都是公共的并且可供其他人访问，那么“契约”理论上包括对象（及其子对象）中的每个字段，因此构建仍然遵循原始契约的新的、不同的实现变得更加困难。

此外，对象暴露的“移动部分”越多，类的用户就越容易错误地操作它。

---

您可能不需要这个，但这里有一个我认为很有趣的例子：

假设您出售一辆发动机舱上没有引擎盖的汽车。到了晚上，司机打开车灯。他到达目的地，下了车，然后想起他把灯开着。他懒得打开车门，所以他把车灯的电线从与电池相连的地方拉出来。这很好用——灯灭了。然而，由于他没有使用预期的机制，下次在黑暗中开车时他发现自己遇到了问题。

生活在美国（来吧，给我投反对票！），他拒绝为他对汽车内部结构的错误使用承担责任，并起诉你，制造商，因为你创造了一种在黑暗中驾驶不安全的产品，因为灯不能关断后能可靠地开启。

这就是为什么所有汽车的发动机舱上都有引擎盖 :)

---

一个更严重的例子：您创建一个 Fraction 类，其中包含分子和分母字段以及一系列操作分数的方法。您的构造函数不允许其调用者创建分母为 0 的分数，但由于您的字段是公共的，因此用户很容易将现有（有效）分数的分母设置为 0，并且随之而来的是欢闹。

Answer 2

首先，语言中没有任何内容强制您使用访问修饰符 - 如果您愿意，您可以自由地将所有内容公开在您的类中。然而，使用它们有一些令人信服的理由。这是我的观点。

1. 隐藏类的内部运作方式可以让您保护该类免遭意外使用。虽然您可能是该类的创建者，但在许多情况下您不会是唯一的消费者 - 或者甚至维护者。隐藏内部状态可以为那些可能不像您一样理解其工作原理的人保护该类。当类没有按照您希望的方式运行时，将所有内容公开会产生“调整”内部状态或内部行为的诱惑，而不是实际纠正内部实现的公共接口。这是通往毁灭之路。

2. 隐藏内部结构有助于整理命名空间，并允许 Intellisense 等工具仅显示相关且有意义的方法/属性/字段。不要低估像 Intellisense 这样的工具 - 它们是开发人员快速识别他们可以对您的类执行哪些操作的强大手段。

3. 隐藏内部结构允许您构建适合该类正在解决的问题的接口。暴露所有内部结构（通常远远超过暴露的接口）使得以后很难理解该类试图解决什么问题。

4. 隐藏内部结构使您可以将测试集中在适当的部分 - 公共接口。当类的所有方法/属性都是公共的时，您必须潜在测试的排列数量显着增加 - 因为任何特定的调用路径都成为可能。

5. 隐藏内部结构可帮助您控制（强制）类中的调用路径。这可以更轻松地确保您的消费者了解可以要求您的类执行什么操作以及何时执行。通常，代码中只有少数路径是有意义且有用的。允许消费者采取任何路径会使他们更有可能得不到有意义的结果 - 并将其解释为您的代码有错误。限制消费者使用您的类的方式实际上可以让他们正确使用它。

6. 隐藏内部实现可以让您自由地更改它，并且知道它不会对您的类的使用者产生不利影响 - 只要您的公共接口保持不变。如果您决定在内部使用字典而不是列表 - 没有人会关心。但是，如果您使类的所有内部结构都可用，那么有人可以编写取决于您内部使用列表这一事实的代码。想象一下，当您想要更改有关实现的此类选择时，必须更改所有消费者。黄金法则是：类的使用者不应该关心该类如何执行其功能。

Answer 3

它主要是一种隐藏和共享的东西。您可以生成并使用自己的所有代码，但其他人提供库等以更广泛地使用。

将事物设为非公开允许您显式定义类的外部接口。非公共内容不是外部接口的一部分，这意味着您可以在内部更改任何您想要的内容，而不会影响任何使用外部接口的人，

Answer 4

您只想公开 API 并隐藏其他所有内容。为什么？
好吧，假设您想要创建一个很棒的 Matrix 库，因此您

class Matrix {
   public Object[][] data //data your matrix storages
   ...
   public Object[] getRow()
}

默认使用您的库的任何其他程序员都希望通过利用底层结构来最大化其程序的速度。

//Someone else's function
Object one() {data[0][0]}

现在，您发现使用列表来模拟矩阵会提高性能，因此您更改数据不会

Object[][] data => Object[] data

导致 Object one() 中断。换句话说，通过更改实现，您破坏了向后兼容性:-(

通过封装，您将内部实现与外部接口分开（通过 private 修饰符实现）。
这样你就可以在不破坏向后兼容性的情况下尽可能地改变实现：D利润！！！

当然，如果您是唯一要修改或使用该类的程序员，您最好将其公开。

注意：封装你的东西还有其他主要好处，这只是其中之一。有关更多详细信息，请参阅封装

Answer 5

我认为最好的原因是在代码上提供抽象层。

随着应用程序的增长，您将需要让您的对象与其他对象进行交互。拥有可公开修改的字段会让您更难理解整个应用程序。

限制在类上公开的内容可以更轻松地抽象设计，以便您可以理解代码的每一层。

Answer 6

对于某些类，拥有私有成员以及一堆仅设置和获取这些值的方法似乎很荒谬。其原因是，假设您有一个类，其中的成员是公共的并且可以直接访问：

class A 
{
    public int i;

   ....
}

现在您继续在编写的一堆代码中使用它。现在，在编写了一堆直接访问 i 的代码之后，您意识到 i 应该对其有一些限制，例如 i 应该始终 >= 0 且小于 100（为了论证）。
现在，您可以检查使用 i 的所有代码并检查此约束，但您可以只添加一个公共 setI 方法来为您完成此操作：

class A
{
    private int i;
    public int I 
    {
        get {return i;}
        set 
        {
            if (value >= 0 && value < 100)
                i = value;
            else
                throw some exception...
         }
    }
}

这隐藏了所有错误检查。虽然这个例子很老套，但类似的情况经常出现。

Answer 7

它与安全完全无关。

访问修饰符和范围都与结构、层、组织和通信有关。

如果你是唯一的程序员，那么可能没什么问题，除非你有这么多代码，甚至你都记不清了。那时，它就像一个团队环境 - 访问修饰符和代码结构引导您留在架构内。