使用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; }
而前者需要的样板代码要少得多。
当前回答
此外，这是为了“未来证明”你的课程。特别是，从字段更改为属性是ABI中断，因此如果您稍后决定需要更多的逻辑而不仅仅是“设置/获取字段”，那么您需要中断ABI，这当然会给针对您的类编译的任何其他内容带来问题。
其他回答
很多人都在谈论二传手和二传手的优点，但我想扮演魔鬼代言人的角色。现在我正在调试一个非常大的程序，程序员们决定让所有的东西都变得更好和更好。这看起来不错，但这是一场逆向工程噩梦。
假设你正在查看数百行代码，你会发现：
person.name = "Joe";
这是一段非常简单的代码，直到你意识到它是一个setter。现在，您遵循该setter，发现它还设置了person.firstName、person.lastName、person.isHuman、person.hasReallyCommonFirstName，并调用person.update（），后者将查询发送到数据库等。哦，这就是发生内存泄漏的地方。
乍一看就理解一段本地代码是具有良好可读性的一个重要特性，getter和setter往往会打破这一特性。这就是为什么我尽量避免使用它们，并在使用它们时尽量减少它们所做的事情。
OO设计的基本原则之一：封装！
它给您带来了许多好处，其中之一是您可以在幕后更改getter/setter的实现，但只要数据类型保持不变，任何具有该值的使用者都将继续工作。
访问器和赋值器的一个优点是可以执行验证。
例如，如果foo是公共的，我可以很容易地将其设置为null，然后其他人可以尝试调用对象上的方法。但它已经不在了！使用setFoo方法，我可以确保foo从未设置为null。
访问器和赋值器也允许封装-如果你不应该在值设置后看到它（也许它在构造函数中设置，然后被方法使用，但不应该被更改），那么任何人都不会看到它。但如果您允许其他类查看或更改它，则可以提供适当的访问器和/或赋值器。
它可以用于延迟加载。假设所讨论的对象存储在数据库中，除非您需要，否则您不想获取它。如果该对象由getter检索，则内部对象可以为空，直到有人请求它，然后您可以在第一次调用getter时获取它。
我在交给我的一个项目中有一个基本页面类，它从几个不同的web服务调用加载一些数据，但这些web服务调用中的数据并不总是用于所有子页面。Web服务具有所有的优点，它开创了“慢”的新定义，因此如果不需要，您不想进行Web服务调用。
我从公共字段转到getter，现在getter检查缓存，如果缓存不存在，则调用web服务。因此，通过一点包装，许多web服务调用被阻止了。
因此，getter使我不必在每个子页面上找出我需要什么。如果我需要它，我打电话给吸气器，如果我还没有，它会帮我找到它。
protected YourType _yourName = null;
public YourType YourName{
get
{
if (_yourName == null)
{
_yourName = new YourType();
return _yourName;
}
}
}
我想发布一个我刚刚完成的真实世界示例：
背景-我使用休眠工具为我的数据库生成映射，这是一个我在开发时正在更改的数据库。我更改数据库模式，推送更改，然后运行hibernate工具来生成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版（测试噩梦），也是同样的情况。希望这会有所帮助。
