Java中getter的命名约定有多重要？

Question

我非常相信一致性,因此也就是惯例.

但是,我目前正在开发一个Java框架,其中这些约定(特别是get/ setprefix约定)似乎妨碍了可读性.例如,一些班级都会有id和name性能和使用o.getId()替代o.id()似乎是有很多原因毫无意义:

• 这些类是不可变的,因此(通常)没有相应的setter,
• 没有混淆的可能性,
• 在get这种情况下传送没有额外的语义和
• 我get在整个库中使用这个无编号的命名模式.

我从Java Collection类(以及Java平台库中的其他类)中获得了一些保证,这些类也违反了JavaBean约定(例如,它们使用size而不是getSize等等).

为了解决这个问题:组件永远不会被用作JavaBean,因为它们不能以这种方式有意义地使用.

另一方面,我不是一个经验丰富的Java用户,我不知道其他Java开发人员对库的期望.我可以在这里遵循Java平台类的示例,还是被认为是糟糕的风格？在Java库类中违反get/ setconvention被认为是回顾的错误吗？或者在不适用时忽略JavaBean约定是完全正常的吗？

(Java的Sun代码约定根本没有提到这一点.)

Answer 1

如果您遵循相应的命名约定,那么第三方工具可以轻松地与您的库集成并使用您的库.他们期望getX(),isX()等,并试图通过反射来找到这些.

虽然你说这些目前不会作为JavaBeans公开,但我仍然会遵循这些惯例.谁知道你可能想要进一步做什么？或者在稍后阶段你可能想要提取这个对象的接口并创建一个可以通过其他工具访问的代理？

Answer 2

我其实讨厌这个惯例.如果它被一个提供accessor/modifier方法的真正的java工具所取代,那么我会发生这种情况.

但我在所有代码中都遵循这个惯例.我们不单独编程,即使整个团队现在同意特殊约定,您也可以放心,未来的新人或将来维护您项目的团队将在开始时遇到困难......我认为获取/设置的不便并不像非标准的不便那么大.

我想提出另一个问题:java软件经常使用太多的访问器和修改器(get/set).我们应该更多地应用" 告诉,不要问 "的建议.例如,用"真实"方法替换B上的getter:

    class A {
      B b;
      String c;
      void a() {
        String c = b.getC();
        String d = b.getD();
        // algorithm with b, c, d
      }
    }

通过

    class A {
      B b;
      String c;
      void a() {
        b.a(c); // Class B has the algorithm.
      }
    }

这个重构获得了许多好的属性:

• B可以是不可变的(非常适合线程安全)
• B的子类可以修改计算,因此B可能不需要另一个属性用于此目的.
• B中的实现比A更简单,因为你不必使用getter和外部访问数据,你在B里面并且可以利用实现细节(检查错误,特殊情况,使用缓存的值...).
• 位于B中它具有更多耦合(两个属性而不是A的一个),重构A可能不会影响算法.对于B重构,可能是改进算法的机会.所以维护就少了.

Answer 3

违反Java库类中的get/set约定肯定是一个错误.我实际上建议你遵循惯例,以避免知道为什么/何时不遵守约定的复杂性.