17

最近 Scala 的博主似乎对类型类模式充满热情，其中一个简单的类具有由符合某些特征或模式的附加类添加的功能。作为一个非常简单的例子，简单的类：

case class Wotsit (value: Int)

可以适应 Foo 特质：

trait Foo[T] {
  def write (t: T): Unit
}

在这个类型类的帮助下：

implicit object WotsitIsFoo extends Foo[Wotsit] {
  def write (wotsit: Wotsit) = println(wotsit.value)
}

类型类通常在编译时使用隐含捕获，允许 Wotsit 及其类型类一起传递到更高阶的函数中：

def writeAll[T] (items: List[T])(implicit tc: Foo[T]) =
  items.foreach(w => tc.write(w))

writeAll(wotsits)

（在你纠正我之前，我说这是一个过于简单的例子）

但是，隐式的使用假定项的精确类型在编译时是已知的。我发现在我的代码中通常情况并非如此：我将拥有某种类型的项目 List[T] 的列表，并且需要发现正确的类型类来处理它们。

Scala 建议的方法似乎是在调用层次结构中的所有点添加 typeclass 参数。随着代码的扩展，这可能会变得很烦人，并且这些依赖项需要通过越来越不相关的方法传递到越来越长的链中。这使得代码混乱且难以维护，这与 Scala 的用途相反。

通常这是依赖注入介入的地方，使用库在需要的时候提供所需的对象。细节因为 DI 选择的库而异——我过去曾用 Java 编写过自己的库——但通常注入点需要精确定义所需的对象。

麻烦的是，在类型类的情况下，精确值在编译时是未知的。必须根据多态描述来选择它。至关重要的是，编译器已经删除了类型信息。清单是 Scala 的类型擦除解决方案，但我还不清楚如何使用它们来解决这个问题。

人们会建议 Scala 的哪些技术和依赖注入库来解决这个问题？我错过了一个技巧吗？完美的 DI 库？或者这真的是它看起来的症结所在？

澄清

我认为这实际上有两个方面。在第一种情况下，需要类型类的点是通过直接函数调用从其操作数的确切类型已知的点到达的，因此足够的类型争论和语法糖可以允许将类型类传递给点它是需要的。

在第二种情况下，这两个点被一个屏障隔开——例如一个不能更改的 API，或者存储在数据库或对象存储中，或者序列化并发送到另一台计算机——这意味着类型类可以' t 与其操作数一起传递。在这种情况下，给定一个类型和值仅在运行时已知的对象，需要以某种方式发现类型类。

我认为函数式程序员习惯于假设第一种情况 - 使用足够先进的语言，操作数的类型将始终是可知的。David 和 mkniessl 对此提供了很好的答案，我当然不想批评这些。但是第二种情况确实存在，这就是我将依赖注入引入问题的原因。

4

3 回答 3

13

可以通过使用新的上下文绑定语法来减轻传递这些隐式依赖项的相当数量的乏味。你的例子变成

def writeAll[T:Foo] (items: List[T]) =
  items.foreach(w => implicitly[Foo[T]].write(w))

它的编译方式相同，但签名清晰明了，并且浮动的“噪声”变量更少。

不是一个很好的答案，但替代方案可能涉及反射，我不知道有任何库可以让它自动工作。

于 2010-07-15T14:18:37.547 回答
11

（我已经替换了问题中的名称，他们没有帮助我思考问题）

我将分两步解决这个问题。首先，我展示了嵌套作用域如何避免在其使用过程中一直声明类型类参数。然后我将展示一个变体，其中类型类实例是“依赖注入”的。

类型类实例作为类参数

为了避免在所有中间调用中必须将类型类实例声明为隐式参数，您可以在定义特定类型类实例应该可用的范围的类中声明类型类实例。我正在使用快捷语法（“上下文绑定”）来定义类参数。

object TypeClassDI1 {

  // The type class
  trait ATypeClass[T] {
    def typeClassMethod(t: T): Unit
  }

  // Some data type
  case class Something (value: Int)

  // The type class instance as implicit
  implicit object SomethingInstance extends ATypeClass[Something] {
    def typeClassMethod(s: Something): Unit =
      println("SomthingInstance " + s.value)
  }

  // A method directly using the type class
  def writeAll[T:ATypeClass](items: List[T]) =
    items.foreach(w => implicitly[ATypeClass[T]].typeClassMethod(w))

  // A class defining a scope with a type class instance known to be available    
  class ATypeClassUser[T:ATypeClass] {

    // bar only indirectly uses the type class via writeAll
    // and does not declare an implicit parameter for it.
    def bar(items: List[T]) {
      // (here the evidence class parameter defined 
      // with the context bound is used for writeAll)
      writeAll(items)
    }
  }

  def main(args: Array[String]) {
    val aTypeClassUser = new ATypeClassUser[Something]
    aTypeClassUser.bar(List(Something(42), Something(4711)))
  }
}

将类实例类型为可写字段（setter 注入）

上面的一个变体，可以使用 setter 注入来使用。这一次，类型类实例通过 setter 调用传递给使用类型类的 bean。

object TypeClassDI2 {

  // The type class
  trait ATypeClass[T] {
    def typeClassMethod(t: T): Unit
  }

  // Some data type
  case class Something (value: Int)

  // The type class instance (not implicit here)
  object SomethingInstance extends ATypeClass[Something] {
    def typeClassMethod(s: Something): Unit =
      println("SomthingInstance " + s.value)
  }

  // A method directly using the type class
  def writeAll[T:ATypeClass](items: List[T]) =
    items.foreach(w => implicitly[ATypeClass[T]].typeClassMethod(w))

  // A "service bean" class defining a scope with a type class instance.
  // Setter based injection style for simplicity.
  class ATypeClassBean[T] {
    implicit var aTypeClassInstance: ATypeClass[T] = _

    // bar only indirectly uses the type class via writeAll
    // and does not declare an implicit parameter for it.
    def bar(items: List[T]) {
      // (here the implicit var is used for writeAll)
      writeAll(items)
    }
  }

  def main(args: Array[String]) {
    val aTypeClassBean = new ATypeClassBean[Something]()

    // "inject" the type class instance
    aTypeClassBean.aTypeClassInstance = SomethingInstance

    aTypeClassBean.bar(List(Something(42), Something(4711)))
  }
}

请注意，第二种解决方案具有基于 setter 的注入的常见缺陷，您可能会忘记设置依赖项并在使用时获得一个不错的 NullPointerException ...

于 2010-07-15T19:59:40.710 回答
0

这里反对类型类作为依赖注入的论点是，对于类型类，“项目的精确类型在编译时是已知的”，而对于依赖注入，它们不是。你可能对这个Scala 项目重写工作感兴趣，我从蛋糕模式转移到依赖注入的类型类。查看这个文件，其中进行了隐式声明。注意环境变量的使用如何确定精确的类型？这就是你如何协调类型类的编译时间要求和依赖注入的运行时间要求。

于 2018-03-29T18:10:52.597 回答