getter和setter方法出错

当您可以加快编码速度并自动提供自文档和标准解决方案时，约定非常有用，这可能是约定优于配置模式如此流行和扩展的主要原因之一。 很好，除非您像往常一样滥用或滥用它们，否则会破坏用户（或读者）的期望，从而增加混乱和耗时的时间（即，即使在您的合同和界面中，也要破坏最小惊讶原则PLA ）。 通常，getter和setter方法是这种过度使用约定的一部分。

当提供框架和库的兼容性时，如此流行的Java Beans约定非常强大，而框架和库则依赖于getter / setter和POJO的内部属性之间的匹配。 开发人员习惯于编写Java Bean的副作用是到处都可以看到getter和setter！ 但是，我们真的需要这么多的吸气剂和吸气剂吗？

考虑数据封装

setter和getter防止访问内部类成员，从而改善了封装，即，我们可以定义set方法来修改内部状态并获取用于访问内部状态的方法，通过公共接口过滤交互，因此具有用于输入验证和状态一致性的入口点 。 但是，为了加强这一原则，我们应该始终将访问权限限制在最低限度 ：其他组件确实需要某种get方法吗？ 是否仅出于测试目的创建了给定的get方法？ 创建对象后通过set方法实际更改内部状态是否合理？ 这些是常见警报，可以发现滥用情况并可能予以纠正。 例如，考虑不为作为计算输出而创建的结果对象公开设置方法，的确可能是向调用方提供多个信息的POJO，但是在这种情况下，我们只需要公开getter而不是 setter：一种可能的解决方案将仅使用getter公开接口，而其具体实现也将提供setter且调用者不可见（例如，程序包可见性）； 否则，请考虑根本没有任何setter方法，并且仅通过其（非公共的？）构造函数或通过Builder模式来初始化对象。

考虑耦合

但是，过量的吸气剂和吸气剂可能会发现错误的面向对象设计，当组件被迫获取和设置值并因此强烈耦合在一起时，将数据移入和移出对象，而应在内部对其进行操作（记住“单一职责”）原则（ SRP ）和告诉不要问（ TDA ）。 结果可能是贫乏的类，不提供任何行为，因此将相关行为移至其他组件。 请记住：类不仅是过程编程语言的结构，它们实际上还应该提供行为，因此，如果调用方需要多个get方法，请考虑提供更简洁和有用的操作。

考虑来电者的期望

API用户不需要为每个调用（特别是对于getter和setter方法）提供文档，他们还应该依赖某些约定。 因此，他们希望getSomething成为访问器方法，并且如果有关的get方法将执行长时间的处理，I / O交互或比单个字段访问更昂贵的操作，则您肯定会违反该期望（但是，我们应排除某些验证）或在发生塞特犬的情况下触发事件）。 如果您的get或set方法带来了开销，则它不是原子操作，并且需要进行额外的计算，请考虑重命名。 方法长度也可以用作度量标准：时间越长，使用不同方法名称的机会就越大。

考虑其他命名约定

Get和set是动词，它们对于简洁和适应非常有用，因此可以用于许多目的和方法名称。 但是，存在许多其他选择，这些选择肯定会避免调用访问器方法的歧义 ，而不是更复杂的方法。 但是，开发人员通常不喜欢在发明方法名称上浪费太多时间，而是选择简单的方法： 通用 get 。 但是，他们真的需要获取或更有意义的东西吗，例如process ， fetch ， find ， 检索 ， 计算 ， 确定 ？

此外，当签名被破坏时，您可能不需要get或set方法：考虑具有多个参数和/或返回类型的setter或具有参数的getter，它们可能会发现设计以进一步重新考虑（您是否需要一次设置多个属性吗？它们不应该只是构造函数的一部分吗？该方法只是一个setter还是在做更多事情？）； 当缺少两者之一时：从Java标准库String＃length或List＃size或Enum＃name，Iterator＃next，Interger＃intValue等来看，它们不是get方法，但它们简短而直观。 另一个示例可能涉及流畅接口的定义，例如应用Builder模式，最好使用withX而不是setX之类的东西：实际上会更流畅 （即Builder.newObject（）。withX（x）.withY（y ），或作为真实示例，例如Java 扫描仪及其useDelimiter（x）.useLocal（y）.useRadix（z）等）。 最后，请尝试在您的API之间保持一致 ，在某些约定之上采用另一约定，以免引起惊讶和混乱。

因此，即使在Java Beans上下文之外也可以扩展getters和setters的狂热，也就是说，即使对于任何Java Beans框架或库都不会使用的POJO或类，我们也要明确指出：使用get / set并没有错在这些情况下的方法，只要不违反标准做法和您的（技术）常识即可。 但是，如果以后可以在Java Reflection处理或基于反射的框架中使用有关的类，那么仍然建议保持get / set约定（考虑使用通用xy访问JSP页面或任何其他面向模板的系统中的属性）模式，则实际上取决于命名约定和某些方法的存在）。 但是，在许多情况下，会有更好的选择可供选择，值得考虑。

翻译自: https://www.javacodegeeks.com/2014/04/getters-and-setters-gone-wrong.html