导入静态是一个好习惯吗？ [关闭]答案

【问题标题】：Is import static a good practice? [closed]导入静态是一个好习惯吗？ [关闭]
【发布时间】：2020-12-26 00:02:12
【问题描述】：

我在用 Java 编码时问自己，import static com.example.method 是一个好方法还是导入整个类更好。

【问题讨论】：

在这种情况下，我认为导入整个类更正常。但我不会说导入静态方法就不好了。
我限制自己将静态数据导入枚举（尤其是在类中广泛使用时）和使用函数参数时的方法（即 Class.staticComparator()）；
几年前我曾经是静态导入的忠实拥护者，但现在我已经尽我所能禁止它，即使是Assertions.* 或Mockito.*。这背后的基本原理是，并非所有名称都适合静态导入（例如，of、forName、valueOf）；添加/删除许多静态导入时，导入单个类不会导致（很多）（git）差异；静态导入可能会发生冲突并且可能看起来模棱两可（例如getInstance、valueOf）。类前缀名称 retain 上下文（例如，比较：SECOND - 它是来自 TimeUnit 的枚举值还是来自其他地方的常量？）
@fluffy 上下文非常重要。例如，许多 DSL 被构建为在静态导入时易于阅读。
另一个不使用静态导入但现在仅作为个人喜好的优点是我有一个色彩丰富的语法突出显示方案，因此类型（但对于类、接口、抽象类和枚举）被识别为一种彩色上下文标记，以免与调用类的（静态）成员或静态导入的成员混淆（我认为我的 IDE 必须提供一个选项来突出显示静态导入，但这就是我保持可读性的方式）。

【解决方案1】：

取决于上下文，不存在在所有情况下都使用的明确规则。但最常见的用途是当您进行测试并需要导入诸如 Assert.* 或 Mockito.* 之类的类时，以便不重复 Assertion。 assertEquals 很多时候一个好主意是做这样的事情：

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertAll;
import static org.junit.jupiter.api.Assertions.assertEquals;

class ErrorsControllerImplTest {

    @Test
    void should_return_all_the_errors_types() {
        ErrorsController controller = new ErrorsControllerImpl();

        assertAll(
                () -> assertEquals(58, controller.getAllErrors().size()),
                () -> assertEquals("BadRequestStatus {code=4000509, message='Site must have a value'}",
                        controller.getAllErrors().get(0)));
    }
}

正如另一位用户所说，其想法是代码可读并删除重复部分。

【讨论】：

好吧，你说得有道理。 +1。在这里确实很有用。反正我还是讨厌它，是魔鬼。
我同意你的观点，我不喜欢使用它。我使用这种类型导入的唯一地方是在单元测试中，在其余的类中我更喜欢了解什么是这种静态方法。