import static vs. static final

时间:2013-01-29 13:47:39

标签: java performance memory import constants

过去我经常在Java类中使用“import static”构造。最近我意识到,而不是

import static my.pack.A.MY_CONSTANT;

你可以使用

import my.pack.A;

public class B {
    private static final MY_CONSTANT = A.MY_CONSTANT;
}

这种方法最明显的优点是:

  1. 您可以在Eclipse中使用重构来轻松地从代码中删除所有长常量表达式,例如A.B.C.CONSTANT.ANOTHER_ONE.TOO_LONG,而不会弄乱静态导入(在Eclipse中不能很快掌握)
  2. 您可以为任何表达式指定任何名称,这在当前上下文中可能更有意义。
  3. 例如:

    private static final PAYMENT_TYPE = PaymentType.CASH;
    ...
    calculateSomething(amount, PAYMENT_TYPE);
    

    而不是

    import static my.pack.PaymentType.CASH
    ...
    calculateSomething(amount, CASH);
    

    如果默认的PaymentType值更改为CREDIT_CARD,这也更容易重构。

    我的问题是:与静态导入相比,这种方法有任何缺点吗?或者它可以在任何地方使用吗?

    我现在唯一关心的是生成的编译.class文件,这可能与所描述的两种方法不同。因此,理论上性能和内存使用可能会受到影响。

2 个答案:

答案 0 :(得分:5)

我认为唯一的缺点是你有更多的代码,你可以将一个常量分配给另一个常量。除此之外应该没有区别。性能和内存无关紧要,您可能会有更多的引用返回到相同的常量池条目。即使它创建了单独的常量池条目,也需要很多它们才能有所作为。

如果无法重命名原始条目,那么能够为常量提供良好的名称可能是一件非常好的事情。

答案 1 :(得分:3)

这主要是品味问题,但官方docs建议谨慎使用static版本,特别是使用通配符。静态导入的主要缺点是它通过向其添加所有静态成员来污染您的命名空间。在上面的示例中,它应该是您认为代码更易读的内容。除非你真的想要static的所有package成员,否则不要做“导入包。*”的冲动。

它不应该影响你的编译代码 - 它只是提供了对同一个常量的简写访问。