使用 getter 和 setter 有什么好处 - 只获取和设置 - 而不是简单地为这些变量使用公共字段？
如果 getter 和 setter 所做的不仅仅是简单的 get/set，我可以很快解决这个问题，但我不是 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/setter 对的一个经常提到的优点不是。有人声称您可以更改实现并且您的客户端不必重新编译。据说，setter 允许您稍后添加验证等功能，而您的客户甚至不需要知道它。但是，向 setter 添加验证是对其前提条件的更改，违反了之前的合同，很简单，“你可以在这里放任何东西，以后你可以从 getter 中得到同样的东西”。
因此，既然您违反了合同，那么更改代码库中的每个文件是您应该做的事情，而不是避免。如果你避免它，你就是在假设所有代码都假设这些方法的合同是不同的。
如果这不应该是合同，那么接口允许客户端将对象置于无效状态。这与封装完全相反如果该字段从一开始就不能真正设置为任何内容，为什么从一开始就没有验证呢？
同样的论点也适用于这些 pass-through getter/setter 对的其他假定优势：如果您后来决定更改正在设置的值，那么您就违反了合同。如果您以超出一些无害修改（如日志记录或其他不可观察的行为）的方式覆盖派生类中的默认功能，则您违反了基类的约定。这违反了 Liskov 可替代性原则，该原则被视为 OO 的原则之一。
如果一个类的每个字段都有这些愚蠢的 getter 和 setter，那么它就是一个没有任何不变量、没有 contract的类。那真的是面向对象的设计吗？如果类只有那些 getter 和 setter，它只是一个哑数据持有者，哑数据持有者应该看起来像哑数据持有者：
class Foo {
public:
int DaysLeft;
int ContestantNumber;
};
将传递的 getter/setter 对添加到这样的类不会增加任何价值。其他类应该提供有意义的操作，而不仅仅是字段已经提供的操作。这就是您可以定义和维护有用的不变量的方式。
客户：“我可以用这个类的对象做什么？”
设计师：“你可以读写几个变量。”
客户：“哦……很酷，我猜？”
使用 getter 和 setter 是有原因的，但如果这些原因不存在，那么以假封装之神的名义制作 getter/setter 对并不是一件好事。制作 getter 或 setter 的正当理由包括经常提到的作为您以后可以进行的潜在更改的事情，例如验证或不同的内部表示。或者该值应该可以被客户端读取但不可写（例如，读取字典的大小），所以一个简单的 getter 是一个不错的选择。但是当你做出选择时，这些理由应该在那里，而不仅仅是你以后可能想要的东西。这是 YAGNI 的一个实例（你不需要它）。
Lots of people talk about the advantages of getters and setters but I want to play devil's advocate. Right now I'm debugging a very large program where the programmers decided to make everything getters and setters. That might seem nice, but its a reverse-engineering nightmare.
Say you're looking through hundreds of lines of code and you come across this:
person.name = "Joe";
It's a beautifully simply piece of code until you realize its a setter. Now, you follow that setter and find that it also sets person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName, and calls person.update(), which sends a query out to the database, etc. Oh, that's where your memory leak was occurring.
Understanding a local piece of code at first glance is an important property of good readability that getters and setters tend to break. That is why I try to avoid them when I can, and minimize what they do when I use them.
在纯面向对象的世界中，getter 和 setter 是一种可怕的反模式。阅读这篇文章：Getters/Setters。邪恶的。期间。简而言之，它们鼓励程序员将对象视为数据结构，而这种类型的思维是纯粹的过程性的（就像在 COBOL 或 C 中一样）。在面向对象的语言中没有数据结构，只有暴露行为的对象（不是属性/属性！）
您可以在优雅对象的第 3.5 节（我关于面向对象编程的书）中找到更多关于它们的信息。
有很多原因。我最喜欢的一个是当您需要更改行为或规范您可以在变量上设置的内容时。例如，假设您有一个 setSpeed(int speed) 方法。但是您希望您只能将最大速度设置为 100。您可以执行以下操作：
public void setSpeed(int speed) {
if ( speed > 100 ) {
this.speed = 100;
} else {
this.speed = speed;
}
}
现在，如果您在代码中的任何地方都使用公共字段，然后您意识到您需要上述要求怎么办？寻找公共字段的每一种用法，而不是仅仅修改你的 setter，玩得开心。
我的 2 美分 :)
访问器和修改器的一个优点是您可以执行验证。
例如，如果foo是公共的，我可以轻松地将其设置为null，然后其他人可以尝试调用对象上的方法。但它已经不存在了！使用一种setFoo方法，我可以确保它foo从未设置为null.
访问器和修改器还允许封装 - 如果您不应该在设置后看到该值（也许它在构造函数中设置然后由方法使用，但不应该被更改），那么任何人都不会看到它。但是，如果您可以允许其他类查看或更改它，您可以提供适当的访问器和/或修改器。
取决于你的语言。你已经标记了这个“面向对象”而不是“Java”，所以我想指出 ChssPly76 的答案是依赖于语言的。例如，在 Python 中，没有理由使用 getter 和 setter。如果您需要更改行为，您可以使用一个属性，该属性包含一个围绕基本属性访问的 getter 和 setter。像这样的东西：
class Simple(object):
def _get_value(self):
return self._value -1
def _set_value(self, new_value):
self._value = new_value + 1
def _del_value(self):
self.old_values.append(self._value)
del self._value
value = property(_get_value, _set_value, _del_value)
谢谢，这真的澄清了我的想法。现在这是（几乎）10 个（几乎）不使用 getter 和 setter 的好理由：
我要离开的最后三个（N/A 或 D/C）...
好吧，我只想补充一点，即使有时它们对于变量/对象的封装和安全性是必要的，如果我们想编写一个真正的面向对象程序，那么我们需要停止过度使用访问器，因为有时我们非常依赖当不是真正需要时，在它们上，这几乎与我们将变量公开一样。
我知道这有点晚了，但我认为有些人对表演感兴趣。
我做了一点性能测试。我写了一个类“NumberHolder”，它拥有一个整数。您可以使用 getter 方法读取该整数，也可以
anInstance.getNumber()使用anInstance.number. 我的程序通过两种方式读取了 1,000,000,000 次。该过程重复五次并打印时间。我得到以下结果：
Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms
（时间1是直接方式，时间2是getter）
你看，吸气剂（几乎）总是快一点。然后我尝试了不同数量的周期。我没有使用 100 万，而是使用了 1000 万和 10 万。结果：
1000 万次循环：
Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms
1000 万次循环，时间几乎相同。以下是 10 万（10 万）个周期：
Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms
同样具有不同数量的循环，getter 比常规方式快一点。我希望这对你有所帮助。
编辑：我回答这个问题是因为有很多学习编程的人都在问这个问题，而且大多数答案在技术上都很有能力，但如果你是新手，它们就不太容易理解。我们都是新手，所以我想我会尝试一个对新手更友好的答案。
两个主要是多态性和验证。即使它只是一个愚蠢的数据结构。
假设我们有这个简单的类：
public class Bottle {
public int amountOfWaterMl;
public int capacityMl;
}
一个非常简单的类，它包含多少液体，以及它的容量是多少（以毫升为单位）。
当我这样做时会发生什么：
Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;
好吧，你不会指望它会起作用，对吧？您希望进行某种健全性检查。更糟糕的是，如果我从未指定最大容量怎么办？哦，亲爱的，我们有问题。
但还有另一个问题。如果瓶子只是一种容器呢？如果我们有几个容器，所有容器都装有容量和数量的液体怎么办？如果我们可以创建一个接口，我们可以让程序的其余部分接受该接口，瓶子、塑料桶和各种东西都可以互换使用。那不是更好吗？由于接口需要方法，这也是一件好事。
我们最终会得到类似的东西：
public interface LiquidContainer {
public int getAmountMl();
public void setAmountMl(int amountMl);
public int getCapacityMl();
}
伟大的！现在我们只需将 Bottle 更改为：
public class Bottle extends LiquidContainer {
private int capacityMl;
private int amountFilledMl;
public Bottle(int capacityMl, int amountFilledMl) {
this.capacityMl = capacityMl;
this.amountFilledMl = amountFilledMl;
checkNotOverFlow();
}
public int getAmountMl() {
return amountFilledMl;
}
public void setAmountMl(int amountMl) {
this.amountFilled = amountMl;
checkNotOverFlow();
}
public int getCapacityMl() {
return capacityMl;
}
private void checkNotOverFlow() {
if(amountOfWaterMl > capacityMl) {
throw new BottleOverflowException();
}
}
我将把 BottleOverflowException 的定义作为练习留给读者。
现在请注意这是多么强大。我们现在可以通过接受 LiquidContainer 而不是 Bottle 来处理代码中的任何类型的容器。这些瓶子处理这类东西的方式各不相同。你可以让瓶子在它改变时将它们的状态写入磁盘，或者保存在 SQL 数据库或 GNU 知道的其他东西上的瓶子。
所有这些都可以有不同的方式来处理各种糟糕的事情。瓶子只是检查，如果它溢出它会抛出一个 RuntimeException。但这可能是错误的做法。（有一个关于错误处理的有用讨论，但我故意在这里保持非常简单。评论中的人可能会指出这种简单方法的缺陷。;)）
是的，似乎我们从一个非常简单的想法转变为快速获得更好的答案。
另请注意，您不能更改瓶子的容量。它现在一成不变。您可以通过将 int 声明为 final 来执行此操作。但如果这是一个列表，您可以清空它，向其中添加新内容，等等。你不能限制接触内脏。
还有第三件事不是每个人都解决过：getter 和 setter 使用方法调用。这意味着它们看起来像其他地方的普通方法。DTO 和其他东西没有奇怪的特定语法，而是到处都有相同的东西。
Getter 和 setter 方法是访问私有类成员的公共接口。
封装的口头禅是使字段私有而方法公开。
Getter 方法： 我们可以访问私有变量。
Setter 方法： 我们可以修改私有字段。
即使 getter 和 setter 方法没有添加新功能，我们也可以改变主意稍后再制作该方法
在任何可以使用值的地方，都可以添加返回该值的方法。代替：
int x = 1000 - 500
利用
int x = 1000 - class_name.getValue();
假设我们需要存储 this 的详细信息Person。这Person有字段name和。这样做涉及为和创建方法。现在，如果我们需要创建另一个人，则有必要重新创建, ,的方法。agesexnameagesexnameagesex
class(Person)我们可以创建一个带有 getter 和 setter 方法的 bean，而不是这样做。所以明天我们可以class(Person class)在需要添加新人的时候创建这个 Bean 的对象（见图）。因此我们重用了 bean 类的字段和方法，这要好得多。
对于 Java 案例，我花了很长时间思考这个问题，我相信真正的原因是：
换句话说，在接口中指定字段的唯一方法是提供写入新值的方法和读取当前值的方法。
这些方法是臭名昭著的 getter 和 setter....
除非您当前的交付需要，否则不要使用 getter setter 即不要过多考虑未来会发生什么，如果有任何事情要更改，它在大多数生产应用程序、系统中都是一个更改请求。
想简单，容易，需要时增加复杂性。
我不会仅仅因为我认为它是正确的或者我喜欢这种方法而利用对深厚技术知识的企业主的无知。
我编写了没有 getter setter 的大型系统，只有访问修饰符和一些方法来验证 n 执行 biz 逻辑。如果你绝对需要。使用任何东西。
它对于延迟加载很有用。假设有问题的对象存储在数据库中，除非你需要它，否则你不想去获取它。如果对象由 getter 检索，则内部对象可以为 null，直到有人请求它，然后您可以在第一次调用 getter 时获取它。
我在一个交给我的项目中有一个基页类，它从几个不同的 Web 服务调用加载一些数据，但这些 Web 服务调用中的数据并不总是在所有子页面中使用。Web 服务，为了所有的好处，开创了“慢”的新定义，所以如果你不需要，你就不想进行 Web 服务调用。
我从公共字段转移到 getter，现在 getter 检查缓存，如果不存在则调用 Web 服务。因此，只需稍加包装，就可以阻止许多 Web 服务调用。
因此，getter 使我免于尝试在每个子页面上弄清楚我需要什么。如果我需要它，我会调用 getter，如果我还没有它，它会为我找到它。
protected YourType _yourName = null;
public YourType YourName{
get
{
if (_yourName == null)
{
_yourName = new YourType();
return _yourName;
}
}
}
到目前为止，我在答案中错过了一个方面，即访问规范：
在不支持“属性”（C++、Java）或在将字段更改为属性（C#）时需要重新编译客户端的语言中，使用 get/set 方法更容易修改。例如，向 setFoo 方法添加验证逻辑不需要更改类的公共接口。
在支持“真实”属性的语言（Python、Ruby，也许是 Smalltalk？）中，获取/设置方法没有意义。
OO设计的基本原则之一：封装！
它为您提供了许多好处，其中之一是您可以在后台更改 getter/setter 的实现，但只要数据类型保持不变，该值的任何使用者都将继续工作。
您应该在以下情况下使用 getter 和 setter：
所以这很少是一个一般的OO问题；这是一个特定于语言的问题，对于不同的语言（和不同的用例）有不同的答案。
从 OO 理论的角度来看，getter 和 setter 是没有用的。你的类的接口是它的作用，而不是它的状态。（如果没有，你写错了类。）在非常简单的情况下，类的作用只是，例如，表示直角坐标中的一个点，* 属性是接口的一部分；getter 和 setter 只是模糊了这一点。但除了非常简单的情况外，属性、getter 和 setter 都不是接口的一部分。
换句话说：如果你认为你的类的消费者甚至不应该知道你有一个spam属性，更不用说能够随意改变它，那么给他们一个set_spam方法是你最不想做的事情。
* 即使对于那个简单的类，您也不一定要允许设置x和y值。如果这真的是一个类，它不应该有像 , 等方法translate吗rotate？如果它只是一个类，因为您的语言没有记录/结构/命名元组，那么这实际上不是 OO 的问题……</sub>
但是没有人做过通用的面向对象设计。他们正在使用特定语言进行设计和实施。在某些语言中，getter 和 setter 远非无用。
如果您的语言没有属性，那么表示概念上是属性但实际上是计算或验证等的东西的唯一方法是通过 getter 和 setter。
即使您的语言确实具有属性，也可能存在它们不充分或不合适的情况。例如，如果你想允许子类控制属性的语义，在没有动态访问的语言中，子类不能用计算属性代替属性。
至于“如果我以后想改变我的实现怎么办？” 问题（在 OP 的问题和接受的答案中以不同的措辞重复多次）：如果它确实是纯粹的实现更改，并且您从属性开始，则可以将其更改为属性而不影响接口。当然，除非你的语言不支持。所以这真的是同样的情况。
此外，遵循您正在使用的语言（或框架）的习惯用法也很重要。如果你用 C# 编写漂亮的 Ruby 风格的代码，那么除了你之外，任何有经验的 C# 开发人员都将难以阅读它，这很糟糕。一些语言的约定比其他语言具有更强的文化。Java 和 Python 在惯用 getter 方面处于相反的两端，碰巧拥有两种最强大的文化，这可能不是巧合。
除了人类读者之外，还会有一些库和工具希望您遵守约定，如果您不遵守约定，则会使您的生活更加艰难。将 Interface Builder 小部件挂接到除 ObjC 属性之外的任何东西，或者使用某些没有 getter 的 Java 模拟库，只会让您的生活变得更加困难。如果这些工具对您很重要，请不要与它们抗争。
从面向对象设计的角度来看，这两种选择都可能通过削弱类的封装而损害代码的维护。对于讨论，您可以查看这篇出色的文章：http ://typicalprogrammer.com/?p=23
代码进化。 当您需要数据成员保护private时非常适合。最终，所有类都应该是一种“小程序”，它们有一个定义明确的接口，你不能只用.
也就是说，软件开发并不是要设置课程的最终版本，就好像您在第一次尝试时要按一些铸铁雕像一样。当您使用它时，代码更像是粘土。 它会随着您的开发而发展，并更多地了解您正在解决的问题领域。在开发过程中，类之间的交互可能超出了它们应有的程度（您计划排除依赖关系）、合并在一起或拆分。所以我认为辩论归结为人们不想虔诚地写作
int getVar() const { return var ; }
所以你有了：
doSomething( obj->getVar() ) ;
代替
doSomething( obj->var ) ;
不仅getVar()视觉上很嘈杂，它还给人一种错觉，这种错觉gettingVar()在某种程度上是一个比实际情况更复杂的过程。如果你的班级有一个 passthru setter，那么你（作为班级作者）如何看待它的神圣性var会让你的班级的用户特别困惑——那么看起来你正在设置这些大门来“保护”你坚持认为有价值的东西， （的神圣性var），但即使你承认var，任何人都可以进来并set var获得他们想要的任何价值，而你甚至没有偷看他们在做什么，所以即使你承认保护也不值得。
所以我编程如下（假设是“敏捷”类型的方法——即当我编写代码时不知道它会做什么/没有时间或经验来计划一个精心设计的瀑布式界面集）：
1) 从具有数据和行为的基本对象的所有公共成员开始。这就是为什么在我的所有 C++“示例”代码中，您会注意到我在使用struct而不是class到处使用。
2）当一个对象的数据成员的内部行为变得足够复杂时，（例如，它喜欢以std::list某种顺序保持内部），编写访问器类型函数。因为我自己编程，所以我并不总是private立即设置成员，但在类进化的某个地方，成员将被“提升”为protectedor 或private.
3) 完全充实并对其内部有严格规则的类（即他们确切地知道自己在做什么，并且你不要对其内部“操”（技术术语））被class指定为默认私有成员，并且只允许选择少数成员public。
我发现这种方法可以让我避免在类演化的早期阶段，当大量数据成员被迁移出去、转移等等时，坐在那里虔诚地编写 getter/setter。
Getter和setter用于实现面向对象编程的两个基本方面，它们是：
假设我们有一个 Employee 类：
package com.highmark.productConfig.types;
public class Employee {
private String firstName;
private String middleName;
private String lastName;
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getMiddleName() {
return middleName;
}
public void setMiddleName(String middleName) {
this.middleName = middleName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
public String getFullName(){
return this.getFirstName() + this.getMiddleName() + this.getLastName();
}
}
在这里，全名的实现细节对用户是隐藏的，用户不能直接访问，这与公共属性不同。
getter 和 setter 方法是访问器方法，这意味着它们通常是用于更改私有类成员的公共接口。您使用 getter 和 setter 方法来定义属性。您可以将 getter 和 setter 方法作为类外部的属性来访问，即使您在类中将它们定义为方法。类之外的那些属性可以具有与类中的属性名称不同的名称。
使用 getter 和 setter 方法有一些优点，例如能够让您创建具有复杂功能的成员，您可以访问类似的属性。它们还允许您创建只读和只写属性。
尽管 getter 和 setter 方法很有用，但您应该注意不要过度使用它们，因为在某些情况下，它们会使代码维护更加困难。此外，它们还提供对您的类实现的访问，例如公共成员。OOP 实践不鼓励直接访问类中的属性。
当您编写类时，总是鼓励您将尽可能多的实例变量设为私有，并相应地添加 getter 和 setter 方法。这是因为有好几次您可能不想让用户更改您的类中的某些变量。例如，如果您有一个私有静态方法来跟踪为特定类创建的实例数，您不希望用户使用代码修改该计数器。只有构造函数语句应该在调用该变量时递增该变量。在这种情况下，您可能会创建一个私有实例变量，并只允许计数器变量使用 getter 方法，这意味着用户只能使用 getter 方法检索当前值，而无法设置新值使用setter方法。
考虑使用访问器的充分理由是没有属性继承。请参见下一个示例：
public class TestPropertyOverride {
public static class A {
public int i = 0;
public void add() {
i++;
}
public int getI() {
return i;
}
}
public static class B extends A {
public int i = 2;
@Override
public void add() {
i = i + 2;
}
@Override
public int getI() {
return i;
}
}
public static void main(String[] args) {
A a = new B();
System.out.println(a.i);
a.add();
System.out.println(a.i);
System.out.println(a.getI());
}
}
输出：
0
0
4
如果您不需要任何验证，甚至不需要维护状态，即一个属性依赖于另一个属性，那么我们需要在一个属性发生更改时维护状态。您可以通过公开字段而不使用 getter 和 setter 来保持简单。
我认为随着程序的发展，OOP 使事情变得复杂，它成为开发人员扩展的噩梦。
一个简单的例子；我们从 xml 生成 c++ 头文件。标头包含不需要任何验证的简单字段。但仍然像在 OOPS 访问器中一样，我们按照以下方式生成它们。
const Filed& getfield() const
Field& getField()
void setfield(const Field& field){...}
这非常冗长，不是必需的。一个简单的
struct
{
Field field;
};
足够且可读。函数式编程没有数据隐藏的概念，他们甚至不需要它，因为它们不会改变数据。
DataStructure 和 Object 是有区别的。
数据结构应该暴露其内在而不是行为。
一个物体不应该暴露它的内在，但它应该暴露它的行为，这也被称为得墨忒耳法则
大多数 DTO 更多地被认为是一种数据结构，而不是对象。他们应该只公开他们的数据而不是行为。在 DataStructure 中使用 Setter/Getter 将暴露行为而不是其中的数据。这进一步增加了违反德墨忒耳法则的机会。
鲍勃叔叔在他的书清洁代码中解释了得墨忒耳定律。
有一个著名的启发式叫做得墨忒耳定律，它说模块不应该知道它所操作的对象的内部结构。正如我们在上一节中看到的，对象隐藏了它们的数据并暴露了操作。这意味着对象不应通过访问器公开其内部结构，因为这样做是公开而不是隐藏其内部结构。
更准确地说，得墨忒耳法则说 C 类的方法 f 应该只调用这些方法：
- C
- f 创建的对象
- 作为参数传递给 f 的对象
- 保存在 C 的实例变量中的对象
该方法不应调用任何允许的函数返回的对象上的方法。换句话说，与朋友交谈，而不是与陌生人交谈。
因此，据此，LoD 违规示例是：
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
这里，函数应该调用它的直接朋友的方法，这里是ctxt，它不应该调用它的直接朋友的朋友的方法。但这条规则不适用于数据结构。所以在这里，如果 ctxt、option、scratchDir 是数据结构，那么为什么要用一些行为来包装他们的内部数据并违反 LoD。
相反，我们可以做这样的事情。
final String outputDir = ctxt.options.scratchDir.absolutePath;
这满足了我们的需求，甚至不违反 LoD。
灵感来自 Robert C. Martin（鲍勃叔叔）的 Clean Code
此外，这是为了“面向未来”您的课程。特别是，从字段更改为属性是 ABI 中断，因此如果您稍后决定需要更多逻辑而不仅仅是“设置/获取字段”，那么您需要中断 ABI，这当然会给任何事情带来问题否则已经针对您的班级进行了编译。
在面向对象的语言中，方法及其访问修饰符声明了该对象的接口。在构造函数与访问器和修改器方法之间，开发人员可以控制对对象内部状态的访问。如果变量只是简单地声明为公共的，那么就没有办法规范这种访问。当我们使用 setter 时，我们可以限制用户输入我们需要的内容。意味着该变量的馈送将来自适当的渠道，并且渠道是我们预定义的。所以使用setter更安全。
另一种用途（在支持属性的语言中）是 setter 和 getter 可以暗示操作是不平凡的。通常，您希望避免在属性中做任何计算上昂贵的事情。
getter/setter 的一个相对现代的优势是可以更轻松地在标记（索引）代码编辑器中浏览代码。例如，如果您想查看谁设置了成员，您可以打开 setter 的调用层次结构。
另一方面，如果成员是公共的，则这些工具无法过滤对该成员的读/写访问权限。因此，您必须艰难地使用该成员的所有用途。
我能想到为什么你不希望所有事情都公开的一个原因。
例如，可以访问您从未打算在类之外使用的变量，甚至可以通过链变量访问（即 object.item.origin.x ）间接访问。
通过将大部分内容设为私有，并且仅将您想要扩展并可能在子类中引用为受保护的内容，并且通常仅将静态最终对象设为公开，然后您可以控制其他程序员和程序可以在 API 中使用的内容以及它的内容可以通过使用 setter 和 getter 访问您想要程序的东西，或者实际上可能其他恰好使用您的代码的程序员可以在您的程序中进行修改。
我只想抛出注释的想法：@getter 和@setter。使用@getter，您应该能够 obj = class.field 但不能使用 class.field = obj。使用@setter，反之亦然。使用@getter 和@setter，您应该能够同时做到这两个。这将通过在运行时不调用琐碎的方法来保留封装并减少时间。
来自数据隐藏的 getter 和 setter 。数据隐藏意味着我们向外界隐藏数据或外部人/事物无法访问我们的数据。这是 OOP 中的一个有用功能。
例如：
如果您创建一个公共变量，您可以访问该变量并在任何地方（任何类）更改值。但是，如果您创建为私有变量，则除了声明的类之外，该变量无法在任何类中查看/访问。
public并且private是访问修饰符。
那么我们如何在外部访问该变量：
这是getter和setter的来源。您可以将变量声明为私有，然后您可以为该变量实现 getter 和 setter。
示例（Java）：
private String name;
public String getName(){
return this.name;
}
public void setName(String name){
this.name= name;
}
优势：
当任何人想要访问或更改/设置balance变量的值时，他/她必须有权限。
//assume we have person1 object
//to give permission to check balance
person1.getName()
//to give permission to set balance
person1.setName()
您也可以在构造函数中设置值，但是稍后当您想要更新/更改值时，您必须实现 setter 方法。
getter/setter 的一个相对现代的优势是可以更轻松地在标记（索引）代码编辑器中浏览代码。例如，如果您想查看谁设置了成员，您可以打开 setter 的调用层次结构。
另一方面，如果成员是公共的，则这些工具无法过滤对该成员的读/写访问权限。因此，您必须艰难地使用该成员的所有用途。
我想发布一个我刚刚完成的真实世界示例：
背景 - 我休眠工具来为我的数据库生成映射，这是我在开发时正在更改的数据库。我更改数据库架构，推送更改，然后运行休眠工具来生成 java 代码。一切都很好，直到我想为那些映射的实体添加方法。如果我修改生成的文件，每次我对数据库进行更改时，它们都会被覆盖。所以我像这样扩展生成的类：
package com.foo.entities.custom
class User extends com.foo.entities.User{
public Integer getSomething(){
return super.getSomething();
}
public void setSomething(Integer something){
something+=1;
super.setSomething(something);
}
}
我上面所做的是用我的新功能（something+1）覆盖超类上的现有方法，而无需触及基类。如果您在一年前编写了一个课程并且想要在不更改您的基类的情况下进入第 2 版（测试噩梦），那么同样的情况。希望有帮助。
如果您想要一个只读变量但不希望客户端必须更改他们访问它的方式，请尝试使用这个模板类：
template<typename MemberOfWhichClass, typename primative>
class ReadOnly {
friend MemberOfWhichClass;
public:
template<typename number> inline bool operator==(const number& y) const { return x == y; }
template<typename number> inline number operator+ (const number& y) const { return x + y; }
template<typename number> inline number operator- (const number& y) const { return x - y; }
template<typename number> inline number operator* (const number& y) const { return x * y; }
template<typename number> inline number operator/ (const number& y) const { return x / y; }
template<typename number> inline number operator<<(const number& y) const { return x << y; }
template<typename number> inline number operator^(const number& y) const { return x^y; }
template<typename number> inline number operator~() const { return ~x; }
template<typename number> inline operator number() const { return x; }
protected:
template<typename number> inline number operator= (const number& y) { return x = y; }
template<typename number> inline number operator+=(const number& y) { return x += y; }
template<typename number> inline number operator-=(const number& y) { return x -= y; }
template<typename number> inline number operator*=(const number& y) { return x *= y; }
template<typename number> inline number operator/=(const number& y) { return x /= y; }
primative x;
};
使用示例：
class Foo {
public:
ReadOnly<Foo, int> cantChangeMe;
};
请记住，您还需要添加按位和一元运算符！这只是为了让你开始
虽然 getter 和 setter 不常见，但这些方法的使用也可以用于 AOP/proxy 模式使用。例如，对于审计变量，您可以使用 AOP 来审计任何值的更新。没有 getter/setter 是不可能的，除非到处更改代码。就个人而言，我从未为此使用过 AOP，但它显示了使用 getter/setter 的另一个优势。
根据我的经验，将变量设置为私有并为每个变量提供访问器和修饰符是理想的。
这样，您可以根据需要创建只读变量或只写变量。
下面的实现显示了一个只写变量。
private String foo;
public void setFoo(String foo) { this.foo = foo; }
private String getFoo() { return foo; }
下面显示了一个只读变量。
private String foo;
private void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }
我会让代码自己说话：
Mesh mesh = new Mesh();
BoundingVolume vol = new BoundingVolume();
mesh.boundingVolume = vol;
vol.mesh = mesh;
vol.compute();
你喜欢它吗？这是二传手：
Mesh mesh = new Mesh();
BoundingVolume vol = new BoundingVolume();
mesh.setBoundingVolume(vol);
这是一个很好的问题，有更好的答案。由于数量很多，我就多放一点。这个例子是基于C#的，只是一段有用的代码。括号中的验证数据已经解释过了。
public class foo
{
public int f1 { get; set; } // A classic GS
public int f2 { get; private set; } // A GS with public read access, the write is only on the private level
public int f3 { private get; set; } // A GS where "You can set, but you can't get" outside the class
public int f4 { get; set; } = 10; // A GS with default value, this is a NEW feature of C# 6.0 / .NET 4.6
}