为访问方法(getter/setters)添加更多功能，而不仅仅是this.x = x;或return x;通常被认为是不好的风格。
我正在寻找可以在技术论文中引用的书面来源。JavaBeans 规范不包含有关访问方法内容的语句。Java 语言规范也没有。
是否有任何官方的Oracle文档或具有重要意义的类似文件明确指出了这一点？还是只是一部不成文的法律？
编辑：似乎我对"通常被认为是不良风格"的看法是错误的。我不想开始讨论基于意见的话题。对我来说，我的答案是，我不能认为它被认为是糟糕的风格。感谢您的输入！
从本质上讲，这是一种固执己见的观点，但我的印象恰恰相反。 如果确实将getter/setter限制为简单的返回/分配，那么它们将没有附加值，然后直接方法。
这是很常见的，并且期望二传手有一些验证。
此外，可以为计算字段(如getSum()，getAvg()等)创建getter方法，在这种情况下，它们可能包括简单或复杂的计算。
正如@SharonBenAsher所写，这个话题是基于意见的，我支持相反的意见。
恕我直言，这是两种基本类型的类：数据传输对象(DTO/豆)和其他。默认情况下，只有 DTO 应该有 getter(并且不太常见)setter。"其他"类只有在有充分理由需要违反信息隐藏原则时才应该有getter。
但是为什么他们不应该有(复杂的)逻辑呢？
我的理由是：它违反了单一责任模式。DTO的职责是携带数据。验证数据一致性或对其进行一些计算的责任属于使用/填充 DTO 的代码。
那么为什么会有吸气剂/二传手呢？ 为什么不直接访问？ 使 DTO 像 C 结构一样——莎朗·本·阿舍
尔
因为信息隐藏原理。
仅仅因为你有一个DTO，并不意味着你必须将值存储在一些不同的成员变量中，它可能是一个集合。
DTO也可以由其他DTO组成：
class Circle{
private Point center;
private double radius;
Circle(double x, double y, double r){
center = new Point(x,y);
radius=r;
}
getX(){return center.getX();}
getY(){return center.getY();}
getRadius(){return radius;}
}
直接访问属性时，您必须意识到这一点，以后不能更改它......
我看不出验证其状态的类如何违反单一责任模式。 它可能会调用实用程序或一些外部类来帮助验证过程， – 莎朗·本·阿舍尔
这更糟糕。实用程序类是添加到将 DTO 传递到的下一层的隐藏依赖项。只要这个"下一层"在同一个JVM上，这可能不是问题，但如果它是在网络连接的另一端呢？
但不能说它绝对不对这项任务负责。 – 莎朗·本·阿舍
我有吗？
就我自己而言，我认为我的理由足够沉重，可以按照我的方式去做。如果你不同意，对我来说很好。
这取决于设计和具体情况。与创造相同。有时您将责任委托给工厂方法，有时您将直接调用构造函数。 – 莎朗·本·阿舍
但是，如果情况发生变化(就像应用程序开发时通常所做的那样)怎么办？我将验证与数据结构分开的方法将始终有效。
我认为您的示例代码是非简单getter的一个很好的例子... – Sharon Ben Asher
但它没有复杂的逻辑。