Kurzer Weg zur Durchsetzung der Fabrik in Scala

Question

Nehmen wir an, wir haben eine Eigenschaft T. Was ist der beste Weg, das zu erreichen, folgende:

• Jeder, der eine Implementierung von T schreibt sollte eine Möglichkeit zu schaffen gezwungen werden, die eine parameterfreie Initialisierung von T erlaubt, dh wir wahrscheinlich die Umsetzung durchzusetzen eine konfigurierbare Fabrik.
• Alle Logik/Daten, die nur von den tatsächlichen Initialisierungsparametern (einer bestimmten Implementierung A von T) abhängen, sollten zentral gehandhabt/gespeichert werden, sollten aber in der Fabrik und A verfügbar sein.

Die einfachste/prägnante Art und Weise sehe ich (ungefähr) zu erreichen, wäre ein Merkmal für eine Fabrik und Link hinzufügen T zu diesem Werk:

trait T { 
    val factory: TFactory 
} 
trait TFactory { 
    def build(): T 
    val description: String // example for logic/data that only depend on the parameters 
} 

// example implementation: 
class A(val factory: AFactory, paramA: Int, paramB: Int, paramC: Int) extends T 

class AFactory(paramA: Int, paramB: Int, paramC: Int) extends TFactory { 
    def build = new A(this, paramA, paramB, paramC) 
    val description = f"$paramA $paramB $paramC" 
} 

Offensichtlich ist diese „erzwingt nicht wirklich "Die Implementierung einer Fabrik (solange es eine alternative Implementierung gibt) und offensichtlich ist es möglich, Instanziierungen von A zu generieren, die mit einem" falschen "TFactory verknüpft sind. Was ich an diesem Ansatz auch nicht mag, ist die Wiederholung der Initialisierungsparameter. Ich erstelle oft noch eine Klasse AParams, die wiederum alle Parameter umschließt (zum Beispiel um das Hinzufügen neuer Parameter zu erleichtern). Somit habe ich drei Klassen, die für dieses einfache Problem eine Menge Standard sind.

Meine Frage ist, ob es einen (vielleicht völlig) anderen Ansatz gibt, der dieselben primären Ziele erreicht, aber prägnanter ist?

Answer 1

Ich bin mir nicht ganz sicher, ob ich die volle Absicht Ihrer Anforderungen bekomme, aber was halten Sie von diesem Verhalten?

trait TFactory{ 
    def build():T 
    val description:String 
} 

trait T extends TFactory 

//can't declare A without build and not make it abstract 
class A(paramA: Int, paramB: Int, paramC: Int) extends T { 
    def build = new A(paramA, paramB, paramC) 
    val description = f"$paramA $paramB $paramC"  
} 

val a1 = new A(1, 4, 5) 
val a2 = a1.build() 

//We can give ourselves as a factory to something that expects TFactory 
val factory:TFactory = a1 
val a_new = factory.build() 

//More likely we can just give our build method 
def func(f:()=>T) = { 
    val new_t = f() 
    new_t 
} 
val a_newer = func(a1.build) 


println(a1 +": " + a1.description) 
println(a2 +": " + a2.description) 
println(a_new +": " + a_new.description) 
println(a_newer +": " + a_newer.description) 

Ausgang:

Main$$anon$1$A@69267649: 1 4 5 
Main$$anon$1$A@69b1fbf4: 1 4 5 
Main$$anon$1$A@24148662: 1 4 5 
Main$$anon$1$A@3f829e6f: 1 4 5 

Answer 2

einen Darstellungsart Parameter hinzufügen:

trait Factory[Prod] { 
    def build(): Prod 
} 

trait Prod[Repr] { 
    def factory: Factory[Repr] 
} 

Oder, wenn Sie wollen "erzwingen", dass der Typ gleich bleibt (ich würde das nicht tun Wenn Sie nichts daraus gewinnen):

trait Prod[Repr <: Prod[Repr]] { 
    def factory: Factory[Repr] 
} 

Dann:

case class AConfig(a: Int, b: Int) 

case class A(config: AConfig) extends Prod[A] { 
    def factory = AFactory(config) 
} 

case class AFactory(config: AConfig) extends Factory[A] { 
    def build() = A(config) 
} 

val f0 = AFactory(AConfig(1, 2)) 
val p0 = f0.build() 
val f1 = p0.factory 
val p1 = f1.build() 
assert(p0 == p1)