这主要是一个编码风格的问题。我想知道从实用程序类中存储和获取对象是否是一个很好的编码原则？
例如，假设我创建了一个整数列表，并希望该列表被其他类使用。但是，为了做到这一点，每次我想使用/编辑列表时，我都必须在每个类中传递列表。 与其这样做，不如创建一个实用程序类，每次我想使用它时都为我"获取"此列表？
使用实用程序类可以清理我的代码。但是，我听说即使使用实用程序类也被认为是一种不好的做法。 谢谢！
public class ThisExample {
private static final List<Integer> thisList = new ArrayList<Integer>();
public static List<Integer> getMoveHistory() {
return thisList;
}
}
我建议从利弊的角度看待你的问题，而不是最佳实践，因为后者是一个意见问题。
使用全局容器的优点：
- 易于访问全局变量 - 将导入容器的每个类都将能够访问全局数据。
- 共享变量的中心化 - 查找特定的全局变量很容易，假设所有变量都存储在同一个容器类中。 文档 - 将所有全局变量
- 存储在一个类中有助于记录全局变量的上下文和用途 - 只需按上下文对它们进行分组，并添加注释解释它们在应用程序中的角色。
- 简单性 - 对于较小的代码库/应用程序，使用单线程方法和少量类和代码流，使用全局变量容器可能是在实体之间传递信息的简单直接的解决方案。
使用全局容器的缺点：
-
类耦合 - 所有使用全局变量的类都必须导入相同的 Container 类，这将导致许多其他类对容器类的依赖。对容器类的更改现在将同时影响许多其他类。
-
单点故障 - 许多应用程序代码流将通过抛出容器类。这使得某些方法(例如使用同步锁)在容器类上使用不切实际，例如出于性能考虑。
-
调试困难 - 由于应用程序的许多元素将不可避免地访问全局变量，因此调试其内容可能更加困难，尤其是在多线程解决方案中。
-
面向对象的反模式 - 如果 OO 方法专注于代码的封装和解决方案的抽象，那么全局容器则完全相反 - 纯粹专注于实现的共享代码(例如，使用 DS 全局变量时)。
-
始终在内存中 - 只要应用程序运行，全局容器的变量就会在范围内。许多内存泄漏是被遗忘的范围内变量的结果。
引用：
- 使用全局变量的优缺点
- 全局变量与局部变量
- 全局变量有多危险