在定义变量的类中使用getter和setter

虽然该语言不要求您这样做，但在访问通过getter和setter公开的私有字段时，最好使用getter和seter。在某些情况下，我甚至会说，即使对于尚未直接公开的内部属性，也可以使用它们。

这样做之所以是一种好的做法，是因为它将读取和修改私有字段的代码隔离为一组方法。这样，您以后就可以提供额外的验证，甚至可以更改属性的内部存储方式，而无需更改太多位置。

更改的一个示例可能是一个类，该类通过getter（访问器）/setter（赋值器）方法公开某个属性，该属性最初存储为该类中的私有字段。稍后您会意识到，您需要为该属性使用不同的存储库-可能从文件或数据库等中读取该属性。此时，如果您只使用了访问和修改属性的方法，则只需更改访问器和赋值器方法的代码即可实现更改。

另一个例子是扩展类时的实例。它提供了更好的封装。

即使对于测试来说，抽象访问逻辑属性的私有"存储库"也是有意义的。

注意：我指的是作为类的属性公开的私有成员的概念，尽管Java不一定这样指它们。

最后，我再怎么强调也不为过，我建议使用方法而不是直接访问私人成员只是：推荐。许多人认为这是一种很好的做法，因此我建议你遵循，但如果你有充分的理由，请随时不要遵循

简单的答案是：由您决定。

有一种学派认为，你应该始终使用访问器，并且只直接访问访问器中的变量，而不要访问它之外的变量。这确保了你在访问器中实现的任何东西都被可靠地触发。

还有另一种学派认为，访问者是为你的班级的公共合同而存在的，而在你的班级内部，你可以自由地做你想做的事。有时，您可能希望设置一个值，而不需要触发您在访问器中实现的任何其他东西。

（几年前，曾经有一个争论是关于在实际上不需要的地方使用访问器的性能方面，但随着当今的JIT编译方法等，这已经不再是一个因素了。）

这取决于情况。

如果getter或setter不是最终的，并且它打算在潜在的子类中被重写，那么即使从类本身调用它也可能是有意义的，以避免绕过子类向访问器添加的附加行为。

例如，假设一个子类希望在每次更改某个属性时激发一个事件。为此，它重写此属性的setter。但是，如果超类的其他方法在不使用setter的情况下直接修改属性，则不会触发事件。在这种情况下，使用基类中的setter是有意义的。

没有简单的答案。这取决于你的访问者做什么。如果他们只是在那里访问变量，那么这并不重要。。。如果他们做了一些逻辑，那么这取决于你是否想在你的类中使用这个逻辑。

有很多例子表明，您不希望使用类内部的属性访问变量，但不希望外部实体在不通过属性访问器的情况下访问该变量。

也就是说，我看待它的方式是：除非你有正当的理由不通过访问器的逻辑，否则就使用它们。

IT也可能取决于您所处的环境。例如，如果您在Android环境中进行Java编程，则鼓励直接访问，而不是getter/setter。在其他环境中，可能会鼓励getter/setter进行维护。

来自安卓开发者文档http://developer.android.com/guide/practices/design/performance.html

避免内部获取器/设置器

在C++等原生语言中，使用getter（例如。i=getCount（）），而不是直接访问字段（i=mCount）。这是C++的一个很好的习惯，因为编译器通常可以内联访问，以及是否需要限制或调试字段访问您可以随时添加代码。

在安卓系统上，这是个坏主意。虚拟方法调用是昂贵的，比实例字段查找更重要。遵循是合理的常见的面向对象编程实践，并具有getter和公共接口中的setter，但在类中，您应该始终直接访问字段。

如果没有JIT，直接字段访问速度大约是调用琐碎的吸气剂。使用JIT（其中直接字段访问与访问本地），直接现场访问比调用一个琐碎的getter。这在Froyo是真的，但在JIT内联getter方法的未来。

在类内部，我使用私有成员。如果事实证明我也需要访问器中的额外逻辑从类中运行，那么我将它们移到另一个中。Helper、internal、parent，任何东西都不能在当前类中留下歧义。

像这样的问题往往会随着类的重构而激增，并可能留下一些痛苦的、通常很难看到的bug。