静态方法或DI

Question

我对Java或程序设计不熟悉，通常我会将Main类的实例作为静态方法来轻松地从其他类访问它。 例如。 private static Main instance;然后为它public static Main getInstance()做一个吸气剂，在其他类上，我只需做Main.getInstance().otherMethods();就可以得到在Main类上声明的其他方法和变量。

最近我被告知不推荐这样做，并被告知我应该改用依赖注入。我的问题是为什么我不应该在Java中使用它，为什么依赖注入会更好？使用这种方式还是简单地将其作为方法参数传递有什么区别？它的优缺点是什么？

Answer 1

已经有很多关于此的问题和答案。您可以搜索“为什么要使用DI”以获得有关其原因的大量理论。例如：Why does one use dependency injection?

DI的主要优点是：

• 灵活性-如果您需要替换一个组件，或者使用多个组件而不是单个组件，那么DI允许您仅进行一些更改即可调整代码。

• 更易于单元测试-您可以将依赖项组件的模拟实现注入到要测试的组件中，并且仅测试目标组件。

一个真实的例子：

我曾经见过一个使用Singleton数据库访问类的项目。整个应用程序中只有一个全局常量：

public static final DB_INSTANCE = ...;

在整个应用程序中都使用过，例如：

DB_INSTANCE.runQuery("SELECT ...");

然后功能请求可以同时使用多个数据库（有点像“分片”）。 DB_INSTANCE单例代表一个数据库，因此此功能需要 ton 行代码进行重写-组件现在已向其中注入了“数据库实例”。

Answer 2

首先，依赖项注入不是Java特定的。这是一个误解。在许多其他语言中，这是个好主意。不管您使用什么和关注点分离的特定实例，将胶合代码与业务逻辑（这就是依赖注入）分开都是一个好主意。这绝不是一个坏主意。您应该使用所有使用的语言来做到这一点。对于不同的语言，您如何执行此操作。

第二：DIY Dependency Injection is easy：这是一种设计模式，而不是框架。当然，当然您可能要使用几个好的Java框架。手动编写胶水代码是猴子的工作。自动化是一个好主意。

此方法的工作原理是简单地应用一些规则：

包含业务逻辑的
1. 代码模块/类/对象/功能等本身不会创建它们所需的任何东西（也称为依赖项）。相反，它们所需的一切都通过参数（也称为注入）提供给了它们。在Java中，执行此操作的最佳位置是构造函数。设置器注入也是一回事，但是构造函数注入是您应该做的。
2. 构建/构造/初始化/配置（如构造函数，主方法，beforeTest方法等）的代码除此以外不应起作用：请勿在此处放置业务逻辑。这就是胶合代码的去向。胶水代码绝对不能与业务逻辑混在一起。

就是这样。简单。创建东西，将其注入到需要的地方。始终如一。如果您发现需要在一个地方注入很多东西，那就是耦合和内聚的问题：请修复它，因为您的设计已损坏。

这里没有Java专用的内容。这是应用SOLID原则的逻辑结果。您不能那样做，也不能做依赖注入。您可以使用Javascript，Ruby，python，Haskell，lisp等来执行此操作。每次听到有关代码难以测试或维护的消息时，您会发现人们将胶水代码和逻辑混为一谈，并弄得一团糟。这些语言中的每一种都有很好的习惯用法。