我是Java或编程的新手，我通常会将Main类的实例作为静态方法，以便从其他类轻松访问它。 例如。private static Main instance;然后我会为它做一个getterpublic static Main getInstance()在其他类上，我只需Main.getInstance().otherMethods();获取在主类上声明的其他方法和变量。
我最近被告知不建议这样做，并被告知我应该使用依赖注入。我的问题是为什么我不应该在 Java 中使用它，为什么依赖注入会更好？使用这种方式或简单地将其作为方法参数传递有什么区别，它的优点和缺点是什么？
关于这个问题已经有很多问题和答案了。您可以搜索"为什么DI"以获得有关原因的大量理论。例如：为什么使用依赖注入？
DI 的主要优点是：
-
灵活性— 如果您需要替换一个组件，或者使用多个组件而不是单个组件，那么 DI 允许您仅通过一些更改来调整代码。
-
更易于单元测试 — 您可以将依赖组件的模拟实现注入到正在测试的组件中，并且仅测试目标组件。
一个现实生活中的例子：
我曾经看到过一个使用单例数据库访问类的项目。整个应用程序中只有一个全局常量：
public static final DB_INSTANCE = ...;
在应用程序周围使用，如下所示：
DB_INSTANCE.runQuery("SELECT ...");
然后功能请求开始能够同时处理多个数据库(一种"分片")。DB_INSTANCE单例代表单个数据库，因此此功能需要重写大量代码行 - 组件现在将"数据库实例"注入其中。
首先，依赖注入不是特定于Java的。这是一种误解。这在许多其他语言中都是一个好主意。无论您使用什么和关注点分离的特定实例，将粘合代码与业务逻辑(这就是依赖注入)分离都是一个好主意。这从来都不是一个坏主意。您应该在您使用的每种语言中执行此操作。对于不同的语言，执行此操作的方式会有所不同。
第二：DIY依赖注入很简单：它是一种设计模式，而不是一个框架。当然，有几个很好的Java框架，当然你可能想使用。手动编写胶水代码是猴子的工作。自动化是个好主意。
其工作方式只是应用一些规则：
- 包含业务逻辑的代码模块/类/对象/函数等不会创建它们自己需要的任何内容(也称为依赖项)。相反，他们需要的一切都通过参数(又名注入)提供给他们。在 Java 中，最好的地方是构造函数。二传手注入也是一回事，但构造函数注入是你应该做的。 构建/构造/初始化
- /配置的代码，如构造函数、main 方法、beforeTest 方法等，不应该做其他工作：不要把业务逻辑放在这里。这就是胶水代码的用武之地。粘附代码不应与业务逻辑混合。
就是这样。简单。创造东西，把它注入到需要的地方。始终如一地这样做。如果你发现你需要在一个地方注入很多东西，那就是一个耦合和内聚性问题：修复它，因为你的设计被破坏了。
这里没有特定于Java的内容。这是应用 SOLID 原则的逻辑结果。你不能这样做，也不能不做依赖注入。你可以在Javascript，Ruby，python，Haskell，lisp等中做到这一点。每次你听说代码难以测试或维护时，你都会发现人们把代码和逻辑混为一谈，把事情搞得一团糟。这些语言中的每一种都有很好的习语来做到这一点。