Scala 中的类型类有什么用？

Question

据我了解，这篇博文“类型类” Scala 只是一个用特征和隐式适配器实现的“模式”。

正如博客所说，如果我有特征 A 和适配器 B -> A 然后我可以调用一个函数，该函数需要 A 类型的参数，以及 B 类型的参数，而无需显式调用此适配器。

我发现它很好但不是特别有用。您能否提供一个用例/示例来说明此功能的用途？

Answer 1

根据要求，一个用例...

假设您有一个事物列表，可以是整数、浮点数、矩阵、字符串、波形等。给定此列表，您想要添加内容。

实现此目的的一种方法是拥有一些 Addable 特征，该特征必须由可以添加在一起的每个单个类型继承，或者在处理时隐式转换为 Addable来自第三方库的对象，您无法对其接口进行改造。

当您还想开始添加其他可以对对象列表执行的此类操作时，这种方法很快就会变得难以承受。如果您需要替代方案（例如，添加两个波形是否将它们连接起来，或者重叠它们？），它也不能很好地工作。解决方案是临时多态性，您可以在其中选择行为对现有类型进行改造。

对于最初的问题，您可以实现一个 Addable 类型类：

trait Addable[T] {
  def zero: T
  def append(a: T, b: T): T
}
//yup, it's our friend the monoid, with a different name!

然后您可以创建该类型的隐式子类实例，对应于您希望可添加的每种类型：

implicit object IntIsAddable extends Addable[Int] {
  def zero = 0
  def append(a: Int, b: Int) = a + b
}

implicit object StringIsAddable extends Addable[String] {
  def zero = ""
  def append(a: String, b: String) = a + b
}

//etc...

对列表求和的方法将变为编写起来很简单...

def sum[T](xs: List[T])(implicit addable: Addable[T]) =
  xs.FoldLeft(addable.zero)(addable.append)

//or the same thing, using context bounds:

def sum[T : Addable](xs: List[T]) = {
  val addable = implicitly[Addable[T]]
  xs.FoldLeft(addable.zero)(addable.append)
}

这种方法的优点在于，您可以提供某些类型类的替代定义，可以通过导入控制作用域中所需的隐式定义，也可以通过显式提供其他隐式参数来控制。因此，可以提供不同的波形相加方式，或者指定整数加法的模运算。将某个第三方库中的类型添加到您的类型类中也相当轻松。

顺便说一句，这正是 2.8 集合 API 所采用的方法。虽然 sum 方法是在 TraversableLike 上定义的，而不是在 List 上定义的，并且类型类是 Numeric （它也包含更多操作，而不仅仅是 zero 和 append）

Answer 2

重读那里的第一条评论：

类型类和接口之间的一个重要区别是，类 A 要成为接口的“成员”，它必须在其自己的定义处进行声明。相比之下，只要您可以提供所需的定义，就可以随时将任何类型添加到类型类中，因此类型类在任何给定时间的成员都依赖于当前作用域。因此，我们并不关心 A 的创建者是否预期了我们希望它所属的类型类；如果不是，我们可以简单地创建我们自己的定义，表明它确实属于，然后相应地使用它。因此，这不仅提供了比适配器更好的解决方案，从某种意义上说，它还消除了适配器要解决的整个问题。

我认为这是类型类最重要的优点。

此外，它们还可以正确处理操作没有我们正在分派的类型的参数或有多个参数的情况。例如考虑这个类型类：

case class Default[T](val default: T)

object Default {
  implicit def IntDefault: Default[Int] = Default(0)

  implicit def OptionDefault[T]: Default[Option[T]] = Default(None)

  ...
}

Answer 3

我认为类型类是向类添加类型安全元数据的能力。

因此，您首先定义一个类来对问题域进行建模，然后考虑要添加到其中的元数据。像 Equals、Hashable、Viewable 等。这创建了问题域和使用类的机制的分离，并开放了子类化，因为类更精简。

除此之外，您可以在范围内的任何位置添加类型类，而不仅仅是定义类的位置，并且您可以更改实现。例如，如果我使用 Point#hashCode 计算 Point 类的哈希码，那么我仅限于该特定实现，该实现可能无法为我拥有的特定 Point 集创建良好的值分布。但如果我使用 Hashable[Point]，那么我可以提供我自己的实现。

[更新示例]
作为一个例子，这是我上周的一个用例。在我们的产品中，有几种 Maps 包含容器作为值的情况。例如，Map[Int, List[String]] 或 Map[String, Set[Int]]。添加到这些集合可能会很冗长：

map += key -> (value :: map.getOrElse(key, List()))

所以我想要一个函数来包装它，这样我就可以编写

map +++= key -> value

主要问题是集合并不都具有相同的添加元素的方法。有些有“+”，而另一些则有“:+”。我还想保留向列表添加元素的效率，所以我不想使用创建新集合的折叠/映射。

解决方案是使用类型类：

  trait Addable[C, CC] {
    def add(c: C, cc: CC) : CC
    def empty: CC
  }

  object Addable {
    implicit def listAddable[A] = new Addable[A, List[A]] {
      def empty = Nil

      def add(c: A, cc: List[A]) = c :: cc
    }

    implicit def addableAddable[A, Add](implicit cbf: CanBuildFrom[Add, A, Add]) = new Addable[A, Add] {
      def empty = cbf().result

      def add(c: A, cc: Add) = (cbf(cc) += c).result
    }
  }

这里我定义了一个类型类Addable，它可以将元素C添加到集合CC中。我有 2 个默认实现：对于使用 :: 的列表，对于其他集合，使用构建器框架。

然后使用这个类型类是：

class RichCollectionMap[A, C, B[_], M[X, Y] <: collection.Map[X, Y]](map: M[A, B[C]])(implicit adder: Addable[C, B[C]]) {
    def updateSeq[That](a: A, c: C)(implicit cbf: CanBuildFrom[M[A, B[C]], (A, B[C]), That]): That  = {
      val pair = (a -> adder.add(c, map.getOrElse(a, adder.empty) ))
      (map + pair).asInstanceOf[That]
    }

    def +++[That](t: (A, C))(implicit cbf: CanBuildFrom[M[A, B[C]], (A, B[C]), That]): That  = updateSeq(t._1, t._2)(cbf)
  }

  implicit def toRichCollectionMap[A, C, B[_], M[X, Y] <: col

特殊的一点是使用 adder.add 来添加元素，并使用 adder.empty 为新键创建新集合。

相比之下，如果没有类型类，我将有 3 个选择：
1. 为每个集合类型编写一个方法。例如，addElementToSubList 和 addElementToSet 等。这会在实现中创建大量样板文件并污染命名空间
2.使用反射来判断子集合是否是List/Set。这很棘手，因为地图一开始就是空的（当然 scala 在这里也可以通过清单提供帮助）
3. 通过要求用户提供加法器来具有穷人的类型类别。像 addToMap(map, key, value, adder) 这样的东西，简直丑陋

Answer 4

我发现这篇博文有用的另一种方式是它描述了类型类： Monads 是不是隐喻

在文章中搜索类型类。这应该是第一场比赛。在本文中，作者提供了一个 Monad 类型类的示例。

Answer 5

论坛主题“是什么让类型类比特征更好？”提出了一些有趣的观点：

• 类型类可以非常轻松地表示在存在子类型的情况下很难表示的概念，例如相等和排序。
  练习：创建一个小的类/特征层次结构，并尝试在每个类/特征上实现.equals，使得对层次结构中任意实例的操作具有适当的自反性、对称性和传递性。< /里>
• 类型类允许您提供证据，证明您“控制”之外的类型符合某些行为。
  其他人的类型可以是您的类型类的成员。
• 你不能用子类型来表达“这个方法接受/返回与方法接收者相同类型的值”，但是这个（非常有用的）约束使用类型类是很简单的。这是f 边界类型问题（其中 F 边界类型通过其自己的子类型进行参数化）。
• 对特征定义的所有操作都需要一个实例；总是有一个 this 参数。因此，您不能在 trait Foo 上定义一个 fromString(s:String): Foo 方法，这样您就可以在没有 Foo 实例的情况下调用它。
  在 Scala 中，这表现为人们拼命尝试对伴生对象进行抽象。
  但对于类型类来说它很简单，如这个幺半群示例中的零元素所示< /a>.
• 类型类可以归纳定义；例如，如果您有 JsonCodec[Woozle]，则可以免费获得 JsonCodec[List[Woozle]]。
  上面的例子说明了“可以添加在一起的东西”。

Answer 6

查看类型类的一种方法是它们启用追溯扩展或追溯多态性。 休闲奇迹和丹尼尔·韦斯特海德 显示了在 Scala 中使用类型类来实现此目的的示例。

这是 在我的博客上发帖
探索了 scala 中的各种方法追溯超类型，一种追溯扩展，包括类型类示例。

Answer 7

除了临时多态性之外，我不知道还有任何其他用例，它的解释是这里可能是最好的方法。

Answer 8

隐式和类型类都用于类型转换。它们的主要用例是为您无法修改但期望继承类型的多态性的类提供临时多态性（即）。如果是隐式，您可以使用隐式 def 或隐式类（这是您的包装类，但对客户端隐藏）。类型类更强大，因为它们可以向现有的继承链添加功能（例如：scala 排序函数中的 Ordering[T]）。
有关更多详细信息，您可以参阅 https://lakshmirajagopalan.github.io/diving-into -scala-类型类/

Answer 9

在 scala 类型类中

• 启用临时多态性
• 静态类型（即类型安全）
• 借用 Haskell
• 解决表达式问题

行为可以扩展
- 在编译时
-事后
- 无需更改/重新编译现有代码

Scala 隐式 方法

的最后一个参数列表可以标记为隐式

• 隐式参数由编译器填充

• 实际上，您需要编译器的证据

• ...例如作用域中存在类型类

• 指定参数。

式

/**
* Created by nihat.hosgur on 2/19/17.
*/
case class PrintTwiceString(val original: String) {
   def printTwice = original + original
}

object TypeClassString extends App {
  implicit def stringToString(s: String) = PrintTwiceString(s)
  val name: String = "Nihat"
  name.printTwice
}

Answer 10

这是一个重要的区别（函数式编程所需）：

考虑 inc:Num a=>一个-> a：

收到的a与返回的相同，这不能通过子类型来完成

Answer 11

我喜欢使用类型类作为依赖注入的轻量级 Scala 惯用形式，它仍然可以处理循环依赖，但不会增加很多代码复杂性。我最近重写了一个 Scala 项目，使用 Cake 模式为 DI 键入类 并实现了代码大小减少 59%。