A特质的自我类型:
trait B
trait A { this: B => }
他说:“A不能被混合到一个具体的类中，这个类不能同时扩展B。”
另一方面，以下几点:
trait B
trait A extends B
表示“任何(具体或抽象的)类在A中混合也会在B中混合”。
这两句话的意思难道不是一样的吗?自我类型似乎只用于产生简单的编译时错误的可能性。
我错过了什么?
当前回答
它主要用于依赖注入，例如在饼模式中。有一篇很棒的文章介绍了Scala中许多不同形式的依赖注入，包括饼模式。如果你谷歌“蛋糕模式和Scala”，你会得到很多链接，包括演示文稿和视频。现在，这里是另一个问题的链接。
现在，关于自我类型和扩展特质之间的区别，这很简单。如果你说B扩展了A，那么B就是A。当你使用自类型时，B需要一个A。用自类型创建了两个特定的需求:
如果B被扩展了，那么你就需要加入A。 当一个具体的类最终扩展/混合这些特征时，某些类/特征必须实现a。
考虑以下例子:
scala> trait User { def name: String }
defined trait User
scala> trait Tweeter {
| user: User =>
| def tweet(msg: String) = println(s"$name: $msg")
| }
defined trait Tweeter
scala> trait Wrong extends Tweeter {
| def noCanDo = name
| }
<console>:9: error: illegal inheritance;
self-type Wrong does not conform to Tweeter's selftype Tweeter with User
trait Wrong extends Tweeter {
^
<console>:10: error: not found: value name
def noCanDo = name
^
如果Tweeter是User的子类，就不会出现错误。在上面的代码中，无论何时使用Tweeter，我们都需要一个User，但是User没有提供给Wrong，所以我们得到了一个错误。现在，上面的代码仍然在范围内，考虑:
scala> trait DummyUser extends User {
| override def name: String = "foo"
| }
defined trait DummyUser
scala> trait Right extends Tweeter with User {
| val canDo = name
| }
defined trait Right
scala> trait RightAgain extends Tweeter with DummyUser {
| val canDo = name
| }
defined trait RightAgain
使用Right，可以满足混合用户的需求。然而，上面提到的第二个需求没有得到满足:实现User的负担仍然留给了扩展Right的类/特征。
使用RightAgain，这两个需求都得到了满足。提供了一个User和一个User的实现。
要了解更多实际用例，请参阅本回答开头的链接!希望你们现在明白了。
其他回答
它主要用于依赖注入，例如在饼模式中。有一篇很棒的文章介绍了Scala中许多不同形式的依赖注入，包括饼模式。如果你谷歌“蛋糕模式和Scala”，你会得到很多链接，包括演示文稿和视频。现在，这里是另一个问题的链接。
现在，关于自我类型和扩展特质之间的区别，这很简单。如果你说B扩展了A，那么B就是A。当你使用自类型时，B需要一个A。用自类型创建了两个特定的需求:
如果B被扩展了，那么你就需要加入A。 当一个具体的类最终扩展/混合这些特征时，某些类/特征必须实现a。
考虑以下例子:
scala> trait User { def name: String }
defined trait User
scala> trait Tweeter {
| user: User =>
| def tweet(msg: String) = println(s"$name: $msg")
| }
defined trait Tweeter
scala> trait Wrong extends Tweeter {
| def noCanDo = name
| }
<console>:9: error: illegal inheritance;
self-type Wrong does not conform to Tweeter's selftype Tweeter with User
trait Wrong extends Tweeter {
^
<console>:10: error: not found: value name
def noCanDo = name
^
如果Tweeter是User的子类，就不会出现错误。在上面的代码中，无论何时使用Tweeter，我们都需要一个User，但是User没有提供给Wrong，所以我们得到了一个错误。现在，上面的代码仍然在范围内，考虑:
scala> trait DummyUser extends User {
| override def name: String = "foo"
| }
defined trait DummyUser
scala> trait Right extends Tweeter with User {
| val canDo = name
| }
defined trait Right
scala> trait RightAgain extends Tweeter with DummyUser {
| val canDo = name
| }
defined trait RightAgain
使用Right，可以满足混合用户的需求。然而，上面提到的第二个需求没有得到满足:实现User的负担仍然留给了扩展Right的类/特征。
使用RightAgain，这两个需求都得到了满足。提供了一个User和一个User的实现。
要了解更多实际用例，请参阅本回答开头的链接!希望你们现在明白了。
Self类型允许您定义循环依赖关系。例如，你可以这样做:
trait A { self: B => }
trait B { self: A => }
使用extends的继承不允许这样。试一试:
trait A extends B
trait B extends A
error: illegal cyclic reference involving trait A
在Odersky的书中，第33.5节(创建电子表格UI章节)提到:
在电子表格示例中，类Model继承自Evaluator和 从而获得其评价方法。同学们，走另一条路 Evaluator将自身类型定义为Model，如下所示:
package org.stairwaybook.scells
trait Evaluator { this: Model => ...
trait A { def x = 1 }
trait B extends A { override def x = super.x * 5 }
trait C1 extends B { override def x = 2 }
trait C2 extends A { this: B => override def x = 2}
// 1.
println((new C1 with B).x) // 2
println((new C2 with B).x) // 10
// 2.
trait X {
type SomeA <: A
trait Inner1 { this: SomeA => } // compiles ok
trait Inner2 extends SomeA {} // doesn't compile
}
让我们从周期依赖开始。
trait A {
selfA: B =>
def fa: Int }
trait B {
selfB: A =>
def fb: String }
然而，这个解决方案的模块化并不像它看起来那么好，因为你可以像这样重写自我类型:
trait A1 extends A {
selfA1: B =>
override def fb = "B's String" }
trait B1 extends B {
selfB1: A =>
override def fa = "A's String" }
val myObj = new A1 with B1
但是，如果重写了self类型的成员，就失去了对原始成员的访问权，仍然可以通过super using继承访问原始成员。因此，通过使用继承真正获得的是:
trait AB {
def fa: String
def fb: String }
trait A1 extends AB
{ override def fa = "A's String" }
trait B1 extends AB
{ override def fb = "B's String" }
val myObj = new A1 with B1
现在我不能说我已经理解了饼模式的所有微妙之处，但是我突然意识到，加强模块化的主要方法是通过组合而不是继承或自我类型。
继承版本更短，但我更喜欢继承而不是自我类型的主要原因是，我发现对自我类型进行正确的初始化顺序要棘手得多。然而，有些事情你可以用自我类型做，而不能用继承做。自我类型可以使用类型，而继承需要一个trait或类，如下所示:
trait Outer
{ type T1 }
trait S1
{ selfS1: Outer#T1 => } //Not possible with inheritance.
你甚至可以这样做:
trait TypeBuster
{ this: Int with String => }
尽管您永远无法实例化它。我没有看到任何绝对的理由不能够从一个类型继承，但我肯定认为它将有用的路径构造函数类和特征，因为我们有类型构造函数特征/类。是不幸的
trait InnerA extends Outer#Inner //Doesn't compile
我们有这个:
trait Outer
{ trait Inner }
trait OuterA extends Outer
{ trait InnerA extends Inner }
trait OuterB extends Outer
{ trait InnerB extends Inner }
trait OuterFinal extends OuterA with OuterB
{ val myV = new InnerA with InnerB }
或:
trait Outer
{ trait Inner }
trait InnerA
{this: Outer#Inner =>}
trait InnerB
{this: Outer#Inner =>}
trait OuterFinal extends Outer
{ val myVal = new InnerA with InnerB with Inner }
我们应该更多地理解的一点是，特征可以扩展阶级。感谢David Maclver指出这一点。下面是我自己代码中的一个例子:
class ScnBase extends Frame
abstract class ScnVista[GT <: GeomBase[_ <: TypesD]](geomRI: GT) extends ScnBase with DescripHolder[GT] )
{ val geomR = geomRI }
trait EditScn[GT <: GeomBase[_ <: ScenTypes]] extends ScnVista[GT]
trait ScnVistaCyl[GT <: GeomBase[_ <: ScenTypes]] extends ScnVista[GT]
ScnBase继承自Swing Frame类，因此它可以用作self类型，然后在最后(实例化时)混合使用。然而，val geomR在被继承trait使用之前需要初始化。所以我们需要一个类来强制先行初始化geomR。ScnVista类可以被多个正交特征继承，这些特征本身也可以被继承。使用多个类型参数(泛型)提供了另一种模块化形式。
更新:一个主要的区别是自我类型可以依赖于多个类(我承认这有点极端)。例如，你可以有
class Person {
//...
def name: String = "...";
}
class Expense {
def cost: Int = 123;
}
trait Employee {
this: Person with Expense =>
// ...
def roomNo: Int;
def officeLabel: String = name + "/" + roomNo;
}
这允许将Employee mixin添加到Person和Expense的子类中。当然，只有当费用扩展了人员，或者反之，这才有意义。关键是使用自类型Employee可以独立于它所依赖的类的层次结构。它不关心什么扩展什么-如果你切换了费用和人员的层次结构，你不需要修改雇员。
