在当今的OO后世界中，依赖注入是否仍然有意义？

到了2015年。大多数新流行语言都或多或少地发挥了作用。 像Java这样的旧版本获得了功能编程元素。 在Scala中，人们越来越倾向于纯粹的一面，使用更多的FP和更少的OO。 那么–依赖注入？ 真？

您可以说DI只是使用（构造函数）参数。 我在使用MacWire在Scala中进行无框架DI的演讲中也这么说。 传递参数是FP的基本构建块。 那么，为什么要给它起另一个名字呢？ DI是一个单独的概念吗？

不同种类的参数

最近，我在博客上与Alois Cochard进行了简短的讨论， 他在其中描述了一种类似于我的DI的方法。 他还曾经写过一个DI库（ Sindi ），所以很高兴知道我们得出了类似的结论。 但这让我思考–也许有两种参数？

一种参数是普通的“数据”参数。 那就是我们传递函数，操纵，修改，持久化等等的东西。这些是实体，集合，集合，案例类。 另一种是“服务”参数。 这些是封装业务逻辑，允许与外部系统进行通信，提供数据访问的类。

虽然您当然只能使用FP端对端创建整个系统，但我认为许多人（包括我在内）发现使用FP（小型）和对象（大型）方便且易读，如编程Scala书或此Quora问题中所述 。 因此，您可能有一些纯粹的FP代码来处理数据，实现核心业务逻辑片段，并且由对象封装（组织为？）（您可以将它们称为“服务”，“模块”，或者可以更好地反映总体的名称）。责任）。

那就是DI出现的地方。 在连接“服务” /“模块”对象图时，它非常有用。 创建对象图的方法可能与处理任何其他类型的对象相同（通过手动执行DI或借助MacWire或容器进行处理），但是使用参数的方式却有所不同。

环境环境

考虑“数据”和“服务”参数拆分的另一种方法是，服务形成了我们（是否为纯FP）代码的执行环境。 这样的环境可能包含用于访问数据库，与用户通信等的服务。当前，我们使用相同的机制-参数-来定义环境（例如，通过构造函数参数），因为我们习惯于在函数周围传递数据。 但是也许在将来的某些编程语言中，这些概念会分开吗？

还是代替创建单独的机制（最终可能会带来更差的“影子”功能），我们可以使用一些更方便的语法来创建和使用环境？

这样的“环境”参数的一个很好的例子是Scala中非常常用的ExecutionContext 。 当前，它经常作为隐式参数传递（并且具有传染性，在我们要操纵期货的每个地方，从方法到方法……都需要隐式）。 至少对我来说，它是参数的另一种“种类”，例如Set[Person] 。 如果我们仅假设我们的代码是在提供“某些”执行上下文的环境中执行的，那不是很好吗？ 其他示例可能包括访问数据库的“某种”方式。 或与网络服务对话的“某种”方式。

这些“环境”参数通常是我们要交换进行测试或根据部署配置更改的参数-依赖项注入的“规范”用例。

最后，阿洛伊斯·科查德（Alois Cochard）还向我介绍了托马斯·佩特里切克（Tomas Petricek）关于环境参数演算的演讲（仅20分钟！）。 是时候学习协同效应了？ :)

翻译自: https://www.javacodegeeks.com/2015/02/in-todays-post-oo-world-is-dependency-injection-still-relevant.html