Öz-tipler ve sürekli alt sınıflar arasındaki fark nedir?

Bir özellik için kendi kendine tip A:

trait B
trait A { this: B => }

diyor " Ada uzanmayan bir beton sınıfına arada kullanılamaz B" .

Öte yandan, aşağıdakiler:

trait B
trait A extends B

"herhangi bir (somut veya soyut) sınıf karışımının Ada B'de karıştırılacağını " belirtir .

Bu iki ifade aynı anlama gelmiyor mu? Kendiliğinden tip, sadece basit bir derleme zamanı hatası olasılığını yaratmak için kullanılır.

Neyi kaçırıyorum?

Çoğunlukla Kek Kalıbı gibi Bağımlılık Enjeksiyonu için kullanılır . Scala'da Kek Kalıbı da dahil olmak üzere birçok farklı bağımlılık enjeksiyonunu kapsayan harika bir makale var . Google "Kek Kalıbı ve Scala" iseniz, sunumlar ve videolar da dahil olmak üzere birçok bağlantı alırsınız. Şimdilik başka bir soruya bağlantı .

Şimdi, kendi kendine bir tür ile bir özelliği genişletme arasındaki farkın ne olduğu konusunda, bu basittir. Eğer derseniz B extends A, o B zaman bir A. Eğer kendi kendine türlerini kullanırken, B gerektirir bir A. Öz türlerle oluşturulan iki özel gereksinim vardır:

1. Eğer Buzatılır, o zaman konum gerekli karıştırmak-in bir A.
2. Somut bir sınıf nihayet bu özellikleri genişlettiğinde / karıştığında, bazı sınıf / özelliklerin uygulanması gerekir A.

Aşağıdaki örnekleri düşünün:

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
                       ^

Eğer Tweeterbir alt sınıf Userolsaydı, hata olmazdı. Yukarıdaki kodda, biz gerekli bir Userzaman Tweeterkullanılır ancak, Usersağlanan değildi Wrongbiz bir hata var bu yüzden. Şimdi, yukarıdaki kod hala kapsamdayken şunları göz önünde bulundurun:

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

İle Rightkarıştırmak için gereksinim Userkarşılanır. Bununla birlikte, yukarıda belirtilen ikinci gereklilik karşılanmamıştır: uygulama yükü, Userdevam eden sınıflar / özellikler için hala devam etmektedir Right.

İle RightAgainher iki gereksinimleri karşılanır. A Userve bir uygulaması Usersağlanmıştır.

Daha pratik kullanım örnekleri için lütfen bu cevabın başındaki bağlantılara bakınız! Ama, umarım şimdi anlarsın.

Kendini türleri döngüsel bağımlılıkları tanımlamanızı sağlar. Örneğin, bunu başarabilirsiniz:

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

Kullanarak miras extendsbuna izin vermez. Deneyin:

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

Odersky kitabında, bahsettiği bölüm 33.5'e (Elektronik tablo kullanıcı arayüzü oluşturma) bakın:

Elektronik tablo örneğinde, sınıf Modeli Değerlendiriciden miras alır ve böylece değerlendirme yöntemine erişim kazanır. Diğer taraftan, sınıf Değerlendiricisi kendi türünü Model olarak tanımlar, şöyle:

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

Bu yardımcı olur umarım.

Diğer bir fark, kendi tiplerinin sınıf dışı tipler belirleyebilmeleridir. Örneğin

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

Buradaki öz tip yapısal bir tiptir. Etkisi, Foo'da karışan her şeyin arg-no "kapat" yöntemi döndüren bir birim uygulaması gerektiğini söylemek. Bu, ördek yazma için güvenli karışımlara izin verir.

Bölüm 2.3 Martin Odersky'nin orijinal Scala makalesi Ölçeklendirilebilir Bileşen Soyutlamalarının "Selftype Ek Açıklamaları" aslında selfin türünün mixin kompozisyonunun ötesindeki amacını çok iyi açıklamaktadır: bir sınıfı soyut bir türle ilişkilendirmenin alternatif bir yolunu sağlamak.

Makalede verilen örnek aşağıdaki gibiydi ve zarif bir alt sınıf muhabirine sahip görünmüyor:

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

Bahsedilmeyen başka bir şey: öz-tipler gerekli sınıfın hiyerarşisinin bir parçası olmadığından, özellikle kapalı bir hiyerarşiye karşı tam olarak eşleştiğinizde, desen eşleşmesinden hariç tutulabilirler. Bu, aşağıdaki gibi dikey davranışları modellemek istediğinizde kullanışlıdır:

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

TL; diğer cevapların DR özeti:

• Genişlettiğiniz türler kalıtsal türlere maruz kalır, ancak öz türler

  örneğin: class Cow { this: FourStomachs }yalnızca geviş getiren hayvanların kullanabileceği yöntemleri kullanmanızı sağlar digestGrass. Bununla birlikte, İnek'i genişleten özelliklerin böyle bir ayrıcalığı olmayacaktır. Öte yandan, herkese açık class Cow extends FourStomachsolacaktır .digestGrassextends Cow

• kendiliğinden türler döngüsel bağımlılıklara izin verir, diğer türleri genişletmez

Döngüsel bağımlılıkla başlayalım.

trait A {
  selfA: B =>
  def fa: Int }

trait B {
  selfB: A =>
  def fb: String }

Ancak, bu çözümün modülerliği ilk göründüğü kadar büyük değildir, çünkü kendiliğinden türleri geçersiz kılabilirsiniz:

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

Kendi türünde bir üyeyi geçersiz kılarsanız, orijinal üyeye erişiminizi kaybedersiniz, buna yine de miras kullanarak süper erişim yoluyla erişebilirsiniz. Yani kalıtım kullanarak gerçekten kazanılan şey:

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

Şimdi kek kalıbının tüm inceliklerini anlayabildiğimi iddia edemem, ancak modülerliği güçlendirmenin ana yönteminin miras veya kendinden türlerden ziyade kompozisyon yoluyla olması bana çarpıcı geliyor.

Kalıtım sürümü daha kısadır, ancak kendi türlerine göre kalıtımı tercih etmemin temel nedeni, kendi kendine türlerle başlatma sırasını doğru almanın çok daha zor olduğunu görmemdir. Ancak, kalıtımla yapamayacağınız öz türlerle yapabileceğiniz bazı şeyler vardır. Kendi kendine türler bir tür kullanabilirken, kalıtım aşağıdaki gibi bir özellik veya sınıf gerektirir:

trait Outer
{ type T1 }     
trait S1
{ selfS1: Outer#T1 => } //Not possible with inheritance.

Hatta şunları yapabilirsiniz:

trait TypeBuster
{ this: Int with String => }

Buna rağmen asla başaramayacaksınız. Bir türden miras kalmamak için kesin bir neden görmüyorum, ancak kesinlikle tür yapıcı sınıfları / sınıflarımız olduğu için yol yapıcı sınıfları ve özelliklerine sahip olmanın yararlı olacağını hissediyorum. Ne yazık ki

trait InnerA extends Outer#Inner //Doesn't compile

Bizde bu var:

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 }

Veya bu:

  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 }

Daha fazla empati edilmesi gereken bir nokta, özelliklerin sınıfları genişletebilmesidir. David Maclver'e bunu işaret ettiği için teşekkürler. İşte kendi kodumdan bir örnek:

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]

ScnBaseSwing Frame sınıfından miras alır , bu nedenle kendi kendine bir tür olarak kullanılabilir ve daha sonra sonunda karıştırılabilir (örnekleme sırasında). Ancak, val geomRözellikler devralınarak kullanılmadan önce başlatılması gerekir. Bu yüzden önceden başlatılmasını sağlamak için bir sınıfa ihtiyacımız var geomR. Sınıf ScnVistadaha sonra kendileri miras alınabilecek birden çok dikey özellikten miras alınabilir. Çoklu tip parametreleri (jenerikler) kullanmak alternatif bir modülerlik biçimi sunar.

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
}

Kendi kendine bir tür, bir özellikte hangi türlerin karışmasına izin verileceğini belirlemenizi sağlar. Örneğin, kendi türünde bir özelliğiniz varsa Closeable, bu özellik, onu karıştırmasına izin verilen tek şeyin Closeablearabirimi uygulaması gerektiğini bilir .

Güncelleme: Temel fark, kendi tiplerinin birden fazla sınıfa bağlı olabileceğidir (bu biraz köşe durum olduğunu itiraf ediyorum). Örneğin,

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

Bu, Employeemixin'i Personve alt sınıfı olan herhangi bir şeye eklemenizi sağlar Expense. Tabi ki, bu anlamlıdır Expenseuzanır Personya da tam tersi. Mesele şu ki, öz-tipler kullanmak Employeebağımlı olduğu sınıfların hiyerarşisinden bağımsız olabilir. Neyin neyi genişlettiği umurumda değil - Expensevs hiyerarşisini Persondeğiştirirseniz, değiştirmeniz gerekmez Employee.

ilk durumda, B'nin bir alt-özelliği veya alt-sınıfı, A'nın kullandığı her şeye karışabilir. Dolayısıyla B, soyut bir özellik olabilir.