在Java中,命名约定对于吸气剂有多重要?

如果遵循适当的命名约定,那么第三方工具可以轻松地与库集成并使用库。他们会期待 getX() , isX() 等等,试着通过思考找到这些。

尽管您说这些不会像JavaBeans一样被公开,但我仍然会遵循这些约定。谁知道你想做什么?或者在稍后的阶段,您可能希望提取这个对象的接口,并创建一个可以通过其他工具访问的代理?

我真的很讨厌这个会议 . 如果它被一个真正的Java工具所取代,它将提供访问器/修饰符方法。

但我确实遵守这个惯例 在我所有的代码中。我们不单独计划,即使整个团队现在同意一个特别的会议,你可以放心,未来的新人,或未来的团队,将维持你的项目,将有一个困难的时间在开始…我相信,对于get/set的不便并没有非标准的不便那么大。

我想提出另一个问题:Java软件经常使用过多的访问器和修饰符(get /set)。我们应该更多地应用 告诉,不要问 “建议。例如,用“real”方法替换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重构,这可能是改进算法的一个机会。所以维修就少了。

在Java库类中违反GET/SET约定无疑是一个错误。我真的会推荐你 跟随 公约,以避免知道为什么/何时不遵守公约的复杂性。

乔希·布洛赫在这件事上实际上站在你这边 Effective Java 他主张 get -为了可读性,对于那些不打算用作bean的东西来说,变体更少。当然,并不是每个人都同意布洛赫的观点,但它显示出存在支持和反对倾销的案例。 得到 . (我认为它更容易阅读,所以如果雅格尼 得到 )

关于 size() 方法;当您查看,例如最近的 Enum 班级有 name() 和 ordinal() . (可能可以用布洛赫是 枚举 的两位作者。艾尔)

get-less模式在scala等语言中使用(和 other languages ) Uniform Access Principle :

scala将字段名和方法名保持在同一个名称空间中,这意味着如果方法名为count,则可以对字段计数进行命名。许多语言,如Java,不具有这种限制,因为它们将字段和方法名保持在单独的命名空间中。

由于Java不打算为“属性”提供UAP,所以最好使用GET/SET约定来引用这些属性。

UAP意味着:

• Foo.bar 和 Foo.bar() 是相同的,并且引用了reading属性,或者引用了该属性的read方法。
• Foo.bar = 5 和 Foo.bar(5) 相同,请参阅设置属性或属性的写入方法。

在爪哇,你不能实现UAP,因为 酒吧酒吧 和 Fo.Bar() 位于两个不同的命名空间中。
这意味着要访问read方法,必须调用 Fo.Bar() ,这与调用任何其他方法没有区别。
因此,这种get-set约定有助于区分该调用与其他调用(与属性无关),因为模块提供的“所有服务(此处“只是读取/设置一个值,或计算它”)不能通过统一的符号来提供。
它不是强制的,但它是一种从其他服务识别与获取/设置或计算属性值相关的服务的方法。
如果UAP在Java中可用,则根本不需要该约定。

注:该 size() 而不是 getSize() 可能是遗留下来的,因为Java的咒语而被保留下来的错误命名是“向后兼容:总是”。

考虑一下:可以告诉许多框架引用对象字段中的属性,比如“name”。在框架的框架下,首先将“name”转换为“setname”,从其单数参数中找出返回类型,然后形成“getname”或“is name”。

如果您没有提供这样一个有良好文档记录的、明智的访问器/调换器机制,那么您的框架/库将无法与现有的大多数其他库/框架一起工作。