使用和不使用 Java 读写方法的原因

"Accessors increase robustness of Java code" 中引入了访问(读写)方法（直接操纵字段值的成员函数）。有两种访问方法：setter，用于修改字段值；以及 getter，用于获取字段值。读写方法确实会为代码增加一些开销，但这些开销很小 -- 特别是与象有问题的数据库设计这样的其它因素相比。在本文中，我将讨论两个基本问题：为什么应该使用读写方法以及何时不应该使用？

为什么使用读写方法？

为什么使用读写方法？ 读写方法以下列方式改进类和组件的可维护性：

• 提供单点更新。可单点更新每个属性，这使得修改和测试更加容易。换句话说，属性被封装起来。
• 控制对属性的访问。可以完全控制如何访问属性以及由谁来访问属性。
• 允许对“昂贵”的属性进行延迟初始化。延 迟初始化表示：只有在首次访问属性时才初始化（设置）属性值。这种方法的优点是：只有在需要属性值时才花功夫去获取属性值。延迟初始化的主要缺点是：代码 将变得更复杂，因为需要查看是否定义了属性，如果还未定义，则要获取属性值。当难以计算或获取属性（可能属性太大，在网络上发送需要大量时间）以及并不是 每次将对象读入内存都需要属性时，通常要使用延迟初始化。
• 减少了子类及其超类之间的耦合。当子类只通过其相应读写方法访问继承的属性时，可以在超类中更改属性实现，而不会影响它的任何子类。这有效地减少了它们之间的耦合。读写方法减少了超类中的更改影响到其子类的这种 脆弱的基类问题所带来的风险。
• 封装对属性的更改。如果与一个或多个属性相关的商业规则发生更改，您可以相应地修改读方法，使其提供与更改之前同样的功能，从而较容易地响应新的商业规则。
• 缓解名称隐藏问题。虽然应该避免名称隐藏（为本地变量赋予与属性相同的名称），但是始终使用读写方法来访问属性意味着：可以为本地变量赋予任何名称。您无需担心隐藏属性名称，因为您永远不会以任何方式直接访问它们。
• 封装确认逻辑。如果需要实现关键确认逻辑（例如确保银行帐户的存款始终是正数），则考虑将该逻辑放置在 setter 这个有效场所。
• 封装撤销／重做逻辑。如果应用程序需要支持撤销／重做逻辑，则具有适当的读写方法将极大方便该功能的实现。

getter 的一种高级用法是获取常数值。遗憾的是，这种技术在 Java 编程世界中不很常见。常见的是使用 use static finals 来实现“常数”值，这是一种与信息隐藏的面向对象概念背道而驰的方法。而将常数值封装在一个静态 getter 方法中则会给您一个强健得多的解决方案。当那些值发生更改、或从常数演变成一个根据已定义的商业规则集计算出的值时，您只需要在 getter 中更新该值，而无需更新使用该常数的每一行代码。静态字段并不理想，但是当常数值不可能更改（例如一星期内的天数）时，也可以使用这种方法。然而，当常数 代表一个用户定义的值（例如共有基金必须包含的最小值）时，您将冒着这个值可能改变的风险，因此最好用静态 getter 方法来实现它。

回页首

何时不应该使用读写方法？

您可能不想使用读写方法的唯一情况是在执行时间极其重要时，但事实上，应用程序中增加的耦合却很少能证明这种行为。在 Concurrent Programming in Java（请参阅 参考资料）中，Lea 用这点来证明其“尽量少用读写方法”的观点：组合中的属性值常常必须一致，单独提供对属性的访问是不明智的。他说得对，因此不要公开所有读写方法！在这种情况下，我将实现一种整批 setter 方法，该方法将立刻更新几个属性、适当地确认其商业值，然后调用更新单一值的专用 setter 方法。我想，Lea 忽略了无需使所有读写方法公开这一观点（如同我在 "Java accessor visibility" 中所指出的）。顺便提一句，整批 setter 方法在 EJB 1.x 开发工作中十分常见，它用于阻止标准和性能的降低，并实现持久性。简而言之，当某些属性值取决于其它值时，您应该引入能做“正确事”的方法，并根据需要使适当的读写方法成为受保护的或专用的。