in Bridge Design Pattern zusätzliche Funktionalität als callback verdeckt übergeben

[MB]

moin,

Im Kontext Design Patterns Bridge:

• Ich habe eine Klassen Array eines bestimmten Typs (z.B. Validator)
• Per instanziierung der Klasse ReferedAbstraction (z.B. Builder) werden diese Validatoren in einem Array rein geladen, Anzahl unabhängig.

class Builder {

  private $container = [];

  private $validators = [];

  public function __construct() {
    $this->validators = [
      'foo' => new FooValidator,
      'bar' => new BarValidator,
      'qax' => new QaxValidator
    ];
  }

  // ...
}

• die Validatoren müssen die ConcreteImplementator intern validieren
• diese Validatoren müssen dann zwangläufig bei jedem Aufruf eines ConcreteImplementator (z.B. Construction)s "verdeckt" übergeben werden.

class AbstractConstruction {

  private $validator;
  
  private $params;
  
  public function setValidator( array $validators ) : void {
    $this->validators = $validators;
  }

  public function __toString() : string {
    return $this->params;
  }
}

class Builder {
  
  //...
  
  public function call( ConstructionInterface $c ) : void {
    $this->c->setValidators( $this->validators );
    $this->container[] = $this->c;
  }
  
  // ...
}

die konrete implementierung FooConstruction:

class FooConstruction extends AbstractConstruction {

  public function __construct( string $params ) {
    $this->validators->isValid( $params );
  }
}

Sähe dann in der Art dann so aus

$b = new Builder(); // reinladen der Validatoren im Array bei instanziierung
$b->
  callFoo( new FooConstrution( 'fuz' ) )
  callBar( new BarConstrution( 'buz' ) )
  callQax( new QayConstrution( 'qux' ) )
$b->result();

Frage:

Frisst das nicht soviele system resourcen wenn bei jedem Methoden aufgruf der Builder-Klasse alls Klassen Validatoren übergeben werden damit der Construction eine rauspcken kann, validieren und zurück schicken kann???

StatusQuo

Ich hab zuvor Statische Validatoren genutzt. Da ich aber dieser Builderklasse mehrfach im Runtime verwenden will, brigt die statischen Klassen wenig, es sei den, ich müsste das in einer extrem verschachtelte Kette realisieren. Auch irgend wie nicht inn der Sache. Bridge Pattern sollen Klassen lose und dynamisch gekoppelt sein und nicht starr und fest.

lgmb

[pl]

Frisst das nicht soviele system resourcen wenn bei jedem Methoden aufgruf der Builder-Klasse alls Klassen Validatoren übergeben werden damit der Construction eine rauspcken kann, validieren und zurück schicken kann???

Du übergibtst doch Referenzen. MFG

[MB]

moin,

Frisst das nicht soviele system resourcen wenn bei jedem Methoden aufgruf der Builder-Klasse alls Klassen Validatoren übergeben werden damit der Construction eine rauspcken kann, validieren und zurück schicken kann???

Du übergibtst doch Referenzen. MFG

Ja, Referenz der Instanzen und zwar jedes Mal. Die RefinedAbstraction (sprich hier der FooConstruction) nimmt die Instanz-Gruppe der Validatoren entgegegen und zerstört sie nach dem herraus Picken eines Validators und dem validieren.

Meines erachtens nach, teuer und ein unnötiger Aufwand, für mich starre Kopplung. Ich wollte einfach nur wissen obs da nicht ne performantere Möglichkeit gibt, das anstehende Problem eleganter zu lösen.

lgmb

PS: Ich muss noch dazu sagen, dass es verhältnismäßig wenig Validatoren sind. 0 bis 5 Klassen Validatoren. Kann man das verkraften??? Wenn zukünfig ein größeres Projekt ansteht, mit dem Bridge Design Pattern und ein ähnliches Problem mit extrem vielen übergebenden Klassen (hier die Validatoren) auftritte, wollte ich wissen obs da nicht eleganteren Weg gibt.

[pl]

Fakt ist, daß beim Übergeben von Referenzen keine neuen Ressourcen angelegt werden. Was Deine Befürchtungen hinsichtlich Effizienz betrifft, das kann auch im Entwurfmuster selbst begründet sein. Natürlich ist es unnötig, haufenweise Objekte zu erzeugen und Code zu kompilieren wo für eine spezielle Aufgabe nur ein Bruchteil davon gebraucht wird, das scheint der Nachteil dieses Entwurfsmusters zu sein.

In Deinem Code finden sich übrigens weitere Entwurfsmuster, z.B. Aggregation und Delegation auch bekannt als Dependency Injection was in der Praxis auch völlig normal ist, also daß mehrere Entwurfmuster nebeneinander verbaut werden.

Also schau Dir mal die Factory an. Und auch wie man Code durch Teilung effizienter macht und infolge Auslagerung von Code Redundanzen vermeidet.

MFG

[MB]

moin,

Fakt ist, daß beim Übergeben von Referenzen keine neuen Ressourcen angelegt werden. Was Deine Befürchtungen hinsichtlich Effizienz betrifft, das kann auch im Entwurfmuster selbst begründet sein. Natürlich ist es unnötig, haufenweise Objekte zu erzeugen und Code zu kompilieren wo für eine spezielle Aufgabe nur ein Bruchteil davon gebraucht wird, das scheint der Nachteil dieses Entwurfsmusters zu sein.

Ja

In Deinem Code finden sich übrigens weitere Entwurfsmuster, [...]

ist mir bewusst. Ich habe ein konkretes Beispiel des Bridge Patterns genommen, was Constructor Injection beinhaltet, das mein vorliegende Problem beschreibt.

Also schau Dir mal die Factory an. Und auch wie man Code durch Teilung effizienter macht und infolge Auslagerung von Code Redundanzen vermeidet.

Sry, das ist nich das Problem das ich hier geschildert habe.

lgmb

[pl]

hi,

Also schau Dir mal die Factory an. Und auch wie man Code durch Teilung effizienter macht und infolge Auslagerung von Code Redundanzen vermeidet.

Sry, das ist nich das Problem das ich hier geschildert habe.

Genau das löst Dein Problem! MFG

[pl]

hi MB, ich finde es äußerst unschön und auch sehr schade daß Du meine Antworten mit -1 bewertest. MFG

[JürgenB]

Hallo Rolf,

ich finde es äußerst unschön, das du MB vorwirfst, er habe dich negativ bewertet. Erstens kann er noch nicht negativ bewerten und zweitens gibt es noch andere, die deine Beiträge kritisch sehen.

Gruß
Jürgen

[Rolf B]

Hallo MB,

tut mir leid. Ich habe es jetzt 5 mal gelesen und bin immer noch der Meinung, dass mir deine Frage zu wirr ist, um sie zu verstehen. Ggf. auch zu viele Codefehler enthält.

Insbesondere begreife ich nicht was dein letztes Codebeispiel (mit callFoo, callBar und callQax soll. Da fehlt was, so ist es Syntaxmüll.

Es fehlt auch allgemein was, ich bringe die Brocken nicht zusammen.

Das Bridge Pattern habe ich aber auch noch nicht (bewusst) verwendet und musste mich erst mal einlesen.

Es könnte helfen, wenn du klarer machst, was Abstraktion, was Implementierung ist und wie das Ganze verwendet wird. Und wie callFoo/Bar/Qax mit der call Methode im Builder zusammenhängen (wenn überhaupt). Was das mit $c und $this->c bedeuten soll, verstehe ich auch nicht.

Ich bin auch noch nicht ganz überzeugt, dass das, was du hier Bridge Pattern nennst, auch wirklich eins ist. Ein Builder, der eine Liste von Validatoren intus hat, ist nicht unbedingt eine Bridge.

Rolf

[MB]

moin,

tut mir leid. Ich habe es jetzt 5 mal gelesen und bin immer noch der Meinung, dass mir deine Frage zu wirr ist, um sie zu verstehen. Ggf. auch zu viele Codefehler enthält.

Sorry 😕. Hast du das gelesen was ich @pl geschrieben habe? Ist zwar abstrakter des vorliegenden Problemes aber deutlich - hoffe ich 😕.

Insbesondere begreife ich nicht was dein letztes Codebeispiel (mit callFoo, callBar und callQax soll. Da fehlt was, so ist es Syntaxmüll.

hmm ok verstehe dann ist es besser für dich wenn ich es anstatt callFoo, callBaz, callQax es getConstruction betitle? Es mach keinen uinterstied des Problemes

Es könnte helfen, wenn du klarer machst, was Abstraktion, was Implementierung ist und wie das Ganze verwendet wird.

Builder ist Abstrakt und Construction Klassen sind Implementierungen

Ich bin auch noch nicht ganz überzeugt, dass das, was du hier Bridge Pattern nennst, auch wirklich eins ist.

Das "Konzept" eins Bridge Pattern's soll eine lose Kopplung zweier Hierarchien, Abstraktion und Implementierung, realisieren. Wie man es anstellt ist dem Programmiere überlassen, jedoch sollte man sich an diese Struktur halte um es Bridge Pattern nennen zu dürfen. So habe ich es gelesen und Tutorien angesehen. Ich hab mich bedingt drang gehalten.

Ein Builder, der eine Liste von Validatoren intus hat, ist nicht unbedingt eine Bridge.

In meinem Fall: wenn im Bridge Pattetn eine Kopplung besteht, die durch den Clienten induziert wird, dann kann die designierte Implementation bestimmte funktionalität durch die übergabe nach der Instanziierung übernehmen, was "Nicht" teil des Bridge Pattern-Konzeptes ist.

Das Konzept im Code:

$ra = new RefinedAbstraction( new ConcreteImplementation( [Parameters] ); 

in meinem Fall

$bu = new Builder(
$bu->getConstruction( new FooConstruction( [Parameters] ); 

mit in diesert Kopplung wird - wie schon erwähnt - Funktionalitäten an die Instanz "verdeckt" nach der Instanziierung der konkreten Implementation übergeben, die hier im obigen Beispiel "Nicht" ersichtlich sind.

Ich hoffe wirchlich es ist einigermaßen verständlich 😕. Wenn nicht, dann ist es auch ok. Du sollst wirklich nicht deine Grauen Zellen abtöten, wenn du mein "Erklärungen" ließst. Das ist schon ok 😉.

lgmb

[Rolf B]

Hallo MB,

nein, es wird immer wirrer, vor allem, weil du Construction mal Abstraktion und mal Implementierung nennst. WAS du da eigentlich bezwecken willst, ist nebulös.

Eine Bridge erkenne ich auch nicht.

Egal, es ging dir um Performance. Der Builder soll der Construction zu einem Namen einen Validator liefern. Dafür sollte die Construction aber nicht in einem Array des Builders herum grabbeln, sondern eine Methode des Builders aufrufen. Dann kann der Builder den Validator lazy erzeugen und ggf für die Zukunft cachen.

Rolf

[MB]

moin,

nein, es wird immer wirrer, vor allem, weil du Construction mal Abstraktion und mal Implementierung nennst. WAS du da eigentlich bezwecken willst, ist nebulös.

Keine Stress, is wirklich ok 😉. Meine Ausdruckskraft ist verwirrent wenn es Komplex wird, ich weis und Sorry dafür 😕.

Eine Bridge erkenne ich auch nicht.

Für mich aber 😀. Ich kann mich zweifellos Irren, weil ich hab zum ersten Mal "bewusst" mit Design Patterns garbeitet. Seit gnädig 😀

Egal, es ging dir um Performance. […]

Jo

Der Builder soll der Construction zu einem Namen einen Validator liefern. Dafür sollte die Construction aber nicht in einem Array des Builders herum grabbeln, sondern eine Methode des Builders aufrufen.

nach dem ich diesen Thread geschrieben habe, ist es mir auch aufgefallen das ich das mit Validator Methoden etwas performater lösen kann.

lgmb