使用 getter 和 setter（仅获取和设置）而不是简单地为这些变量使用公共字段有什么优势？

如果 getter 和 setter 所做的不仅仅是简单的获取/设置，我可以很快弄清楚这一点，但我不是 100% 清楚如何：

public String foo;

比以下更糟糕：

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

而前者需要的样板代码要少得多。

网友回答：

因为从现在起 2 周（月、年）后，当您意识到您的 setter 需要做的不仅仅是设置值时，您还会意识到该属性已直接用于其他 238 个类 🙂

网友回答：

公共字段并不比 getter/setter 对差，后者除了返回字段并分配给它之外什么都不做。首先，很明显（在大多数语言中）没有功能差异。任何差异都必须在其他因素上，例如可维护性或可读性。

一个经常提到的吸气手/二传手对的优势，不是。有一种说法是，您可以更改实现，并且您的客户端不必重新编译。据说，资源库允许您稍后添加验证等功能，而您的客户甚至不需要知道它。然而，为二传手添加验证是对其先决条件的改变，违反了之前的合同，很简单，“你可以在这里放任何东西，以后你可以从getter那里得到同样的东西”。

因此，既然您违反了合同，那么更改代码库中的每个文件是您应该想要做的事情，而不是避免。如果你避免它，你就是在假设所有代码都假定这些方法的协定是不同的。

如果这不应该是协定，那么接口允许客户端将对象置于无效状态。这与封装完全相反如果该字段从一开始就不能真正设置为任何内容，为什么从一开始就不进行验证？

同样的论点也适用于这些直通 getter/setter 对的其他假定优势：如果你后来决定更改正在设置的值，你就违反了合同。如果重写派生类中的默认功能，除了一些无害的修改（如日志记录或其他不可观察的行为）之外，您就会破坏基类的协定。这违反了Liskov可替代性原则，该原则被视为OO的原则之一。

如果一个类在每个领域都有这些愚蠢的getter和setter，那么它是一个没有任何不变量，没有契约的类。这真的是面向对象的设计吗？如果类只有那些getter和setter，那么它只是一个愚蠢的数据持有者，而愚蠢的数据持有者应该看起来像愚蠢的数据持有者：

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

将直通吸气器/二传手对添加到此类不会增加任何价值。其他类应提供有意义的操作，而不仅仅是字段已提供的操作。这就是定义和维护有用的不变量的方法。

客户：“我可以用这个类的对象做什么？
设计师：“你可以读取和写入几个变量。
客户：“哦…很酷，我猜？

使用 getter 和 setter 是有原因的，但如果这些原因不存在，那么以虚假封装神的名义制作 getter/setter 对并不是一件好事。制作 getter 或 setter 的正当理由包括经常提到的您以后可以进行的潜在更改，例如验证或不同的内部表示。或者，也许该值应该可由客户端读取但不可写（例如，读取字典的大小），因此简单的 getter 是一个不错的选择。但是当你做出选择时，这些原因应该存在，而不仅仅是你以后可能想要的潜在东西。这是YAGNI（你不需要它）的一个实例。

网友回答：

实际上有很多很好的理由考虑使用访问器而不是直接公开类的字段 – 不仅仅是封装的参数和使未来的更改更容易。

以下是我知道的一些原因：

• 封装与获取或设置属性相关的行为 – 这允许以后更轻松地添加其他功能（如验证）。
• 隐藏属性的内部表示形式，同时使用替代表示形式公开属性。
• 使您的公共接口与更改隔离 – 允许公共接口在实现更改时保持不变，而不会影响现有使用者。
• 控制属性的生存期和内存管理（处置）语义 – 在非托管内存环境（如 C++ 或 Objective-C）中尤其重要。
• 为属性在运行时更改时提供调试拦截点 – 在某些语言中，调试属性更改为特定值的时间和位置可能非常困难。
• 改进了与旨在针对属性获取者/资源库进行操作的库的互操作性 – 模拟、序列化和 WPF 浮现在脑海中。
• 允许继承者通过重写 getter/setter 方法来更改属性的行为和公开方式的语义。
• 允许 getter/setter 作为 lambda 表达式而不是值传递。
• getter 和 setter 可以允许不同的访问级别 – 例如，get可能是公开的，但集合可以受到保护。