我一直在阅读有关吸气剂和二传手的信息，我有一个问题。在访问声明变量的类中的变量时，是否应该使用getter和setter？看起来这里不需要getter和setter因为变量是私有的并不重要，声明它的类总是可以访问它....？
或者当外部类想要访问这些变量时，是否应该使用getter和setter？
答案 0 :(得分：8)
虽然该语言不要求您这样做，但在访问通过getter和setter公开的私有字段时，最好使用getter和setter。在某些情况下，我甚至会说，即使对于未直接暴露的内部属性，使用它们也是有意义的。
这样做的好理由是因为它将读取和修改私有字段的代码隔离到一组方法中。这样您以后可以提供额外的验证，甚至可以更改属性在内部存储的方式，而无需更改太多地方。
更改的示例可能是通过getter（accessor）/ setter（mutator）方法公开某个属性，该属性最初存储为该类中的私有字段。稍后您意识到您需要为该属性使用不同的存储库 - 可以从文件或数据库等中读取它。此时如果您只使用这些方法来访问和修改属性，您只需更改用于实现更改的访问器和mutator方法的代码。
另一个例子是扩展类时的实例。它提供了更好的封装。
即使对于测试，抽象对逻辑属性的私有“存储库”的访问也是有意义的。
注意：我指的是您作为类的属性公开的私有成员的概念，即使Java不一定是指它们。
最后，我无法强调，我建议使用方法而不是直接访问私有成员只是：建议。许多人认为这是一种很好的做法，因此我建议你遵循，但如果你有充分的理由，请务必不要跟随！
答案 1 :(得分：2)
简单的答案是：这取决于你。
有一种思想流派认为你应该总是使用访问者，并且只能直接访问访问者中的变量，而不是在访问者之外。这可以确保可靠地触发您在访问器中实现的任何内容。
还有另一种思想流派认为，你的班级的公共合同中存在访问者，而在你的班级内部，你可以自由地做你想做的事。有时您可能想要设置一个值，而不用触发您在访问器中实现的任何其他内容。
（几年前曾经有过一个关于使用访问者的性能方面的论据，你实际上并不需要这样做，但是对于今天的JIT编译方法等，这不再是一个因素完全没有。）
答案 2 :(得分：1)
这取决于。
如果getter或setter不是final，并且如果要在潜在的子类中重写，那么甚至可以从类本身调用它也是有意义的，以避免绕过子类添加的附加行为访问者。
例如，假设一个子类想要在每次更改某个属性时触发事件。为此，它会覆盖此属性的setter。但是，如果超类的某些其他方法直接修改属性，而不使用setter，则不会触发该事件。在这种情况下，使用基类中的setter是有意义的。
答案 3 :(得分：1)
没有简单的答案。取决于您的访问者所做的事情。如果他们只是在那里访问变量，那么它并不重要......如果他们做了一些逻辑，那么这取决于你是否想要在你的类中使用该逻辑。
有很多例子你不想使用类中的属性来访问变量，但是不允许外部实体在不通过属性访问器的情况下访问该变量。
那就是说，我的看待它的方式是：除非你有正当理由不通过访问者的逻辑，否则使用它们。
答案 4 :(得分：1)
IT也可以依赖于您正在使用的环境。例如，如果您在Android环境中进行Java编程，则鼓励直接访问，而不是getter / setter。在其他环境中，可以鼓励getter / setter的可维护性。
来自http://developer.android.com/guide/practices/design/performance.html
的Android开发人员文档避免使用内部吸气剂/装置者
在像C ++这样的母语中，使用getter是常见的做法（例如 i = getCount（））而不是直接访问该字段（i = mCount）。 这是C ++的一个很好的习惯，因为编译器通常可以 内联访问，如果您需要限制或调试字段访问 您可以随时添加代码。
在Android上，这是一个坏主意。虚方法调用很昂贵， 实例字段查找要多得多。遵循是合理的 常见的面向对象编程实践，并有getter和 公共界面中的setter，但你应该始终在一个类中 直接访问字段。
没有JIT，直接字段访问速度比调用a快3倍 琐碎的吸气剂。使用JIT（直接现场访问便宜） 访问本地），直接字段访问速度比快7倍 调用一个微不足道的吸气剂。在Froyo中也是如此，但是会有所改善 JIT内联getter方法的未来。
答案 5 :(得分：0)
在类中我使用私有成员。如果事实证明我需要访问器中的额外逻辑从类中运行，那么我将它们移到另一个中。帮助者，内部，父母，任何东西，但在当前的课堂上留下歧义。
类似的问题会随着类的重构而扩散，并且可能会留下一些痛苦而且经常难以看到的错误。