不要滥用静态对象和静态方法

不要滥用静态对象和静态方法

禁止转载！

接触了一些项目，发现的静态对象和静态方法被滥用了。多数情况下，静态类对象不应该是编程的首选。

1. 缺点

使用静态对象的缺点有：

1. 状态管理复杂性：

   静态对象在应用程序的整个生命周期中保持状态，这意味着它们的状态在所有使用它们的地方是共享的。这可能会导致难以追踪和管理状态变化，尤其是在多线程环境中。

2. 线程安全问题：

   静态对象和方法在多线程环境中需要特别小心，因为它们可能会被多个线程同时访问和修改。如果没有正确的同步机制，这可能会导致竞态条件（race conditions）和数据不一致性。

3. 内存泄漏风险：

   静态对象在应用程序的整个生命周期中都存在，可能会导致内存泄漏。如果静态对象持有对大量资源的引用，并且这些资源没有被正确释放，内存使用量会不断增加，最终可能导致内存不足。

4. 难以测试：

   由于静态方法和对象是全局的，通常很难在单元测试中对它们进行模拟或替换。这会使得测试变得复杂，并且难以实现测试的隔离性和独立性。

5. 设计和可维护性问题：

   过度使用静态方法和对象可能会导致代码设计不良，使得代码难以理解和维护。静态方法和对象打破了面向对象编程中的封装原则，可能会导致紧耦合的代码结构。

6. 不支持多态性：

   静态方法不支持多态性（polymorphism），这意味着它们不能被子类覆盖。这限制了代码的可扩展性和灵活性。

2. 枚举实现策略模式

最近看到一些人提出使用 Java 枚举实现策略模式，这显然也是一种误用：枚举也可以看做静态代码，枚举的依赖可能随着业务的需求不断变化，会带来维护性问题。

3. Logger 可以是静态的

最常见的 Logger 实现是在每个类对象下创建私有静态实例，曾经 log 如何使用也是有争议的，SLF4J 官方也曾推荐使用成员对象记录日志，目前使用静态实例的方式已被大多数人所认可。

我们看下 Logger 如何解决以上所说的问题：

1. 测试：Logger 可以指定默认实现，在单元测试时使用 NoOp 实现，简单配置即可，无需在单测中额外处理
2. 线程安全问题：SLF4J 的多数底层实现是线程安全的
3. 状态管理：使用时 Logger 是无状态的
4. 设计和维护性问题：SLF4J 使用 Facade 模式 + 工厂模式 解决了紧耦合的问题
5. 不支持多态性：Logger 静态对象声明的是接口，通过 服务发现（SPI）来实现多态。

总的来说，使用静态变量若想避免其缺点，在设计方面需要进行精心的考量，SLF4J 值得我们借鉴。不过，从一般的开发角度来说，使用成员对象可以满足我们的大多数需求，简单有效，同时也不需要这些设计模式与技巧。