我想发布一个我刚刚完成的真实世界示例：

背景-我使用休眠工具为我的数据库生成映射，这是一个我在开发时正在更改的数据库。我更改数据库模式，推送更改，然后运行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版（测试噩梦），也是同样的情况。希望这会有所帮助。

我知道现在有点晚了，但我想有些人对表演感兴趣。

我做了一个性能测试。我写了一个类“NumberHolder”，它包含一个整数。您可以使用getter方法读取该IntegeranInstance.getNumber（）或通过使用anInstance.number直接访问数字。我的程序通过两种方式读取数字1000000000次。该过程重复五次，并打印时间。我得到了以下结果：

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是吸气方式）

你看，吸气器（几乎）总是快一点。然后我尝试了不同次数的循环。我用了1000万和10万，而不是100万。结果：

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比常规方法快一点。我希望这对你有所帮助。

访问器和赋值器的一个优点是可以执行验证。

例如，如果foo是公共的，我可以很容易地将其设置为null，然后其他人可以尝试调用对象上的方法。但它已经不在了！使用setFoo方法，我可以确保foo从未设置为null。

访问器和赋值器也允许封装-如果你不应该在值设置后看到它（也许它在构造函数中设置，然后被方法使用，但不应该被更改），那么任何人都不会看到它。但如果您允许其他类查看或更改它，则可以提供适当的访问器和/或赋值器。

从面向对象设计的角度来看，这两种选择都会削弱类的封装，从而对代码的维护造成损害。对于讨论，您可以查看这篇优秀的文章：http://typicalprogrammer.com/?p=23

如果您不需要任何验证，甚至不需要维护状态，即一个属性依赖于另一个属性，那么当一个属性发生更改时，我们需要维护状态。您可以通过公开字段而不使用getter和setter来保持简单。

我认为OOP会随着程序的增长而使事情变得复杂，这对于开发人员来说是一场噩梦。

一个简单的例子；我们从xml生成c++头。标头包含不需要任何验证的简单字段。但仍然像OOPS访问器一样，我们生成它们的方式如下。

const Filed& getfield() const
Field& getField() 
void setfield(const Field& field){...} 

这是非常冗长的并且不是必需的。一个简单的

struct 
{
   Field field;
};

足够且可读。函数式编程没有数据隐藏的概念，它们甚至不需要它，因为它们不会改变数据。

代码不断演变。private非常适合需要数据成员保护的情况。最终，所有的类都应该是一种“小程序”，它有一个定义良好的接口，你不能只使用它的内部结构。

也就是说，软件开发并不是要设置课程的最终版本，就好像你在第一次尝试时按下了一些铸铁雕像一样。当你使用它时，代码更像粘土。它随着你的发展而发展，并进一步了解你正在解决的问题领域。在开发过程中，类之间可能会发生不应有的交互（您计划排除的依赖关系）、合并或拆分。因此，我认为争论归结为人们不想虔诚地写作

int getVar() const { return var ; }

所以你有：

doSomething( obj->getVar() ) ;

而不是

doSomething( obj->var ) ;

getVar（）不仅在视觉上很嘈杂，而且给人一种错觉，认为getingVar（（）在某种程度上是一个比实际更复杂的过程。如果你的类有一个passthrough setter，那么你（作为类编写者）如何看待var的神圣性对你的类的用户来说尤其令人困惑——那么你似乎在设置这些门来“保护”你坚持认为有价值的东西，（var的神圣性）但即使你承认，任何人只要进来并将var设置为他们想要的任何值，而你甚至不去偷看他们在做什么，那么var的保护就没有多大价值。

所以我按如下方式编程（假设采用“敏捷”类型的方法——即当我编写代码时不知道它将要做什么/没有时间或经验来规划一个复杂的瀑布式界面集）：

1） 从具有数据和行为的基本对象的所有公共成员开始。这就是为什么在我所有的C++“示例”代码中，你会注意到我到处使用结构而不是类。

2） 当对象对数据成员的内部行为变得足够复杂时（例如，它喜欢以某种顺序保存内部std:：list），就会编写访问器类型函数。因为我是自己编程的，所以我并不总是立即将成员设置为私有，但是在类的进化过程中，成员将被“提升”为受保护或私有。

3） 完全充实并对其内部有严格规则的类（即，它们确切地知道自己在做什么，你不能“操”（技术术语）它的内部）被赋予类名称，默认为私有成员，只有少数成员被允许公开。

我发现这种方法可以让我避免在一个类进化的早期阶段，当大量数据成员被迁移、转移等时，坐在那里虔诚地编写getter/setter。