3

当我们通过 Reader 实现 DI 时，我们将依赖项作为方法签名的一部分。假设我们有（没有实现）：

trait Service1 { def f1:Int = ??? }
trait Service2 { def f2:Reader[Service1, Int] = ??? }

type Env= (Service1, Service2)
def c:Reader[Env, Int] = ???  //use Service2.f2 here

现在，f2需要额外的服务来实现，比如：

trait Service3
type Service2Env = (Service1, Service3)
//new dependecies on both:
trait Service2 { def f2:Reader[Service2Env, Int] = ??? }

它将破坏现有客户，如果Service2.f2不提供Service3额外服务，他们将无法再使用。

通过注入（通过构造函数或设置器）进行 DI，这在 OOP 中很常见，我将c仅用作Service2. 它是如何构造的以及它的依赖项列表是什么，我不在乎。从这一点开始，任何新的依赖都Service2将保持函数的签名c不变。

它是如何以FP方式解决的？有选择吗？有没有办法注入新的依赖项，但以某种方式保护客户免受更改？

4

1 回答 1

3

有没有办法注入新的依赖项，但以某种方式保护客户免受更改？

这有点违背目的，因为使用 Reader（或 Final Tagless 或 ZIO 环境）是一种在每个函数的类型签名中显式声明（直接和间接）依赖关系的方法。您这样做是为了能够跟踪代码中这些依赖项的使用位置——只需查看函数签名，您就可以判断此代码​​是否可能具有戏剧性的副作用，例如发送电子邮件（或者可能你这样做是出于其他原因，但结果是一样的）。

对于不需要那种级别的静态检查的依赖项/效果，您可能希望将此与构造函数注入混合并匹配。

于 2019-04-03T08:53:45.760 回答