Scala的Higher-Kinded类型-摩杜云开发者社区

Scala的Higher-Kinded类型

Higher-Kinded从字面意思上看是更高级的分类，也就是更高一级的抽象。我们先看个例子。

如果我们要在scala中实现一个对Seq[Int]的sum方法，应该怎么做呢？

def sum(seq: Seq[Int]): Int = seq reduce (_ + _)

sum(Vector(1,2,3,4,5)) // 结果值: 15

看起来很简单，刚刚我们实现了Seq[Int]的sum操作，那么如果我们想更进一步，我们想同时实现Seq[Int]和Seq[(Int,Int)]的操作该怎么处理呢？

不同的Seq需要不同的add实现，我们先抽象一个trait:

trait Add[T] { 
def add(t1: T, T2: T): T
}

接下来我们在Add的伴生类中定义两个隐式实例，一个Add[Int]，一个Add[(Int,Int)]。

object Add { 
implicit val addInt = new Add[Int] {
def add(i1: Int, i2: Int): Int = i1 + i2
}
implicit val addIntIntPair = new Add[(Int,Int)] {
def add(p1: (Int,Int), p2: (Int,Int)): (Int,Int) =
(p1._1 + p2._1, p1._2 + p2._2)
}
}

这两个隐式实例分别为Add[Int]，一个Add[(Int,Int)]实现了add方法。

最后我们可以定义sumseq方法了：

def sumSeq[T : Add](seq: Seq[T]): T = 
seq reduce (implicitly[Add[T]].add(_,_))

T : Add 被称为上下文定界（ context bound），它暗指隐式参数列表将接受Add[T] 实例。

我们看下怎么调用：

sumSeq(Vector(1 -> 10, 2 -> 20, 3 -> 30)) // 结果值: (6,60)
sumSeq(1 to 10) // 结果值: 55
sumSeq(Option(2)) // 出错!

sumSeq可以接受Seq[Int]和Seq[(Int,Int)]类型，但是无法接收Option。

对于任何一种序列，只要我们为它定义了隐式的Add 实例，那么sumSeq 方法便能计算出该序列的总和。

不过，sumSeq 仍然只支持Seq 子类型。假如容器类型并不是Seq 子类型，但是却实现了reduce 方法，我们该如何对该容器进行处理呢？我们会使用更加泛化的求和操作。这时候就需要使用到higher-kinded 类型了。

我们用M替代Seq，则可以得到M[T],M[T]就是本文介绍的Higher-Kinded类型。

trait Reduce[T, -M[T]] { 
def reduce(m: M[T])(f: (T, T) => T): T
}
object Reduce { 
implicit def seqReduce[T] = new Reduce[T, Seq] {
def reduce(seq: Seq[T])(f: (T, T) => T): T = seq reduce f
}
implicit def optionReduce[T] = new Reduce[T, Option] {
def reduce(opt: Option[T])(f: (T, T) => T): T = opt reduce f
}
}

为了能对Seq 和Option 值执行reduce操作，我们分别为这两类类型提供了隐式实例。为了简化起见，我们将直接使用类型中已经提供的reduce 方法执行reduce操作。

注意这里-M[T]是逆变类型，还记得我们之前的结论吗？函数的参数一定是逆变类型的。因为M[T]是reduce(m: M[T])的参数，所以我们需要定义它为逆变类型-M[T]。

我们看一下sum方法该怎么定义：

def sum[T : Add, M[T]](container: M[T])( 
implicit red: Reduce[T,M]): T =
red.reduce(container)(implicitly[Add[T]].add(_,_))

调用结果如下：

sum(Vector(1 -> 10, 2 -> 20, 3 -> 30)) // 结果值: (6,60)
sum(1 to 10) // 结果值: 55
sum(Option(2)) // 结果值: 2
sum[Int,Option](None) // 错误!

最后一个调用，我们为sum 方法添加的类型签名[Int, Opton] 会要求编译器将None 解释成Option[Int] 类型。假如不添加该类型签名，我们将得到编译错误：无法判断Option[T] 类型中的类型参数T 到底应该对应addInt 方法还是addIntIntPair 方法。

通过显式地指定类型，我们能够得到真正希望捕获的运行错误：我们不能对None 值调用reduce 方法。

在上面的sum方法中，sum[T : Add, M[T]]， T: Add是上下文边界，我们也想定义M[T] 的上下文边界，比如M[T] : Reduce。
因为上下文边界只适用于包含单参数的场景，而Reduce 特征包
含两个类型参数，所以我们需要对Reduce进行改造：

trait Reduce1[-M[_]] { 
def reduce[T](m: M[T])(f: (T, T) => T): T
}
object Reduce1 { 
implicit val seqReduce = new Reduce1[Seq] {
def reduce[T](seq: Seq[T])(f: (T, T) => T): T = seq reduce f
}
implicit val optionReduce = new Reduce1[Option] {
def reduce[T](opt: Option[T])(f: (T, T) => T): T = opt reduce f
}
}

在新的reduce1中，只包含一个类型参数且属于higher-kinded 类型。

M[_]是上篇文章我们讲到的存在类型。T 参数被移至reduce 方法。

修改后的sum方法如下：

def sum[T : Add, M[_] : Reduce1](container: M[T]): T =
implicitly[Reduce1[M]].reduce(container)(implicitly[Add[T]].add(_,_))

我们定义了两个上下文边界，它们分别作用于Reduce1 和Add。而使用implicity 修饰的类型参数则能够区分出这两种不同的隐式值。

M[_]就是我们经常会看到的higher-kinded， higher-kinded虽然带给我们额外的抽象，但是使代码变得更加复杂。大家可以酌情考虑是否需要使用。

更多精彩内容且看：

区块链从入门到放弃系列教程-涵盖密码学,超级账本,以太坊,Libra,比特币等持续更新
Spring Boot 2.X系列教程:七天从无到有掌握Spring Boot-持续更新
Spring 5.X系列教程:满足你对Spring5的一切想象-持续更新
java程序员从小工到专家成神之路（2020版）-持续更新中,附详细文章教程