В чем разница между самотипами и подклассами черт?

Он преимущественно используется для внедрения зависимостей, например, в шаблоне торта. Существует отличная статья, охватывающая множество различных форм внедрения зависимостей в Scala. , включая выкройку для торта. Если вы погуглите "Cake Pattern and Scala", вы получите множество ссылок, включая презентации и видео. А пока вот ссылка на другой вопрос.

Теперь, что касается разницы между самотипом и расширением черты, это просто. Если вы говорите B extends A, тогда B A. При использовании самотипов B требуется A. Есть два конкретных требования, которые создаются с помощью самотипов:

1. Если B расширен, вам требуется добавить A.
2. Когда конкретный класс, наконец, расширяет / смешивает эти черты, какой-то класс / черта должен реализовывать 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, ошибки не было бы. В приведенном выше коде мы требовали User всякий раз, когда используется Tweeter, однако 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. Однако второе требование, упомянутое выше, не выполняется: бремя реализации User все еще остается для классов / признаков, которые расширяют Right.

С RightAgain удовлетворяются оба требования. Предоставляются User и реализация User.

Для более практических примеров использования см. Ссылки в начале этого ответа! Но, надеюсь, теперь вы это поняли.

Собственные типы позволяют определять циклические зависимости. Например, вы можете добиться этого:

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

Наследование с использованием extends этого не позволяет. Пытаться:

trait A extends B
trait B extends A
error:  illegal cyclic reference involving trait A

В книге Одерского посмотрите раздел 33.5 (Глава Создание пользовательского интерфейса электронной таблицы), где упоминается:

В примере с электронной таблицей класс Model наследуется от Evaluator и, таким образом, получает доступ к его методу оценки. Чтобы пойти другим путем, класс Evaluator определяет свой собственный тип как Model, например:

package org.stairwaybook.scells
trait Evaluator { this: Model => ...

Надеюсь это поможет.

Еще одно отличие состоит в том, что самотипы могут указывать неклассовые типы. Например

trait Foo{
   this: { def close:Unit} => 
   ...
}

Самотип здесь - это структурный тип. Эффект состоит в том, чтобы сказать, что все, что смешивается в Foo, должно реализовывать блок, возвращающий метод "close" без аргументов. Это позволяет создавать безопасные миксины для утиного набора.

Еще одна вещь, о которой не упоминалось: поскольку самотипы не являются частью иерархии требуемого класса, они могут быть исключены из сопоставления с образцом, особенно когда вы полностью сопоставляете запечатанную иерархию. Это удобно, если вы хотите смоделировать ортогональное поведение, например:

sealed trait Person
trait Student extends Person
trait Teacher extends Person
trait Adult { this : Person => } // orthogonal to its condition

val p : Person = new Student {}
p match {
  case s : Student => println("a student")
  case t : Teacher => println("a teacher")
} // that's it we're exhaustive

Раздел 2.3 «Самотипные аннотации» оригинальной статьи Мартина Одерски по Scala Масштабируемые абстракции компонентов на самом деле очень хорошо объясняет цель selftype, выходящую за рамки композиции миксина: предоставить альтернативный способ связывания класса с абстрактным типом.

abstract class Graph {
  type Node <: BaseNode;
  class BaseNode {
    self: Node =>
    def connectWith(n: Node): Edge =
      new Edge(self, n);
  }
  class Edge(from: Node, to: Node) {
    def source() = from;
    def target() = to;
  }
}

class LabeledGraph extends Graph {
  class Node(label: String) extends BaseNode {
    def getLabel: String = label;
    def self: Node = this;
  }
}

TL; DR резюме других ответов:

• Расширяемые типы доступны для унаследованных типов, но самотипы - нет.

  например: class Cow { this: FourStomachs } позволяет использовать методы, доступные только жвачным животным, такие как digestGrass. Однако черты, расширяющие Cow, не будут иметь таких привилегий. С другой стороны, class Cow extends FourStomachs раскроет digestGrass всем, кто extends Cow.

• самотипы допускают циклические зависимости, расширение других типов не допускает

Начнем с циклической зависимости.

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

Хотя, если вы переопределяете член собственного типа, вы теряете доступ к исходному члену, к которому по-прежнему можно получить доступ через супер с помощью наследования. Итак, что действительно дает использование наследования:

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 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 }

Еще один момент, которому следует сопереживать, - это то, что черты могут расширять классы. Спасибо Дэвиду Маклверу за указание на это. Вот пример из моего собственного кода:

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, поэтому его можно использовать как самостоятельный тип а затем подмешивают в конце (при создании экземпляра). Однако val geomR необходимо инициализировать, прежде чем он будет использоваться путем наследования признаков. Итак, нам нужен класс для принудительной предварительной инициализации geomR. Затем класс ScnVista может быть унаследован от нескольких ортогональных признаков, от которых могут быть унаследованы сами. Использование нескольких параметров типа (обобщенных) предлагает альтернативную форму модульности.

Собственный тип позволяет указать, какие типы разрешено смешивать с признаками. Например, если у вас есть черта с собственным типом Closeable, то эта черта знает, что единственные вещи, которым разрешено смешивать ее, должны реализовывать интерфейс Closeable.

Обновление: принципиальное отличие состоит в том, что самотипы могут зависеть от нескольких классов (я допускаю, что это угловой случай). Например, у вас может быть

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 только ко всему, что является подклассом Person и Expense. Конечно, это имеет смысл только в том случае, если Expense расширяет Person или наоборот. Дело в том, что использование self-типов Employee может быть независимым от иерархии классов, от которых оно зависит. Его не волнует, что что расширяет - если вы переключаете иерархию Expense на Person, вам не нужно изменять Employee.

в первом случае суб-признак или подкласс B может быть смешан с любым использованием A. Таким образом, B может быть абстрактным признаком.