【问题标题】:'public static final' or 'private static final' with getter?带有getter的“公共静态最终”或“私有静态最终”?
【发布时间】:2012-04-20 07:49:58
【问题描述】:

在 Java 中,变量应该保持私有以实现更好的封装,但是静态常量呢?这个:

public static final int FOO = 5;

结果与此等价:

private static final int FOO = 5;
...
public static getFoo() { return FOO; }

但哪种做法更好?

【问题讨论】:

  • 投票结束不具建设性(基于已经提供的固执己见的反馈)。 FOO 真的是一个常数吗?提供FOO 的类是API 的一部分吗?还是端点应用程序的一部分?有一些永远不会改变的数学常数。还有一些永远不应该改变的位标志(参见 SWT)。所以答案是“视情况而定”。

标签: java static private public final


【解决方案1】:

由于最终变量不能在以后更改,如果您要将它用作全局常量,只需将其公开,不需要 getter。

【讨论】:

  • 只有当你绝对确定你永远不会改变最终变量时。常量由编译器内联,如果它们稍后更改并且您不重新编译所有内容,这可能会导致极其令人惊讶的结果。编辑:想通了,这是值得的答案,让它更显眼。
【解决方案2】:

Getter 在这里毫无意义,很可能会被 JVM 内联。坚持使用公共常量。

封装背后的想法是保护变量的不必要更改并隐藏内部表示。使用常量没有多大意义。

【讨论】:

    【解决方案3】:

    如果 getFoo 结果是常数且不需要在运行时评估,则为第一个。

    【讨论】:

      【解决方案4】:

      在 member 上使用 setter 和 getter 的好处是能够覆盖。 这对静态“方法”(而不是函数)无效

      也没有办法定义接口的静态方法。

      我会去现场访问

      【讨论】:

        【解决方案5】:

        我会继续使用 getFoo(),因为它允许您在将来更改实现而不更改客户端代码。正如@Tomasz 所指出的,JVM 可能会内联您当前的实现,因此您会付出很大的性能损失。

        【讨论】:

          【解决方案6】:

          不直接在代码中使用常量的原因之一。

          假设 FOO 稍后可能会更改(但仍保持不变),请告诉 public static final int FOO = 10;。只要没有人愚蠢到直接硬编码值,就不应该破坏任何东西吗?

          没有。 Java编译器会将上面的Foo等常量内联到调用代码中,即someFunc(FooClass.FOO);变成someFunc(5);。现在,如果您重新编译您的库而不是调用代码,您可能会遇到令人惊讶的情况。如果您使用函数,则可以避免这种情况 - JIT 仍会对其进行优化,因此不会影响到真正的性能。

          【讨论】:

          • 有趣,我从来没有意识到这一点。不过,我从来没有在野外遇到过带有 getter 的常量。
          • 感谢您的信息,看来私有常量和吸气剂在经验上是更安全的选择,应该被视为更好的做法。
          • @Chris 取决于你的常量是什么 - 有很多常量是一成不变的(例如,Pi 在这么多年之后不太可能变成 3 ;))所以我不会谴责在所有情况下都使用公共常量。但是应该记住这一点,因为调试这样的问题是非常可怕的。
          • 哇! +10!我从事这项业务的时间比我愿意提及的要长,而且我一直想知道为什么我不应该只在看起来安全的情况下使用公共常量!
          • @TJ 如果“常量”将来可能发生变化,请使用吸气剂。如果常量始终相同,您可以使用公共常量。
          【解决方案7】:

          将类外的变量用作:

          public def FOO:Integer = 5; 
          

          如果封装不是您的首要任务。否则使用第二个变体,以便您公开方法而不是变量。

          private static final int FOO = 5;
          ...
          public static getFoo() { return FOO; }
          

          不依赖变量也是代码维护的更好做法。请记住“过早的优化是万恶之源”。

          【讨论】:

            猜你喜欢
            • 2011-03-04
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2012-09-29
            • 2010-11-27
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多