Ullrich: Die Seite wurde neu angelegt: „== Reihenfolge der Methoden-Ausführung == Normalerweise sollte die Reihenfolge in der die Modifier-Methoden aufgerufen werden keine Rolle spielen. Sofern das…“

2021-04-12T17:30:27Z

Die Seite wurde neu angelegt: „== Reihenfolge der Methoden-Ausführung == Normalerweise sollte die Reihenfolge in der die Modifier-Methoden aufgerufen werden keine Rolle spielen. Sofern das…“

Neue Seite

== Reihenfolge der Methoden-Ausführung ==
Normalerweise sollte die Reihenfolge in der die Modifier-Methoden aufgerufen werden keine Rolle spielen.
Sofern das eine Frage der Lesbarkeit ist -- so sollte zuerst die Straße und dann die Hausnummer angegeben werden --
läßt sich das in der Reegel organisatorisch -- also per Handbuch -- steuern lassen, falls es sich nicht (wie bei der Hausnummer)
von selbst regelt.

Man kann das Problem zur Laufzeit entweder mit Prüfungen und Exceptions behandeln und dabei das Risiko eingehen damit
in die Produktion zu gehen wenn die Tests lückenhaft sind. Falls ein Modifier auf die Erfassung der Daten durch einen anderen
Modifier angewiesen ist, kann man das Problem mit Buffering und verzögerter Auswertung umgehen (-> Beispiel??).

Wäre aber nicht eine Lösung wünschenswert, die Probleme zur Compile-Zeit erkennt und es damit unmöglich macht, daß diese
in die Produktion gelangen? Im Prinzip ja, leider gehen solche Maßnahmen in der Regel mit erhöhtem Aufwand einher; man tut
also gut daran genau zu überlegen wann sich der Aufwand lohnt.

== Interfaces, Interfaces ==
Eine relativ komfortable Lösung bieten Interfaces, sor allem deshalb, weil man sie ''nachträglich'' hinzufügen kann.
Wir nehmen einfach das obige Beispiel und bauen eine einfachen Builder:
{{java|code=
public class AdressBuilder {
Adresse adr = new Adresse();

public static AdressBuilder neu() {
return new AdressBuilder();
}

public AdressBuilder withStrasse(String strasse) {
adr.setStrasse(strasse)
return this;
}

public AdressBuilder withHausnummer(int nr) {
adr.setHausnummer(nr);
return this;
}

public Adresse get() {
return adr;
}
}
}}
Bei der Verwendung des Builders können wir eine Reihe von unerwünschten Dinge treiben:
* die Modifier in beliebiger Reihenfolge aufrufen
* den Aufruf eines Modifiers auslassen
* einen Modifier mehrfach aufrufen
Jede der drei Situationen läßt sich zur Compile-Zeit verhindern, indem wir drei Interfaces einführen
und über diese die Reihenfolge steuern. Zur Verdeutlichung -- und zur vereinfachung -- numerieren
wir die Interfaces einfach durch. Wir beginnen mit dem ersten Interface für die Methode {{java|withStrasse}}:
{{java|code=
public interface First {
Second strasse(String strasse);
}
}}
Das Interface {{java|First}} -- wie das in den Builder eingebaut wird, sehen wir nachher -- erlaubt ausschließlich die Angabe der Straße.
Anschließend geht's weiter mit dem Interface {{java|Second}}:
{{java|code=
public interface Second {
Finish hausnummer(int nummer);
}
}}
das -- ausschließlich -- die Angabe der Hausnummer erlaubt. Danach könnten in dieser Vorgehensweise weitere Interfaces folgen,
für unser Beispiel ist die Reise vorbei und wir enden mit dem Interface {{java|Finish}}:
{{java|code=
public interface Finish {
Adresse get();
}
}}
das nur noch den Aufruf der Generator-Methode erlaubt. Wir halten schonmal fest: Für die Festlegung der
Reihenfolge von ''n'' Methoden benötigen wir ''n + 1'' (winzige) Interfaces. Bauen wir die Interfaces nun in unseren Builder ein:
{{java|code=
public class AdressBuilder implements First, Second, Finish {
Adresse adr = new Adresse();

public static First neu() {
return new AdressBuilder();
}

@Override
public AdressBuilder withStrasse(String strasse) {
adr.setStrasse(strasse)
return this;
}

@Override
public AdressBuilder withHausnummer(int nr) {
adr.setHausnummer(nr);
return this;
}

@Override
public Adresse get() {
return adr;
}
}}}
Wir haben am Builder tatsächlich nur zwei Änderungen vorgenommen:

Zunächst weisen wir den Builder n, die drei Interfaces zu implementieren.
In der Folge erhalten die Methoden die Annotation {{java|@Override}}.

Die einzige Stelle an der eines der Interfaces -- das erste -- eingetragen werden muß ist an der
Creation-Methode. Wir haben hierfür eine statische Methoden {{java|neu}} definiert, denn aus offensichtlichem Grunde
funktioniert die Interface-Lösung nicht, wenn Konstruktoren verwendet werden. Dadurch wird erreicht,
daß zu Anfang nur die Methode {{java|withStrasse}} zur Verfügung steht, der Anfang der Kette.

Wie die Kette funktionert läßt sich am einfachsten in der IDE ausprobieren. Man tippt die Folge
{{java| code=
AdressBuilder.neu().strasse("").hausnummer(0).get();
}}
ein und schaut sich nach jedem Punkt die möglichen anwendbaren Methoden an. Neben den unvermeidlichen
{{java|Object}}-Methoden steht immer nur eine Methode des {{java|AdressBuilder}} zur Auswahl.

=== Optionale Aufrufe ===
Bis hierher ist der Aufruf ''jeder'' der Builder-Methoden zwingend erforderlich.
Nehmen wir an, die Angabe der Hausnummer sei optional und die entsprechende Methode soll übersprungen werden können.
Dazu müssen wir dem entsprechenden Interface ({{java|Second}}) die zusätzliche Möglichkeit geben die Methode {{java|get}} aufzurufen.
Das können wir so machen:
{{java|code=
public interface First{
Finish hausnummer(int nummer);
Adresse get();
}
}}
Damit implementiert die Methode {{java|get}} im {{java|AdressBuilder}} nun zwei Interfaces.
Nachteil dieser Lösung ist, daß die beiden Interfaces synchron gehalten werden müssen. Das iat
normalerweise kein Problem, weil sich der Typ des Builder-Generats in der Regel nicht ändert.
Aber es dupliziert eine Zeile und für jede optionale Modifier-Methode müssen wir die Zeile wiederholen.

Hier also die Alternative. Dafür modifizieren wir das Interface {{java|First}}:
{{java|code=
public interface First {
<T extends Second & Finish> T strasse(String strasse);
}
}}
Statt im Interface {{java|Second}} anzugeben daß das Interface übersprungen werden kann,
geben wir nun an der Methode {{java|withStrasse}} an, welche Interfaces im Anschluß angewandt werden können.
Ein feiner aber wichtiger Unterschied im Design.

Java bietet uns hier durch die Forderung der Typ {{java|T}} müsse ''zwei'' Interfaces implementieren
eine Alternative zur nicht vorhandenen Mehrfachvererbung. Die Implementierung der Methode muß ein Objekt
im Ergebnis liefern, das ''beide'' Interfaces implementiert. {{java|AdressBuilder}} tut das:
{{java|code=
public class AdressBuilder implements First, Second, Finish {
...
@Override
public AdressBuilder withStrasse(String strasse) {
adr.setStrasse(strasse)
return this;
}
}}
Der Compiler sieht dabei allerdings ein Problem und warnt uns davor, daß hier eine ungeprüfter Typ-Konversion
stattfindet obwohl das offensichtlich kein Problem darstellt...

Den Effekt kann man in der IDE wieder sehr schön nachvollziehen.

== Alternativen ==
Anstelle der Straße möchten wir gerne ein Postfach angeben können.
In diesem Falle sind weder Straße noch Hausnummer sinnvoll. Dazu erweitern wir zunächst den Builder um
eine Modifier-Methode:
{{java|code=
@Override
public AdressBuilder withPostfach(int postfach) {
adr.setPostfach(postfach);
return this;
}
}}
Die IDE wird dann freundlicherweise das Interface {{java|First}} für uns erweitern und wir müssen nur die Signatur anpassen:
{{java|code=
Finish withPostfach(int postfach);
}}
Da hinter der Hausnummer nichts mehr kommt, gehen wir hier gleich zur Generator-Methode -- sprich zu Interface {{java|Finish}} über.

Die Verweendung eines Interface anstelle der Generator-Methode verschafft uns hier noch einen weiteren Vorteil.
Wenn wir nun eine weitere Modifier-Methode -- etwa für den Ort -- mit einem weiteren Interface einführen,
schiebt sich eine weitere Ebene zwischen {{java|First}} und die Generator-Methode mit einem weiteren Interface das {{java|Third}} heißen möge.
Dafür brauchen wir dann nur den Ergebnis-Typ der {{java|withPostfach}}-Methode auf {{java|Third}} zu ändern.
Wir gewinnen also Einheitlichkeit und damit Änderungsfreundlichkeit.

== Ausblick ==
Abschließend stellt sich die Frage, was für Strukturen wir auf diese Weise modellieren können?
Ohne den formalen Beweis zu erbringen liegt die Vermutung nahe, daß jede Methoden-Kette die sich als endlicher
Automat darstellen läßt mit Hilfe der Interface-Methode modellieren läßt. Die Knoten des Automaten bilden die Interfaces
und die Kanten die Modifier-Methoden.
=== was nicht geht ===
Was uns zu der Frage nach den Grenzen der Methode führt. In der Gruppe Straße/Postfach haben wir eine Alternative programmiert.
Wollten wir in der Gruppe A/B zusätzlich die Variante "A und B" zulassen, müssen wir das über ein separates Interface machen.
Andernfalls müssen wir entweder die Variante "weder A noch B" oder die Mehrfach-Anwendung von A bzw. B zulassen.

Abgrenzung zu kontextfreien Sprachen... Folgen... Klammerungs-Äquivalent geht nicht

Builder mit Interfaces (Draft) - Versionsgeschichte

Ullrich: Die Seite wurde neu angelegt: „== Reihenfolge der Methoden-Ausführung == Normalerweise sollte die Reihenfolge in der die Modifier-Methoden aufgerufen werden keine Rolle spielen. Sofern das…“