Trait 继承和 self 类型注释之间的区别

Question

在 Scala 中，我已经看到了构造

trait T extends S

并

trait T { this: S =>

用于实现类似的事情（即必须在创建实例之前定义 S 中的抽象方法）。他们之间有什么区别？为什么你会使用其中一种而不是另一种？

Answer 1

自类型注释允许您表达循环依赖关系。例如：

trait A extends B
trait B { self: A => }

这对于简单继承来说是不可能的。

Answer 2

我会使用自我类型进行依赖管理：这个特征需要混合另一个特征。并且我会使用继承来完善另一个特征或接口。

举个例子：

trait FooService

trait FooRemoting { this : FooService => }
trait FooPersistence { this : FooService => }

object Services extends FooService with FooRemoting with FooPersistence

现在，如果 FooRemoting 和 FooPersistence 都继承自 FooService，并且 FooService 有成员和方法，那么 Services 会是什么样子？

而对于继承，我们会有类似的东西：

trait Iterator[T] {
  def hasNext : boolean
  def next : T
}

trait InfiniteIterator[T] extends Iterator[T] {
  def hasNext = true
}

Answer 3

自从提出问题以来，我遇到了这些帖子：

Spiros Tzavellas 讨论了使用特征作为公共接口，使用自我类型作为必须由实现类混合的帮助器。

总之，如果我们想搬家
特征内部的方法实现
那么我们就有污染界面的风险
用抽象方法描述这些特征
支持实施
具体方法和方法无关
主要负责人
特征。这个问题的解决方案是
将那些抽象方法移入
其他特征并组成特征
一起使用自我类型注释
和多重继承。

例如：

trait PublicInterface { this: HelperTrait =>
  // Uses helperMethod
}

trait HelperTrait {
  def helperMethod = // ...
}

class ImplementationClass extends PublicInterface with HelperTrait

Scala 之旅 讨论使用带有抽象类型成员的自类型注释 - 大概是无法扩展抽象类型成员（？）

Answer 4

我知道这个问题很旧，但我想添加一些说明和示例。

特质遗传和自我类型之间存在三个主要区别。

语义

继承是对象范式中耦合度最高的关系之一，如果 A 扩展 B，则意味着 A 是 B。

假设我们有以下代码，

trait Animal {
  def stop():Unit = println("stop moving")
}

class Dog extends Animal {
  def bark:String = "Woof!"
}

val goodboy:Dog = new Dog

goodboy.bark
// Woof!

我们说狗是 一只动物。我们可以将消息 bark 和 stop 发送给 goodboy，因为它是一只狗，它理解这两种方法。

现在假设我们有一个新特征，

trait Security {
  this: Animal =>
  def lookout:Unit = { stop(); println("looking out!") }
}

这次安全不是动物，这很好，因为如果我们确认安全是动物，那么在语义上就会不正确，它们是不同的概念，可以一起使用。

现在我们可以创建一种新的狗，

val guardDog = new Dog with Security

guardDog.lookout
// stop moving
// looking out!

guardDog 是一只狗，一种动物和安全。它理解停止、吠叫和监视，因为它是一只有安全感的狗。

但是如果我们创造一只这样的新狗会发生什么呢？

val guardDog2:Dog = new Dog with Security
guardDog2.lookout // no such method!

guardDog2 只是一只 Dog，因此我们无法调用 lookout 方法。 （好吧，这是一只具有安全性的狗，但我们只看到一只狗）

循环依赖

自类型允许我们在类型之间创建循环依赖。

trait Patient {
  this: Reader =>
  def isQuite:Boolean = isReading
  def isSlow:Boolean = true
}

trait Reader {
  this: Patient =>
  def read():Unit = if(isSlow) println("Reading Slow...") else println("Reading Fast...")
  def isReading = true
}

val person = new Patient with Reader

以下代码无法编译。

trait Patient extends Reader { /** code **/}

trait Reader extends Patient { /** code **/ }

这种代码在依赖注入（蛋糕模式）中很常见。

多功能性

最后但并非最不重要的一点是，谁使用我们的特征可以决定它们的使用顺序，因此由于特征线性化，尽管使用的特征相同，但最终结果可能会有所不同。

对于正常的继承，我们不能这样做，特征和类之间的关系是固定的。

trait Human {
  def isGoodForSports:Boolean
}

trait Programmer extends Human {
  def readStackOverflow():Unit = println("Reading...")
  override def isGoodForSports: Boolean = false
}

trait Sportsman extends Human {
  def play():Unit = println("Playing something")
  override def isGoodForSports: Boolean = true
}

val foo = new Programmer with Sportsman
foo.isGoodForSports
// true

val bar = new Sportsman with Programmer
bar.isGoodForSports
// false

希望这会有用。

Answer 5

答案是“循环”。但不仅如此。

自类型注释为我解决了继承的基本问题：你继承的东西不能使用你的东西。
有了自我型，一切都变得容易了。

我的模式如下，可以被认为是一个退化的蛋糕：

trait A { self: X => def a = reuseme}
trait B { self: X => def b = a }
class X extends A with B { def reuseme=null }

您可以以多种行为分解您的类，这些行为可以从程序集中的任何位置调用，同时保持干净的类型。
不需要经常（并且错误地）将蛋糕图案与痛苦的间接联系起来。

过去十年中，一半（如果不是全部）复杂的 Java DI 框架都致力于做到这一点，当然不需要打字。
仍在该领域使用 JAVA 的人们显然正在浪费时间：“SCALA ouakbar”。

Answer 6

虽然它没有回答你的问题，但我试图理解自我类型注释，基本上迷失在答案中，并且不知何故最终循环了你的问题的变体，该问题侧重于使用自我类型注释来声明依赖关系。

因此，我在这里发布了一个用例的描述，其中很好地说明了自类型注释，即类似于“this”作为子类型的类型安全情况：

http://programming-scala.labs.oreilly.com/ch13.html#SelfTypeAnnotationsAndAbstractTypeMembers

希望这对最终的人有帮助偶然回答这个问题（并且像我一样，在开始探索之前没有时间阅读 scala 书:-)）