MimiPedia - Benutzerbeiträge [de]

Builder:Motivation

2025-02-26T07:28:17Z

Ullrich: /* Fluent Interfaces */

[[Kategorie:Java]]
[[Kategorie:Builder]]
= Motivation =

Ber Begriff "Builder" tritt wohl zum ersten Mal im "Design Patterns"-Buch der Gang of Four auf.
Die Absicht des Builder Pattern wird dort definiert durch:
:Separate the construction of a complex object from its representation 
:so that the same construction process can create different representations

Es geht dort also um die Trennung von Konstruktion und Repräsentation. Ein wesentlicher Aspekt
dabei ist die Anforderung ''verschiedene'' Repräsentationen aus dem Ergebnis des selben
Konstruktionsprozesses zu erzeugen. Als Beispiel führt das Buch die Konstruktion eines Textes an,
der dann in unterschiedliehen Formaten ausgegeben werden kann.

Auch wenn solche Probleme in der Praxis durchaus vorkommen, hat sich der Builder-Begriff davon mittlerweile losgelöst.
Die meisten Beschreibungen verzichten auf den zweiten Aspekt -- die Erzeugung der Repräsentationen --
und beschränken sich auf die Konstruktion. In diesem Sinne solle der Builder auch in diesem Pamphlet verstanden
werden. Es geht also um die Trennung der Konstruktion von der Verarbeitung des erzeugten Objekts.
Dem Builder geht es dabei ausschließlich um die Konstruktion und die Manipulation der Objekt;
was -- insbesondere fachlich -- weiter mit dem Objektgeschieht, interessiert den Builder nicht.

== Paradigmen ==
Sucht man im Web nach dem Begriff "objektorientiert" so findet man allerhand, nur keine Definition;
nicht einmal ein Konsens darüber was OO eigentlich sein soll findet man.
Eine der ersten Sprachen die "Objekte" eingeführt hat, war [https://en.wikipedia.org/wiki/Simula SIMULA-67].
Wie der Name suggeriert, ist SIMULA im Umfeld von software-gestützten Simulationen entstanden in denen mehr oder weniger
selbständige "Dinge" mit einander interagieren. Die Definition von Grady Booth für das objektorienterte Design enstammt
der realen Welt, nicht der Programmierung; die Eigenschaften treffen jedoch auch beide zu. Demnach hat eine Objekt
* eine Identität
* einen (inneren) Zustand
* eine definiertes Verhalten
Das Objekt tackert damit Daten und Funktionen die damit arbeiten zusammen. Objekte "leben" über einen längeren Zeitraum
und verändern sich dabei. Seit dem Aufkommen in den 1990ern ist "Objektorientierung" das führende Paradigma,
tatsächlich zeichnet sich seit einiger Zeit eine Änderung des Trends ab. Massive Parallelität in allen Bereichen -- vom
Prozessor bis zum globalen Web führen immer wieder zu Problemen, weil die Daten im Objekt nicht für den parallelen Zugriff
vorgesehen sind. Auch wenn SOA kein moderner Begriff mehr ist, ist der Service zum Mantra der Gegenwart geworden.
Die Vorstellung eines Ablaufs, der gestartet und beendet wird, Eingaben aufnimmt und daraus ein Ergebnis berechnet;
unabhängig vom Rest der Welt, mit einer Lebensdauer von Millisekunden -- das ist das Gegenteil eines Objekts.

Auch der Builder bricht mit dem OO-Paradigma indem er die Daten von ihrer Manipulation trennt.
Im Grunde genommen läßt sich die Verarbeitung von Daten nicht zufriedenstellend in der OO-Welt abbilden.
Eine Überweisung führt sich nicht selbst aus. Sie ist ein Auftrag, der im Rahmen eines Prozesses ausgeführt wird.
Die Überweisungs-Daten müssen also vom inneren Zustand der Überweisungsmaschine gertrennt werden. Die Maschine
mag ein Objekt sein, die Überweisungsdaten bilden keines; für sie ist das Datenstruktur- oder Datentyp-Modell angemessener.

Folgt man diesem Gedankenm, führt das zum Konzept das typisierten funktionalen Programmiersprachen zugrunde liegt.

== Die integrierte Factory ==
Im Pattern-Buch taucht ''die'' Factory als Pattern nicht auf. Statt dessen giebt es zwei speziellere Pattern
"Abstract Factory" und "Factory Method" deren Definition hier nicht wiederholt weren soll.
Stellen wir uns statt dessen die Frage: Was möchten wir unter einer ''Factory'' verstehen?

Die kürzestmögliche Definition ist:
:Eine Factory ist ein Ding, das Objekte erzeugt.
Meistens handelt es sich da um ein Objekt, es kann aber auch eine Funktion oder eine Methode sein.

Die Parametrisierung bzw. Konfigurierbarkeit zur Erzeugung von Objekten ''unterschiedlicher'' Klassen
ist zwar möglich, aber nicht wesentlich. Dieser Factory-Begriff kann also getrost auf den Builder angewandt
werden: Ein Builder erzeugt Objekte. Die Klasse des Generats kann für einen
Builder variieren, muß -- und tut es im allgemeinen -- aber nicht.

Was den Builder von der landläufigen Vorstellung der Factory -- und der Gof'schen factory method -- unterscheidet,
ist die Tatsache daß beim Builder zur Erzeugung von Objekten mehrere Methoden aufgerufen werden müssen.

== Fluent Interfaces ==
Geprägt wurde der Begriff wohl von Eric Evens; Martin Fowler schreibt darüber 2005 in seinem
[https://martinfowler.com/bliki/FluentInterface.html Blog].
Die Idee dahinter ist, Folgen von Methoden-Aufrufen auf Objekte -- die so typisch sind für imperative Sprachen wie Java -- zu ersetzen durch verkettete Methoden-Aufrufe, die die Struktur einer domain specific languange aufweisen.
Fowlers Beispiel ähnelt nicht zufällig den Buildern wie sie hier beschrieben werden. Im folgenden soll nicht der Artikel nacherzählt werden, vielmehr geht es darum einen Eindruck vom "fluent interface"-Konzept zu geben.

Manchmal werden fluent interfaces auch als Pattern bezeichnet. Das ist -- im ursprünglichen Sinne -- nicht korrekt.
Ihnen liegt keine fachliche Motivation zugrunde und sie dienen nicht der Lösung irgendeiner Problem-Kategorie.
Sie sind ein Design-Konzept für Programmier-Interfaces.

In Java könnte man sich folgenden Code vorstellen:
{{java|code=
Statement s = new select();
Fields f = new Fields();
f.setList(List.of("x", "y", "z));
s.setFields(f);
Table t = new Table("t");
s.setTables(t);
Condition c = new Condition("x = z");
s.setConditions(c)
}}
Man kann -- anstelle der Verwendung lokaler Variablen -- die Objekt-Erzeugung inline durchführen,
aber das macht den Code nicht schöner. Man kommt beim Lesen nicht umhin, den Code sequentiell zu analysieren:
Erzeugt wird ein Statement, dann wird ein "Field"-Objekt erzeugt, das wird dem Statement
hinzugefügt, und so fort. Der Eingeweihte erkennt schnell das SQL-Statement das hier konstruiert wird.

Man kann das -- anlehnend an die SQL-Syntax -- auch in Java anders formulieren:
{{java|code=
Statement s = new Select() //
.fields("x", "y", "z") //
.from(new Table("t")) //
.where(Condition.equals("x", "z"));
}}
Anstelle der von einander unabhängigen Setter definiert die {{java|Select}}-Klasse Methoden, die immer wieder das gleiche
{{java|Select}}-Objekt als Ergebnis liefern. Die DSL die hier definiert wird, entspricht der SQL-Syntax und man kann sich
vorstellen, daß -- wenn die {{java|where}}-Methode entsprechend modelliert wird -- auch die Definition geschachtelter
Select-Statements möglich sind.

Das sind denn auch die beiden Elemente der fluent interfaces, die hier wesentlich sind.
Zunächst einmal das "method chaining": Man versteht darunter, daß die Methoden-Aufrufe nicht in einzelnene Befehlen
geschehen -- wie das bei Verwendung von Settern und lokalen Variablen der Fall ist -- sondern in einer (mehr oder weniger langen)
Kette von aufeinander angewandten Methoden, so daß für die komplette Folge nur ein einziger Befehl
(gewissermaßen ein einziges Semikolon) benötigt wird.

Das zweite Element ist die Schachtelung. Statt Unter-Objekte in lokalen Variablen abzulegen und dort zu manipulieren,
werden sie -- wieder in einer einzigen Methoden-Kette erzeugt und dann direkt als Argumente an Methoden übergeben.
Das ganze Konstrukt erhält dadurch einen eher funktionalen Charakter. Das ist für den "prozeduralen" Java-Hacker
ein eher ungewohntes und damit befremdliches Konzept.

Ich stand der "fluent interface"-Idee von Anfang an skeptisch gegenüber. Solange die dadurch definierte DSL den Charakter einer formalen
Sprache hat -- wie das bei SQL der Fall ist -- die einer eindeutig definierten inneren Logik folgt, giebt es eigentlich kein Problem.
Wenn man aber versucht -- und so wird es vielfach verkauft -- natürliche Sprache darüber nachzubilden wird die Sache schwierig.
Computer-Programme sind formal und lassen keine Unschärfe zu; das Gegenteil ist ein wesentliches Merkmal natürlicher Sprachen.

Wie kann man nun zusammenfassen inwiefern fluent interfaces bei der Builder-Konstruktion bedeutsam sind?

{{quotation|Der Builder verwendet Method Chaining und Schachtelung, um klassische Anweisungsfolgen durch eine DSL zu ersetzen.}}

Dadurch wird einerseits eine bessere Lesbarkeit und eine bessere Verständlichkeit der zugrundeliegenden Semantik erreicht
und andererseits boiler plate code gekapselt, der sonst die die Aufmerksamkeit absaugen würde.

== Separation of Concerns ==
Wie im Abschnitt "Zugriffs-Kontolle" ausführlicher beschrieben wird, bietet der Builder eine Möglichkeit
die Zuständigkeiten über Entities so trennen. Das klingt zunächst einmal etwas merkwürdig; welche Zuständigkeiten
sollte man bei einem Entity -- das selbst keine Logik enthält -- trennen?

Es geht hier um die Trennung von Erzeugung (bzw. Manipulation) des Objekts und dem Zugriff auf den Inhalt.
Die Idee des immutable Objekts ist Java grundsätzlich fremd, sie widerspricht geradezu der eigentlichen Objekt-Idee.
Aber tatsächlich haben unveränderliche Objekte in einer multithreading-Umgebung große Vorteile,
weil sie die Synchronisation stark vereinfachen. Nicht umsonst ist das funktionale Paradigma weiterhin auf dem Vormarsch.

Konsequent durchgezogen, kann das Entity vollständig auf Setter verzichten indem es die Manipulation dem Builder überträgt
und sich darauf beschränken Daten zu halten und herauszugeben.

== Statisch oder dynamisch? ==
Das ist für jede Programmiersprache die -- oder zumindest eine -- Gretchenfrage. Was ist damit gemeint?
Statisch heißt "zur Compile-Zeit", dynamisch -- oder nicht-statisch -- bezeichnet das Gegenstück, nämlich "zur Laufzeit".

Wenn Tony Hoare die Einführung von "null" in ALGOL als "billion Dollar mistake" bezeichnet hat, meinte er damit,
daß die null- oder Ungültigkeitsprüfung optimalerweise zur Compile-Zeit stattfinden sollte. Es giebt mittlerweile
Sprachen, die Konzepte dafür implementieren -- in Java sind sie nur unzulänglich ausgeführt.

Inwiefern betrifft das den Builder? Bei jeder Prüfung muß man sich fragen, wann diese stattfinden soll.
Was ist mit Muß-Werten? Kann man das Vorhandensein zur Compile-Zeit prüfen -- was sicherer wäre -- oder soll man
die Prüfung auf die Laufzeit -- was einfacher wäre -- verlagern? Auf diese spezielle Frage wird später noch eingegangen,
betrachten wir die Frage etwas allgemeiner: "wann statisch, wann dynamisch"?

Die Antwort lautet: -- wie überraschend -- kommt drauf an...

Grundsätzlich kann man sagen: statische Prüfung ist immer aufwändiger als die dynamische. Definiert an einen einfachen
Builder mit mehrereren Konfigurations-Methoden, kann man die Methoden in beliebiger Reihenfolge aufrufen; im einfachsten
Falle sogar mehrfach. Möchte man eine Reihenfolge festlegen, die bereits zur Compile-Zeit eingehalten werden muß ist das
prinzipiell möglich. es erfordert allerdings zusätzliche Klassen und verursacht Aufwand.

Möchte man zur Compile-Zeit sicher sein, daß Muß-Felder gefüllt sind, geht das nur über (häßliche) Konstruktoren und selbst
dann hat man nur eingeschränkte Kontrolle darüber, ob die Felder mit brauchbaren Werten gefüllt sind.

Es bleibt also eine Abschätzung: Lohnt sich der Aufwand -- wenn es denn überhaupt geht?

Der Aldi-Tip: Mach's dynamisch und schreib' viele Unit-Tests.

== Migration/Versionierung ==
Die Separation von Datenspeicherung -- im Entity -- und Manipulation -- im Builder -- macht es einfacher,
zwischen unterschiedlichen Versionen von Entities zu unterscheiden, diese zu erzeugen und Migration von
Daten zwischen Versionen durchzuführen.

Builder:Motivation

2025-02-26T07:26:50Z

Ullrich: /* Fluent Interfaces */

[[Kategorie:Java]]
[[Kategorie:Builder]]
= Motivation =

Ber Begriff "Builder" tritt wohl zum ersten Mal im "Design Patterns"-Buch der Gang of Four auf.
Die Absicht des Builder Pattern wird dort definiert durch:
:Separate the construction of a complex object from its representation 
:so that the same construction process can create different representations

Es geht dort also um die Trennung von Konstruktion und Repräsentation. Ein wesentlicher Aspekt
dabei ist die Anforderung ''verschiedene'' Repräsentationen aus dem Ergebnis des selben
Konstruktionsprozesses zu erzeugen. Als Beispiel führt das Buch die Konstruktion eines Textes an,
der dann in unterschiedliehen Formaten ausgegeben werden kann.

Auch wenn solche Probleme in der Praxis durchaus vorkommen, hat sich der Builder-Begriff davon mittlerweile losgelöst.
Die meisten Beschreibungen verzichten auf den zweiten Aspekt -- die Erzeugung der Repräsentationen --
und beschränken sich auf die Konstruktion. In diesem Sinne solle der Builder auch in diesem Pamphlet verstanden
werden. Es geht also um die Trennung der Konstruktion von der Verarbeitung des erzeugten Objekts.
Dem Builder geht es dabei ausschließlich um die Konstruktion und die Manipulation der Objekt;
was -- insbesondere fachlich -- weiter mit dem Objektgeschieht, interessiert den Builder nicht.

== Paradigmen ==
Sucht man im Web nach dem Begriff "objektorientiert" so findet man allerhand, nur keine Definition;
nicht einmal ein Konsens darüber was OO eigentlich sein soll findet man.
Eine der ersten Sprachen die "Objekte" eingeführt hat, war [https://en.wikipedia.org/wiki/Simula SIMULA-67].
Wie der Name suggeriert, ist SIMULA im Umfeld von software-gestützten Simulationen entstanden in denen mehr oder weniger
selbständige "Dinge" mit einander interagieren. Die Definition von Grady Booth für das objektorienterte Design enstammt
der realen Welt, nicht der Programmierung; die Eigenschaften treffen jedoch auch beide zu. Demnach hat eine Objekt
* eine Identität
* einen (inneren) Zustand
* eine definiertes Verhalten
Das Objekt tackert damit Daten und Funktionen die damit arbeiten zusammen. Objekte "leben" über einen längeren Zeitraum
und verändern sich dabei. Seit dem Aufkommen in den 1990ern ist "Objektorientierung" das führende Paradigma,
tatsächlich zeichnet sich seit einiger Zeit eine Änderung des Trends ab. Massive Parallelität in allen Bereichen -- vom
Prozessor bis zum globalen Web führen immer wieder zu Problemen, weil die Daten im Objekt nicht für den parallelen Zugriff
vorgesehen sind. Auch wenn SOA kein moderner Begriff mehr ist, ist der Service zum Mantra der Gegenwart geworden.
Die Vorstellung eines Ablaufs, der gestartet und beendet wird, Eingaben aufnimmt und daraus ein Ergebnis berechnet;
unabhängig vom Rest der Welt, mit einer Lebensdauer von Millisekunden -- das ist das Gegenteil eines Objekts.

Auch der Builder bricht mit dem OO-Paradigma indem er die Daten von ihrer Manipulation trennt.
Im Grunde genommen läßt sich die Verarbeitung von Daten nicht zufriedenstellend in der OO-Welt abbilden.
Eine Überweisung führt sich nicht selbst aus. Sie ist ein Auftrag, der im Rahmen eines Prozesses ausgeführt wird.
Die Überweisungs-Daten müssen also vom inneren Zustand der Überweisungsmaschine gertrennt werden. Die Maschine
mag ein Objekt sein, die Überweisungsdaten bilden keines; für sie ist das Datenstruktur- oder Datentyp-Modell angemessener.

Folgt man diesem Gedankenm, führt das zum Konzept das typisierten funktionalen Programmiersprachen zugrunde liegt.

== Die integrierte Factory ==
Im Pattern-Buch taucht ''die'' Factory als Pattern nicht auf. Statt dessen giebt es zwei speziellere Pattern
"Abstract Factory" und "Factory Method" deren Definition hier nicht wiederholt weren soll.
Stellen wir uns statt dessen die Frage: Was möchten wir unter einer ''Factory'' verstehen?

Die kürzestmögliche Definition ist:
:Eine Factory ist ein Ding, das Objekte erzeugt.
Meistens handelt es sich da um ein Objekt, es kann aber auch eine Funktion oder eine Methode sein.

Die Parametrisierung bzw. Konfigurierbarkeit zur Erzeugung von Objekten ''unterschiedlicher'' Klassen
ist zwar möglich, aber nicht wesentlich. Dieser Factory-Begriff kann also getrost auf den Builder angewandt
werden: Ein Builder erzeugt Objekte. Die Klasse des Generats kann für einen
Builder variieren, muß -- und tut es im allgemeinen -- aber nicht.

Was den Builder von der landläufigen Vorstellung der Factory -- und der Gof'schen factory method -- unterscheidet,
ist die Tatsache daß beim Builder zur Erzeugung von Objekten mehrere Methoden aufgerufen werden müssen.

== Fluent Interfaces ==
Geprägt wurde der Begriff wohl von Eric Evens; Martin Fowler schreibt darüber 2005 in seinem
[https://martinfowler.com/bliki/FluentInterface.html Blog].
Die Idee dahinter ist, Folgen von Methoden-Aufrufen auf Objekte -- die so typisch sind für imperative Sprachen wie Java -- zu ersetzen durch verkettete Methoden-Aufrufe, die die Struktur einer domain specific languange aufweisen.
Fowlers Beispiel ähnelt nicht zufällig den Buildern wie sie hier beschrieben werden. Im folgenden soll nicht der Artikel nacherzählt werden, vielmehr geht es darum einen Eindruck vom "fluent interface"-Konzept zu geben.

Manchmal werden fluent interfaces auch als Pattern bezeichnet. Das ist -- im ursprünglichen Sinne -- nicht korrekt.
Ihnen liegt keine fachliche Motivation zugrunde und sie dienen nicht der Lösung irgendeiner Problem-Kategorie.
Sie sind ein Design-Konzept für Programmier-Interfaces.

In Java könnte man sich folgenden Code vorstellen:
{{java|code=
Statement s = new select();
Fields f = new Fields("x, y, z");
s.setFields(f);
Tables t = new Tables("t");
s.setTables(t);
Condition c = new Condition("x = z");
s.setConditions(c)
}}
Man kann -- anstelle der Verwendung lokaler Variablen -- die Objekt-Erzeugung inline durchführen,
aber das macht den Code nicht schöner. Man kommt beim Lesen nicht umhin, den Code sequentiell zu analysieren:
Erzeugt wird ein Statement, dann wird ein "Field"-Objekt erzeugt, das wird dem Statement
hinzugefügt, und so fort. Der Eingeweihte erkennt schnell das SQL-Statement das hier konstruiert wird.

Man kann das -- anlehnend an die SQL-Syntax -- auch in Java anders formulieren:
{{java|code=
Statement s = new Select() //
.fields("x", "y", "z") //
.from(new Table("t")) //
.where(Condition.equals("x", "z"));
}}
Anstelle der von einander unabhängigen Setter definiert die {{java|Select}}-Klasse Methoden, die immer wieder das gleiche
{{java|Select}}-Objekt als Ergebnis liefern. Die DSL die hier definiert wird, entspricht der SQL-Syntax und man kann sich
vorstellen, daß -- wenn die {{java|where}}-Methode entsprechend modelliert wird -- auch die Definition geschachtelter
Select-Statements möglich sind.

Das sind denn auch die beiden Elemente der fluent interfaces, die hier wesentlich sind.
Zunächst einmal das "method chaining": Man versteht darunter, daß die Methoden-Aufrufe nicht in einzelnene Befehlen
geschehen -- wie das bei Verwendung von Settern und lokalen Variablen der Fall ist -- sondern in einer (mehr oder weniger langen)
Kette von aufeinander angewandten Methoden, so daß für die komplette Folge nur ein einziger Befehl
(gewissermaßen ein einziges Semikolon) benötigt wird.

Das zweite Element ist die Schachtelung. Statt Unter-Objekte in lokalen Variablen abzulegen und dort zu manipulieren,
werden sie -- wieder in einer einzigen Methoden-Kette erzeugt und dann direkt als Argumente an Methoden übergeben.
Das ganze Konstrukt erhält dadurch einen eher funktionalen Charakter. Das ist für den "prozeduralen" Java-Hacker
ein eher ungewohntes und damit befremdliches Konzept.

Ich stand der "fluent interface"-Idee von Anfang an skeptisch gegenüber. Solange die dadurch definierte DSL den Charakter einer formalen
Sprache hat -- wie das bei SQL der Fall ist -- die einer eindeutig definierten inneren Logik folgt, giebt es eigentlich kein Problem.
Wenn man aber versucht -- und so wird es vielfach verkauft -- natürliche Sprache darüber nachzubilden wird die Sache schwierig.
Computer-Programme sind formal und lassen keine Unschärfe zu; das Gegenteil ist ein wesentliches Merkmal natürlicher Sprachen.

Wie kann man nun zusammenfassen inwiefern fluent interfaces bei der Builder-Konstruktion bedeutsam sind?

{{quotation|Der Builder verwendet Method Chaining und Schachtelung, um klassische Anweisungsfolgen durch eine DSL zu ersetzen.}}

Dadurch wird einerseits eine bessere Lesbarkeit und eine bessere Verständlichkeit der zugrundeliegenden Semantik erreicht
und andererseits boiler plate code gekapselt, der sonst die die Aufmerksamkeit absaugen würde.

== Separation of Concerns ==
Wie im Abschnitt "Zugriffs-Kontolle" ausführlicher beschrieben wird, bietet der Builder eine Möglichkeit
die Zuständigkeiten über Entities so trennen. Das klingt zunächst einmal etwas merkwürdig; welche Zuständigkeiten
sollte man bei einem Entity -- das selbst keine Logik enthält -- trennen?

Es geht hier um die Trennung von Erzeugung (bzw. Manipulation) des Objekts und dem Zugriff auf den Inhalt.
Die Idee des immutable Objekts ist Java grundsätzlich fremd, sie widerspricht geradezu der eigentlichen Objekt-Idee.
Aber tatsächlich haben unveränderliche Objekte in einer multithreading-Umgebung große Vorteile,
weil sie die Synchronisation stark vereinfachen. Nicht umsonst ist das funktionale Paradigma weiterhin auf dem Vormarsch.

Konsequent durchgezogen, kann das Entity vollständig auf Setter verzichten indem es die Manipulation dem Builder überträgt
und sich darauf beschränken Daten zu halten und herauszugeben.

== Statisch oder dynamisch? ==
Das ist für jede Programmiersprache die -- oder zumindest eine -- Gretchenfrage. Was ist damit gemeint?
Statisch heißt "zur Compile-Zeit", dynamisch -- oder nicht-statisch -- bezeichnet das Gegenstück, nämlich "zur Laufzeit".

Wenn Tony Hoare die Einführung von "null" in ALGOL als "billion Dollar mistake" bezeichnet hat, meinte er damit,
daß die null- oder Ungültigkeitsprüfung optimalerweise zur Compile-Zeit stattfinden sollte. Es giebt mittlerweile
Sprachen, die Konzepte dafür implementieren -- in Java sind sie nur unzulänglich ausgeführt.

Inwiefern betrifft das den Builder? Bei jeder Prüfung muß man sich fragen, wann diese stattfinden soll.
Was ist mit Muß-Werten? Kann man das Vorhandensein zur Compile-Zeit prüfen -- was sicherer wäre -- oder soll man
die Prüfung auf die Laufzeit -- was einfacher wäre -- verlagern? Auf diese spezielle Frage wird später noch eingegangen,
betrachten wir die Frage etwas allgemeiner: "wann statisch, wann dynamisch"?

Die Antwort lautet: -- wie überraschend -- kommt drauf an...

Grundsätzlich kann man sagen: statische Prüfung ist immer aufwändiger als die dynamische. Definiert an einen einfachen
Builder mit mehrereren Konfigurations-Methoden, kann man die Methoden in beliebiger Reihenfolge aufrufen; im einfachsten
Falle sogar mehrfach. Möchte man eine Reihenfolge festlegen, die bereits zur Compile-Zeit eingehalten werden muß ist das
prinzipiell möglich. es erfordert allerdings zusätzliche Klassen und verursacht Aufwand.

Möchte man zur Compile-Zeit sicher sein, daß Muß-Felder gefüllt sind, geht das nur über (häßliche) Konstruktoren und selbst
dann hat man nur eingeschränkte Kontrolle darüber, ob die Felder mit brauchbaren Werten gefüllt sind.

Es bleibt also eine Abschätzung: Lohnt sich der Aufwand -- wenn es denn überhaupt geht?

Der Aldi-Tip: Mach's dynamisch und schreib' viele Unit-Tests.

== Migration/Versionierung ==
Die Separation von Datenspeicherung -- im Entity -- und Manipulation -- im Builder -- macht es einfacher,
zwischen unterschiedlichen Versionen von Entities zu unterscheiden, diese zu erzeugen und Migration von
Daten zwischen Versionen durchzuführen.

Kategorie:Builder

2025-02-24T16:15:32Z

Ullrich:

[[Category:Java]]
Eine Heranführung in das Thema bietet die Seite [[Builder:Motivation|Motivation]].

Die drei Teile des Builders beschreibt die Seite [[Builder:Komponenten|Komponenten]].

Die zwei Orte an denen man den Builder definieren kann zeigt die Seite [[Builder:Location|Location]].

Näheres über die Erzeugung der Generate bietet die Seite [[Builder:Objekt-Erzeugung]].

Kategorie:Builder

2025-02-24T16:15:08Z

Ullrich:

Kategorie:Builder

2025-02-24T16:11:09Z

Ullrich: Die Seite wurde neu angelegt: „Category:Java“

[[Category:Java]]

Builder:Objekt-Erzeugung

2025-02-24T16:09:57Z

Ullrich: Die Seite wurde neu angelegt: „Kategorie:Java Kategorie:Builder =Objekt-Erzeugung= Wann soll das Objekt -- das der Builder bauen soll -- erzeugt werden? Auf diese Frage giebt es zwei Antworten: "Up front" oder "in time". Für beide Varianten giebt es Argumente, welche man wählt hängt von den Umständen ab. Betrachten wir also beide... ==Up font== Was so viel heißt: Wir erzeugen das Objekt und füllen die Daten direkt hinein. Die Erzeugung findet entweder bei der Deklaratio…“

[[Kategorie:Java]]
[[Kategorie:Builder]]
=Objekt-Erzeugung=

Wann soll das Objekt -- das der Builder bauen soll -- erzeugt werden? Auf diese Frage giebt es
zwei Antworten: "Up front" oder "in time". Für beide Varianten giebt es Argumente, welche man wählt
hängt von den Umständen ab. Betrachten wir also beide...

==Up font==
Was so viel heißt: Wir erzeugen das Objekt und füllen die Daten direkt hinein.
Die Erzeugung findet entweder bei der Deklaration des entsprechenden Feldes statt
oder im Konstruktor des Builders. Zu bevorzugen ist der erste Fall, das kann
zum Beispiel so aussehen:
{{java|code=
Foo foo == new Foo();
FooBuilder withName(String name) {
foo.setName(name);
return this;
<nowiki>}</nowiki>
}}
Das Objekt das der Builder erzeugt wird erzeugt und von den with-Methoden direkt befüllt.
Der Vorteil ist ein sehr geringer Overhead, weil kein Zwischenspeicher für gesetzte Werte
benötigt wird. Die build-Methode kann das Objekt ohne weitere Aktionen ausliefern.
Wenn es darum geht, Entities zu erzeugen und zu befüllen ist das normalerweise das Mittel der Wahl.

==in time==
Die Alternative ist, das Objekt erst dann zu erzeugen, wenn es tatsächlich benötigt wird,
in der Regel geschieht das dann in der build-Methode. Der offensichtliche Nachteil ist,
daß die with-Methoden ihre Daten nicht direkt in das zu erzeugende Objekt füllen können.
Es wird ein Buffer -- üblicherweise in Form von Builder-Feldern benötigt:
{{java|code=
private String name;
FooBuilder withName(String name) {
this.name = name;
return this;
}

Foo build() {
Foo foo = new Foo();
foo.setName(this.name);
return foo;
<nowiki>}</nowiki>
}}
==Wann was?==
Wie man sieht ist der Aufwand bei der verzögerten Erzeugung spürbar höher als bei der Befüllung des sofort erzeugten Objekt.
Warum sollte man sich das antun? Man wird sich für die vergögerte Variante in der Regel nur dann entscheiden, wenn es gute
Gründe für die verzögerte Objekt-Erzeugung giebt. Wenn man etwa das Objekt nur dann anlegen möchte, wenn tatsächlich alle Daten
vorhanden sind bzw. alle Daten korrekt sind. Oder wenn die Erzeugung des Objektes besonders teuer ist.

Und es giebt einen Fall, in dem es gar nicht anders geht. Nämlich wenn das zu erzeugende Objekt die
Daten -- oder zumindest einige der Daten -- im Konstruktor verlangt. Diese Variante wird im nächsten Abschnitt beschrieben.

Einen wichtigen Punkt muß man dabei unbedingt berücksichtigen.
Wird das Objekt sofort erzeugt und von der Abschlußmethode des Builders geliefert, verändert jeder nachfolgende Aufruf
einer with-Methode des Builders dazu, daß das eben erzeugte Objekt nachträglich verändert wird!

Die verzögerte Erzeugung kann verwendet werden, wenn der Builder als (Massen-)Factory verwendet werden soll.
Man konfiguriert damit ein Objekt, erzeugt es, verwendet die Konfiguration als Grundlage für das nächste Objekt
und so fort.

==der Fall des ekelhaften Konstrukturs==
Ein formidables Beispiel liefert uns freundlicherweise der JDK. Es handelt sich um die Klasse NewCookie.
Der schlimmste Konstruktur -- es giebt im JDK 1.7 sieben Stück davon -- könnte im Aufruf so aussehen:
{{java|code=
cookie = NewCookie("myCookie", null, null, 4711, "unused", 10, null, true, true);
}}
Das ist so lesbar wie ansprechend... In diesem Falle bekommt der Builder für jeden Parameter ein Feld
und eine with-Methode. Erst in der build-Methode erzeugt man den Cookie mit den Werten der Builder-Felder.
Auf diese Weise werden im Builder-Aufruf nur die erforderlichen Werte gesetzt, die übrigen ggf. mit
default-Werten vorbelegt und der Benutzer braucht nicht nach dem passenden Konstruktor suchen.

In diesem Falle ist es natürlich auch sinnvoll, in der build-Methode zu prüfen, ob alles da ist was benötigt wird.

Builder:Location

2025-02-24T16:08:46Z

Ullrich: Die Seite wurde neu angelegt: „Kategorie:Java Kategorie:Builder =Wohin mit dem Builder?= Es giebt zwei Orte, an dem man den Builder unterbringen kann. Man kann ihn als separate Klasse ''irgendwo' ablegen,'' oder man kann ihn als member class in der Generat-Klasse ansiedeln. Wo man den Builder unterbringt ist wohl im wesentlichen eine Geschmacksfrage. Hat man keine Möglichkeit die Generat-Klasse zu ändern, bleibt allerdings nur die Möglichkeit, den Builder als separate Klass…“

[[Kategorie:Java]]
[[Kategorie:Builder]]
=Wohin mit dem Builder?=
Es giebt zwei Orte, an dem man den Builder unterbringen kann. Man kann ihn als separate Klasse ''irgendwo' ablegen,''
oder man kann ihn als member class in der Generat-Klasse ansiedeln. Wo man den Builder unterbringt ist wohl im
wesentlichen eine Geschmacksfrage. Hat man keine Möglichkeit die Generat-Klasse zu ändern, bleibt allerdings nur
die Möglichkeit, den Builder als separate Klasse zu implementieren.

==Der Builder als eigene Klasse==
Eigentlich giebt es hierzu nicht viel zu sagen, der Aufbau des Builder ist ziemlich simpel. nehmen wir als Beispiel
folgende Klasse als Beispiel:
{{java|code=
class Person {
private String vorname;
public String getVorname() {
return vorname;
}

public String setVorname(String vorname) {
this.vorname = vorname;
}
<nowiki>}</nowiki>
}}
dann sieht der Builder dazu so aus:
{{java|code=
class PersonBuilder {
private Person person = new Person();

public PersonBuilder withVorname(String vorname) {
person.setVorname(vorname);
return this;
}

public Person get() {
return person;
}
<nowiki>}</nowiki>
}}
Nichts Aufregendes hier. Wenn der Builder im gleichen Package angesiedelt ist wie die Generat-Klasse
und die Felder des Generats package visibility haben (public sollten sie niemals sein), dann können wir
die Modifier-Methoden darauf umschreiben und auf die Indirektion durch den setter verzichten:
{{java|code=
public PersonBuilder withVorname(String vorname) {
person.vorname = vorname;
return this;
<nowiki>}</nowiki>
}}
In diesem Falle können wir auf den Setter in der Generat-Klasse verzichten und das Feld im Generat
immutable machen, oder wir können den Builder für die Manipulation verwenden. Auf diese Weise können
wir die vollkommene Kontrolle über die Generat-Felder halten.

==Der Builder als member class==
Über den Unterschied zwischen member class und inner class sein an dieser Stelle auf die Java-Spec
verwiesen. Es genüge an dieser Stelle, daß die member class -- im Gegensatz zur inner class -- unabhängig
von der sie umgebenden Klasse zu erzeugen.

Wir verwenden die gleiche Klasse wie oben und fügen den Builder dort ein:
{{java|code=
class Person {
private String vorname;
String getVorname() {
return vorname;
}
public static class Builder {
private Person person = new Person();
Builder withVorname(String vorname) {
person.vorname = vorname;
return this;
}

Person get() {
return person;
}
}
<nowiki>}</nowiki>
}}
Zwei Unterschiede fallen in's Auge: da der Builder in der Generat-Klasse liegt, können wir ihn
einfach "Builder" nennen, die Verwendeung sieht damit so aus:
{{java|code=Person person = new Person.Builder().withVorname("Peter").get();}}
Die Sichtbarkeit der Felder spielt nun keine Rolle mehr. Da die fiel class vollen Zugriff auch
auf die private-Felder der Klasse hat die sie enthält, brauchen wir keine Setter mehr. Natürlich können
wir welche definieren, brauchen sie aber nicht für den Builder und müssen die Sichtbarkeit nicht mehr
aufzuweichen.

Builder:Motivation

2025-02-24T16:08:08Z

Ullrich: Die Seite wurde neu angelegt: „Kategorie:Java Kategorie:Builder = Motivation = Ber Begriff "Builder" tritt wohl zum ersten Mal im "Design Patterns"-Buch der Gang of Four auf. Die Absicht des Builder Pattern wird dort definiert durch: :Separate the construction of a complex object from its representation :so that the same construction process can create different representations Es geht dort also um die Trennung von Konstruktion und Repräsentation. Ein wesentlicher Aspekt…“

[[Kategorie:Java]]
[[Kategorie:Builder]]
= Motivation =

Ber Begriff "Builder" tritt wohl zum ersten Mal im "Design Patterns"-Buch der Gang of Four auf.
Die Absicht des Builder Pattern wird dort definiert durch:
:Separate the construction of a complex object from its representation 
:so that the same construction process can create different representations

Es geht dort also um die Trennung von Konstruktion und Repräsentation. Ein wesentlicher Aspekt
dabei ist die Anforderung ''verschiedene'' Repräsentationen aus dem Ergebnis des selben
Konstruktionsprozesses zu erzeugen. Als Beispiel führt das Buch die Konstruktion eines Textes an,
der dann in unterschiedliehen Formaten ausgegeben werden kann.

Auch wenn solche Probleme in der Praxis durchaus vorkommen, hat sich der Builder-Begriff davon mittlerweile losgelöst.
Die meisten Beschreibungen verzichten auf den zweiten Aspekt -- die Erzeugung der Repräsentationen --
und beschränken sich auf die Konstruktion. In diesem Sinne solle der Builder auch in diesem Pamphlet verstanden
werden. Es geht also um die Trennung der Konstruktion von der Verarbeitung des erzeugten Objekts.
Dem Builder geht es dabei ausschließlich um die Konstruktion und die Manipulation der Objekt;
was -- insbesondere fachlich -- weiter mit dem Objektgeschieht, interessiert den Builder nicht.

== Paradigmen ==
Sucht man im Web nach dem Begriff "objektorientiert" so findet man allerhand, nur keine Definition;
nicht einmal ein Konsens darüber was OO eigentlich sein soll findet man.
Eine der ersten Sprachen die "Objekte" eingeführt hat, war [https://en.wikipedia.org/wiki/Simula SIMULA-67].
Wie der Name suggeriert, ist SIMULA im Umfeld von software-gestützten Simulationen entstanden in denen mehr oder weniger
selbständige "Dinge" mit einander interagieren. Die Definition von Grady Booth für das objektorienterte Design enstammt
der realen Welt, nicht der Programmierung; die Eigenschaften treffen jedoch auch beide zu. Demnach hat eine Objekt
* eine Identität
* einen (inneren) Zustand
* eine definiertes Verhalten
Das Objekt tackert damit Daten und Funktionen die damit arbeiten zusammen. Objekte "leben" über einen längeren Zeitraum
und verändern sich dabei. Seit dem Aufkommen in den 1990ern ist "Objektorientierung" das führende Paradigma,
tatsächlich zeichnet sich seit einiger Zeit eine Änderung des Trends ab. Massive Parallelität in allen Bereichen -- vom
Prozessor bis zum globalen Web führen immer wieder zu Problemen, weil die Daten im Objekt nicht für den parallelen Zugriff
vorgesehen sind. Auch wenn SOA kein moderner Begriff mehr ist, ist der Service zum Mantra der Gegenwart geworden.
Die Vorstellung eines Ablaufs, der gestartet und beendet wird, Eingaben aufnimmt und daraus ein Ergebnis berechnet;
unabhängig vom Rest der Welt, mit einer Lebensdauer von Millisekunden -- das ist das Gegenteil eines Objekts.

Auch der Builder bricht mit dem OO-Paradigma indem er die Daten von ihrer Manipulation trennt.
Im Grunde genommen läßt sich die Verarbeitung von Daten nicht zufriedenstellend in der OO-Welt abbilden.
Eine Überweisung führt sich nicht selbst aus. Sie ist ein Auftrag, der im Rahmen eines Prozesses ausgeführt wird.
Die Überweisungs-Daten müssen also vom inneren Zustand der Überweisungsmaschine gertrennt werden. Die Maschine
mag ein Objekt sein, die Überweisungsdaten bilden keines; für sie ist das Datenstruktur- oder Datentyp-Modell angemessener.

Folgt man diesem Gedankenm, führt das zum Konzept das typisierten funktionalen Programmiersprachen zugrunde liegt.

== Die integrierte Factory ==
Im Pattern-Buch taucht ''die'' Factory als Pattern nicht auf. Statt dessen giebt es zwei speziellere Pattern
"Abstract Factory" und "Factory Method" deren Definition hier nicht wiederholt weren soll.
Stellen wir uns statt dessen die Frage: Was möchten wir unter einer ''Factory'' verstehen?

Die kürzestmögliche Definition ist:
:Eine Factory ist ein Ding, das Objekte erzeugt.
Meistens handelt es sich da um ein Objekt, es kann aber auch eine Funktion oder eine Methode sein.

Die Parametrisierung bzw. Konfigurierbarkeit zur Erzeugung von Objekten ''unterschiedlicher'' Klassen
ist zwar möglich, aber nicht wesentlich. Dieser Factory-Begriff kann also getrost auf den Builder angewandt
werden: Ein Builder erzeugt Objekte. Die Klasse des Generats kann für einen
Builder variieren, muß -- und tut es im allgemeinen -- aber nicht.

Was den Builder von der landläufigen Vorstellung der Factory -- und der Gof'schen factory method -- unterscheidet,
ist die Tatsache daß beim Builder zur Erzeugung von Objekten mehrere Methoden aufgerufen werden müssen.

== Fluent Interfaces ==
Geprägt wurde der Begriff wohl von Eric Evens; Martin Fowler schreibt darüber 2005 in seinem
[https://martinfowler.com/bliki/FluentInterface.html Blog].
Die Idee dahinter ist, Folgen von Methoden-Aufrufen auf Objekte -- die so typisch sind für imperative Sprachen wie Java -- zu ersetzen durch verkettete Methoden-Aufrufe, die die Struktur einer domain specific languange aufweisen.
Fowlers Beispiel ähnelt nicht zufällig den Buildern wie sie hier beschrieben werden. Im folgenden soll nicht der Artikel nacherzählt werden, vielmehr geht es darum einen Eindruck vom "fluent interface"-Konzept zu geben.

Manchmal werden fluent interfaces auch als Pattern bezeichnet. Das ist -- im ursprünglichen Sinne -- nicht korrekt.
Ihnen liegt keine fachliche Motivation zugrunde und sie dienen nicht der Lösung irgendeiner Problem-Kategorie.
Sie sind ein Design-Konzept für Programmier-Interfaces.

In Java könnte man sich folgenden Code vorstellen:
{{java|code=
Statement s = new select();
Fields f = new Fields("x, y, z");
s.setFields(f);
Tables t = new Tables("t");
s.setTables(t);
Condition c = new Condition("x = z");
s.setConditions(c)
}}
Man kann -- anstelle der Verwendung lokaler Variablen -- die Objekt-Erzeugung inline durchführen,
aber das macht den Code nicht schöner. Man kommt beim Lesen nicht umhin, den Code sequentiell zu analysieren:
Erzeugt wird ein Statement, dann wird ein "Field"-Objekt erzeugt, das wird dem Statement
hinzugefügt, und so fort. Der Eingeweihte erkennt schnell das SQL-Statement das hier konstruiert wird.

Man kann das -- anlehnend an die SQL-Syntax -- auch in Java anders formulieren:
{{java|code=
Statement s = new Select() //
.fields("x, y, z") //
.from("t") //
.where("x = z");
}}
Anstelle der von einander unabhängigen Setter definiert die {{java|Select}}-Klasse Methoden, die immer wieder das gleiche
{{java|Select}}-Objekt als Ergebnis liefern. Die DSL die hier definiert wird, entspricht der SQL-Syntax und man kann sich
vorstellen, daß -- wenn die {{java|where}}-Methode entsprechend modelliert wird -- auch die Definition geschachtelter
Select-Statements möglich sind.

Das sind denn auch die beiden Elemente der fluent interfaces, die hier wesentlich sind.
Zunächst einmal das "method chaining": Man versteht darunter, daß die Methoden-Aufrufe nicht in einzelnene Befehlen
geschehen -- wie das bei Verwendung von Settern und lokalen Variablen der Fall ist -- sondern in einer (mehr oder weniger langen)
Kette von aufeinander angewandten Methoden, so daß für die komplette Folge nur ein einziger Befehl
(gewissermaßen ein einziges Semikolon) benötigt wird.

Das zweite Element ist die Schachtelung. Statt Unter-Objekte in lokalen Variablen abzulegen und dort zu manipulieren,
werden sie -- wieder in einer einzigen Methoden-Kette erzeugt und dann direkt als Argumente an Methoden übergeben.
Das ganze Konstrukt erhält dadurch einen eher funktionalen Charakter. Das ist für den "prozeduralen" Java-Hacker
ein eher ungewohntes und damit befremdliches Konzept.

Ich stand der "fluent interface"-Idee von Anfang an skeptisch gegenüber. Solange die dadurch definierte DSL den Charakter einer formalen
Sprache hat -- wie das bei SQL der Fall ist -- die einer eindeutig definierten inneren Logik folgt, giebt es eigentlich kein Problem.
Wenn man aber versucht -- und so wird es vielfach verkauft -- natürliche Sprache darüber nachzubilden wird die Sache schwierig.
Computer-Programme sind formal und lassen keine Unschärfe zu; das Gegenteil ist ein wesentliches Merkmal natürlicher Sprachen.

Wie kann man nun zusammenfassen inwiefern fluent interfaces bei der Builder-Konstruktion bedeutsam sind?

{{quotation|Der Builder verwendet Method Chaining und Schachtelung, um klassische Anweisungsfolgen durch eine DSL zu ersetzen.}}

Dadurch wird einerseits eine bessere Lesbarkeit und eine bessere Verständlichkeit der zugrundeliegenden Semantik erreicht
und andererseits boiler plate code gekapselt, der sonst die die Aufmerksamkeit absaugen würde.

== Separation of Concerns ==
Wie im Abschnitt "Zugriffs-Kontolle" ausführlicher beschrieben wird, bietet der Builder eine Möglichkeit
die Zuständigkeiten über Entities so trennen. Das klingt zunächst einmal etwas merkwürdig; welche Zuständigkeiten
sollte man bei einem Entity -- das selbst keine Logik enthält -- trennen?

Es geht hier um die Trennung von Erzeugung (bzw. Manipulation) des Objekts und dem Zugriff auf den Inhalt.
Die Idee des immutable Objekts ist Java grundsätzlich fremd, sie widerspricht geradezu der eigentlichen Objekt-Idee.
Aber tatsächlich haben unveränderliche Objekte in einer multithreading-Umgebung große Vorteile,
weil sie die Synchronisation stark vereinfachen. Nicht umsonst ist das funktionale Paradigma weiterhin auf dem Vormarsch.

Konsequent durchgezogen, kann das Entity vollständig auf Setter verzichten indem es die Manipulation dem Builder überträgt
und sich darauf beschränken Daten zu halten und herauszugeben.

== Statisch oder dynamisch? ==
Das ist für jede Programmiersprache die -- oder zumindest eine -- Gretchenfrage. Was ist damit gemeint?
Statisch heißt "zur Compile-Zeit", dynamisch -- oder nicht-statisch -- bezeichnet das Gegenstück, nämlich "zur Laufzeit".

Wenn Tony Hoare die Einführung von "null" in ALGOL als "billion Dollar mistake" bezeichnet hat, meinte er damit,
daß die null- oder Ungültigkeitsprüfung optimalerweise zur Compile-Zeit stattfinden sollte. Es giebt mittlerweile
Sprachen, die Konzepte dafür implementieren -- in Java sind sie nur unzulänglich ausgeführt.

Inwiefern betrifft das den Builder? Bei jeder Prüfung muß man sich fragen, wann diese stattfinden soll.
Was ist mit Muß-Werten? Kann man das Vorhandensein zur Compile-Zeit prüfen -- was sicherer wäre -- oder soll man
die Prüfung auf die Laufzeit -- was einfacher wäre -- verlagern? Auf diese spezielle Frage wird später noch eingegangen,
betrachten wir die Frage etwas allgemeiner: "wann statisch, wann dynamisch"?

Die Antwort lautet: -- wie überraschend -- kommt drauf an...

Grundsätzlich kann man sagen: statische Prüfung ist immer aufwändiger als die dynamische. Definiert an einen einfachen
Builder mit mehrereren Konfigurations-Methoden, kann man die Methoden in beliebiger Reihenfolge aufrufen; im einfachsten
Falle sogar mehrfach. Möchte man eine Reihenfolge festlegen, die bereits zur Compile-Zeit eingehalten werden muß ist das
prinzipiell möglich. es erfordert allerdings zusätzliche Klassen und verursacht Aufwand.

Möchte man zur Compile-Zeit sicher sein, daß Muß-Felder gefüllt sind, geht das nur über (häßliche) Konstruktoren und selbst
dann hat man nur eingeschränkte Kontrolle darüber, ob die Felder mit brauchbaren Werten gefüllt sind.

Es bleibt also eine Abschätzung: Lohnt sich der Aufwand -- wenn es denn überhaupt geht?

Der Aldi-Tip: Mach's dynamisch und schreib' viele Unit-Tests.

== Migration/Versionierung ==
Die Separation von Datenspeicherung -- im Entity -- und Manipulation -- im Builder -- macht es einfacher,
zwischen unterschiedlichen Versionen von Entities zu unterscheiden, diese zu erzeugen und Migration von
Daten zwischen Versionen durchzuführen.

Builder:Komponenten

2025-02-24T16:07:31Z

Ullrich: Die Seite wurde neu angelegt: „Kategorie:Java Kategorie:Builder =Komponenten= Die Anwendung eines Buildes im Code erfolgt stets in drei Schritten, auch wenn diese nicht immer unmittelbar hintereinander ausgeführt werden müssen: #Erzeugen des Builders #Konfiguration oder Manipulation des vom Builder zu erzeugenden Objektes #Herausgabe des gewünschten Objekts Auch wenn es Variationen darüber giebt was die einzelnen Methoden des Builders tatsächlich tun, giebt es zu jeder der…“

[[Kategorie:Java]]
[[Kategorie:Builder]]
=Komponenten=
Die Anwendung eines Buildes im Code erfolgt stets in drei Schritten, auch wenn diese nicht
immer unmittelbar hintereinander ausgeführt werden müssen:
#Erzeugen des Builders
#Konfiguration oder Manipulation des vom Builder zu erzeugenden Objektes
#Herausgabe des gewünschten Objekts
Auch wenn es Variationen darüber giebt was die einzelnen Methoden des Builders tatsächlich tun,
giebt es zu jeder der genannten Schritte auch eine Gruppe von Methoden die zur Ausführung des Schrittes
beitragen. Wir haben damit drei Gruppen von Methoden:

#Creator-Methoden zur Erzeugung
#Modifier-Methoden zur Manipulation
#Generator-Methoden zur Auslieferung des Ergebnisses

Während man oft nur eine Erzeugungs- und in der Regel nur eine Methode zur Auslieferung des Objekts benötigt,
hat man üblicherweise einige oder viele Konfigurations-Methoden. Der Begriff "Generator"-Methode ist dabei diskutabel,
weil das Objekt nicht notwendigerweise in der "Generator"-Methode erzeugt werden muß.

==Builder erzeugen mit dem Creator==
Um mit einem Builder arbeiten zu können, muß man zunächst ein passendes Objekt erzeugen.
Dazu hat man in Java zwei Möglichkeiten: Mit einem passenden Konstruktor einerseits oder einer (in der Regel statischen)
Factory Methode -- die natürlich ihrerseits einen Konstruktor aufruft -- andererseits.

Offensichtlich braucht man in jedem Fall einen Konstruktor, es geht also eher um die Frage ob man
diesen Konstruktor direkt oder über eine geeignete Methode zugänglich macht.

===Konstruktor===
Die Konstruktor-Variante liegt den meisten Entwicklern wohl am nächsten.
Dabei wird für jede Art der Erzeugung ein Konstruktor definiert -- maximal einen ohne und beliebig viele mit Parametern.
Da die Befüllung in der Regel über Modifier-Methoden geschieht, steuert man mit den Konstruktor-Parametern
seltener die Erzeugung des Builders selbst, oftmals aber die Initial-Befüllung.

Ein naheligendes Beispiel ist die Implementierung eines Konstruktors für die Erzeugung neuer Generate
und eines Konstruktors zur Manipulation existierender Generate:
{{java|code=
public class PersonBuilder {
private Person person;
public PersonBuilder() {
person = new Person();
}
public PersonBuilder(Person person) {
this.person = person;
}
<nowiki>}</nowiki>
}}
Man kann dem Konstruktor auch Werte zur Initial-Belegung mitgeben:
{{java|code=
public class AmpelBuilder {
private Ampel ampel = new Ampel();
public AmpelBuilder(Color initial) {
ampel.farbe = initial;
}
...
<nowiki>}</nowiki>
}}
Von dem Konzept, im Konstruktor ''alle'' nicht-optionalen Werte zu setzen wird an dieser Stelle allerdings abgeraten.
Einerseits bietet es eine gewisse statische Sicherheit, führt aber in der Praxis zu immer häßlicheneren Konstruktoren.
Besser lesbar ist immer die Variante, die Konsistenz des Generats -- oder die Möglichkeit der Erzeugung -- in
der Generator-Methode zu prüfen.

Die Verwendung von Konstruktoren findet ihre Grenze da, wo sich die Konstruktoren nicht mehr anhand der Typen
ihrer Parameter-Liste unterscheiden lassen. Das ist schlicht und ergreifend unmöglich zu implementieren.

===Statische Methoden===
Der Personen-Builder des vorangegangenen Absatzes würde mit statischen Methoden so aussehen:
{{java|code=
public class PersonBuilder {
private Person person;

public static PersonBuilder empty() {
return new PersonBuilder (new Person());
}

public static PersonBuilder use(Person person) {
return new PersonBuilder (person);
}

private PersonBuilder(Person person) {
this.person = person;
}
<nowiki>}</nowiki>
}}
Wir verwenden hier weiterhin den Konstruktor zur Initialisierung, machen ihn aber private und rufen ihn
über die statischen Methoden auf. Das macht im vorliegenden Beispiel keinen großen Unterschied, sieht nur etwas anders aus.

Betrachten wir nochmal das Ampel-Beispiel von vorhin. Der Aufruf
{{java|new AmpelBuilder(Color.BLUE)}}
ist nun nicht besonders sinnvoll. Wollten wir das mit der Konstruktor-Lösung verhindern, blieben nicht viel
Möglichkeiten. Wir könnten ein Enum definieren, dort nur die Ampel-Farben zulassen und einen Konstruktor mit
einem entsprechenden Enum-Parameter definieren. Statische Methoden bieten eine weniger aufwändige Möglichkeit:
{{java|code=
static AmpelBuilder rot() {
return new AmpelBuilder(Color.RED);
}
static AmpelBuilder gelb() {
return new AmpelBuilder(Color.YELLOW);
}
static AmpelBuilder gruen() {
return new AmpelBuilder(Color.GREEN);
<nowiki>}</nowiki>
}}
Der Konstruktor wird dann wieder private deklariert.

===Wann wählt man was?===
Wenn man die freie Wahl hat, ist die Entscheidung tatsächlich eine Geschmacksfrage.
Wenn man mehr Creator-Methoden braucht als die Konstruktor-Lösung es hergiebt, giebt es eigentlich keine Wahl.
Es sei denn, man bevorzugt seltsame Lösungen mit Selektor-Parametern.

Auf jeden Fall sollte man dabei aber die Parameter-Listen so kurz wie möglich halten.
Und generische Parameter mit Typen wie {{java|int}} oder {{java|String}} sollten bei der Erzeugung nur dann verwendet werden,
wenn tatsächlich ''alle'' Werte erlaubt sind. Wenn man etwa eine eMail-Adresse als String übergiebt, kann man dem Konstruktor
nicht ansehen welche Bedeutung der übergeben String hat. Eine statische Methode könnte {{java|forMailAddress}} heißen.

Eine viel elegantere Lösung bietet ein eigener Datentyp "EmailAdresse", was mithilfe von {{java|record}} sehr schlank
zu implementieren ist.

==Das Generat definieren mit dem Modifier==
Die Modifier-Methoden versorgen dem Builder mit Daten aus denen das Generat befüllt wird.
Sie haben alle den selben Aufbau:
{{java|code=
Builder methode(Typ wert) {
// übernehme Daten aus "wert"
return this;
<nowiki>}</nowiki>
}}
Die Modifier-Methoden sollten einen einzelnen Parameter haben. In Ausnahmen kann man auch
auf den Parameter verzichten. Mehr als einen Parameter sollte man aber nicht übergeben. Ausgenommen
ist die Übergabe beliebig vieler Parameter -- die vararg-Form.

Wer unbedingt mehrere Parameter an die Modifier-Methode übergeben möchte, folge der "Clean Code"-Methode
und definiere ein Parameter-Objekt, das die Werte in ''einem'' Objekt zusammenfaßt. Dafür kann man sehr gut
einen Builder schreiben...

===Einen Wert übernehmen===
Im einfachsten Fall wird ein einzelner Wert übergeben. Die Methode sollte
''nicht'' {{java|setIrgendwas}} heißen, das giebt nur Verwirrung mit nicht-Builder-Klassen.
Empfehlenswert ist das Präfix "with":
{{java|code=
FooBuilder withName(String name) {
foo.setName(name);
return this;
<nowiki>}</nowiki>
}}
Der Wert wird übernommen und ''in Gänze'' in das Ergebnis-Objekt übernommen.
Sollen nur Teile des übergebenen Arguments verwendet werden, sollte man einen anderen Präfix
wählen, zum Beispiel "use" oder "from" oder entsprechende Konstrukte.
Hier soll nur der Name der übergebenen Person verwendet werden:
{{java|code=
FooBuilder useForName(Person person) {
foo.setName(person.getName());
return this;
<nowiki>}</nowiki>
}}
Auf Namenskonventionen wird im Anschluß eingegangen.

===Werte aus einem Objekt extrahieren===
Wenn nicht das gesamte übergebene Objekt verwendet werden soll
sondern nur ein Teil davon, sollte sich das in der Benamung niederschlagen.

Soll etwa nur der Name einer person verwendet werden, kann man schreiben:
{{java|code=
public FooBuilder usePersonForName(Person person) {
foo.setName(person.getName());
return this;
<nowiki>}</nowiki>
}}
Man kann das verwendete Objekt im Namen auch weglassen und {{java|useForName}} schreiben.
Werden generische Typen wie {{java|String}} oder Zahlen verwendet sollte man aber immer
dazuschreiben als was der Parameter übergeben wird, denn aus dem Datentyp geht es nicht hervor.

werden mehrere Komponenten des übergebenen Objekts verwendet kann man gegebenenfalls einfach
{{java|use}} schreiben. Dann muß aber aus dem Kontext bzw. im Team klar sein was da geschieht.
Grundsätzlich gilt: So genau wie nötig, so allgemein wie möglich.
===Generate anderer Builder===
Möchte man Objekte mit dem Builder setzen, verwendet man nicht selten Objekte die
andere Builder generieren. Zum Setzen der Adresse einer Person in der Klasse
{{java|code=
public class Person {
Adresse adresse;
<nowiki>}</nowiki>
}}
kann man im Builder die Methode
{{java|code=
public PersonBuilder with(Adresse adresse) {
person.adresse = adresse;
return this;
<nowiki>}</nowiki>
}}
definieren und wie folgt aufrufen:
{{java|code=new PersonBuilder().with(new AdressBuilder().get());}}
Wenn man die Modifier-Methode mit dem Builder als Parameter-Typ definiert:
{{java|code=
public PersonBuilder with(AdressBuilder adresse) {
person.adresse = adresse.get();
return this;
<nowiki>}</nowiki>
}}
Sieht der Aufruf so aus:
{{java|code=new PersonBuilder().with(new AdressBuilder());}}
Man spart sich immerhin den Aufruf der Generator-Methode.
Man schafft damit aber auch eine Möglichkeit für den einbettenden Builder, das übergeben Objekt
zu modifizieren. Das ist etwa dann hilfreich, wenn das eingebettete Objekt eine Referenz über
das einbettende Objekt haben soll (das Beispiel ist vielleicht nicht sehr sinnvoll):
{{java|code=
public PersonBuilder with(AdressBuilder adresse) {
adresse.setBewohner(person);
person.adresse = adresse.get();
return this;
<nowiki>}</nowiki>
}}
Da wir hier nur eine Referenz setzen wollen, werden wir nicht die Generator-Methode des Personen-Builder aufrufen.

===Boolean-Werte===
Boolean-Parameter sind ''immer'' häßlich, weil die Bedeutung von {{java|true}} und {{java|false}}
nur aus dem Kontext erschlossen werden kann. Alternativ kann man hier zwei parameterlose Modifier-Methoden
anbieten -- eine für {{java|true}} und eine {{java|false}}. Ist der default-Wert klar,
kann man auch auf eine der beiden Methoden verzichten:
{{java|code=
public FooBuilder enabled() {
foo.setEnabled(true);
return this;
}
public FooBuilder disabled() {
foo.setEnabled(false);
return this;
<nowiki>}</nowiki>
}}
Für einen Manipulator-Builder kann man auch eine "toggle"-Methode anbieten, die den aktuellen Wert negiert.

===Sammlungen manipulieren===
Enthält das Objekt eine Sammlung von anderen Objekten, benötigt man in der Regel eine Methode zum Hinzufügen
einzelner Elemente. Niemals sollte man eine Collection zur Manipulation herausrücken, das bringt nur Probleme.
Getter- und Setter für Collections anzubieten ist so ziemlich das Dümmste was man machen kann...

Unter Sammlung wollen wir hier jedes Konstrukt verstehen, das Objekte einer gemeinsamen Klasse zusammenfaßt.
Also List-, Set-, Array-, und alle anderen Collection-Objekte sowie klassische Java-arrays und selbstgebaute
Objekte.

Grundsätzlich lassen sich auch Methoden für das Entfernen von Listen-Elementen definieren,
aber beim Zusammenbauen von Objekten braucht man das eher selten.

Als Präfix bietet sich hier "add" ganz von selbst an :-)
Im folgenden Code-Schnipsel wird bei Bedarf auch die Collection selbst erzeugt.
In der Regel ist es besser, sie bei der Objekt-Erzeugung selbst anzulegen.

{{java|code=
public FooBuilder add(Adresse adresse) {
if (foo.getAdressen() == null) {
foo.setAdressen(new ArrayList<Adressen>());
}
foo.getAdressen().add(adresse);
return this;
<nowiki>}</nowiki>
}}
Eine Liste von Objekten läßt sich damit so hinzufügen:
{{java|code=adresssListe.stream().forEach(FooBuilder::add);}}

Bisweilen ist es aber eleganter eine Sammlung von Objekten komplett zu übergeben.
Der Stream ist auch hier der Parameter-Typ der Wahl, weil sich jede Sammlung ohne overhead in einen Stream
überführen läßt. Wir behalten in jedem Fall die {{java|add}}-Methode und fühen die Stream-Variante als convenience-Methode hinzu:
{{java|code=
public FooBuilder add(Stream<Adresse> stream) {
stream.forEach(this::add);
return this;
<nowiki>}</nowiki>
}}
Eine null-Prüfung sollte man bei Sammlungen eigentlich nicht brauchen. Sammlungen sollten niemals null sein, höchstens leer.
Eine weitere valide Variante ist die Verwendung einer variablen Parameter-Liste. Auch sie läßt sich über einen stream
verarbeiten:
{{java|code=
public FooBuilder add(Adresse... adressen) {
Arrays.stream(adressen).forEach(this::add);
return this;
<nowiki>}</nowiki>
}}
oder -- wenn wir die Stream-Variante ebenfalls implementiert haben:
{{java|code=
public FooBuilder add(Adresse... adressen) {
add(Arrays.stream(adressen));
return this;
<nowiki>}</nowiki>
}}
Das "convenience-Prinzip" hat den Vorteil, daß man die Hinzufügung -- und mögliche zugehörige Logik -- nur ''einmal''
implementieren muß. Gegebenenfalls muß man hier aber tatsächlich die Performance in Betracht ziehen. Die Abfrage ob das
Listen-Objekt vorhanden ist etwa sollte man nicht bei jedem add ausführen.

zum Schluß sei noch die Variante angesprochen bei der der Inhalt der Sammlung ersetzt wird. Das kann zwar sinnvoll sein,
ist aber mit Vorsicht zu genießen, weil dadurch vorangegangene Hinzufügungen Rückgängig gemacht werden. Das ist nicht
intuitiv und kann leicht zu Fehlern führen:
{{java|code=
public FooBuilder replace(Stream<Adresse> stream) {
foo.setAdressen(stream.collect(Collectors.toList()));
return this;
<nowiki>}</nowiki>
}}

===Namens-Konventionen===
Es giebt keine kanonischen Naming-Regeln, man sollte sich daher darum bemühen eine -- zumindest im Team --
allgemeinverständlicher Nomenklatur zu schaffen.

Das empfohlene Namensschema in Java sieht für Methoden ein verbiales Konstrukt vor. Für Setter
verwendet man daher den Imperativ des Verbs "to set" mit dem Namen des Atrtributs.

Da die Modifier-Methoden des Builders keine void-Methoden sind wie die Setter, sondern
die Instanz des verwendeten Builders liefern, verbietet sich "set" als Präfix.

Eine Alternative ist die Verwendung von "with":
{{java|code= public FooBuilder withName(String name);}}
Das bedeutet eine Abweichung vom Verb-Schema, drückt aber aus was geschieht.
Der Builder erhält dadurch einen eher statischen Charakter.
Legt der typ des übergebenen Objekt fest -- oder zumindestes nahe -- was gesetzt wird, kann man den
Attribut-Namen auch weglassen:
{{java|code=
FooBuilder with(StatusEnum status);
FooBuilder with(Person person);
}}
Hat das {{java|Foo}}-Objekt mehr als eine Person oder mehr als einen Status,
kann man das Attribut natürlich nicht weglassen. Die Methode hieße dann aber
eher {{java|withAntragsteller}} bzw. {{java|withVorherigerStatus}} oder so ähnlich.

Hier eine kleine Auflistung möglicher Präfixe:
{|
|add||Hinzufügen von Elementen zu einer Sammlung
|-
|use||Verwendung eines Objekts zur Manipulation
|-
|from||Extraktion von Daten aus einem Objekt
|-
|for||Verwendung des Parameters für einen bestimmten Zweck
|}
Die Namenskonventionen sollten ''immer'' Gegenstand einer Team-Debatte sein.

==Den Bau abschließen mit dem Generator==
Ist die Konfiguration des Objekts abgeschlossen, kann es vom Benutzer abgeholt werden.
Der Builder beitet dafür in der Regel eine einzige Methode an, die üblicherweise {{java|build}}
oder kürzer {{java|get}} heißt. Der Name sollte im Projekt einheitlich gewählt werden.
Wenn der Benutzer beim Aufruf der Generator-Methode entscheiden kann, welche Art Objekt er
haben möchte, kann der Builder auch mehr als eine Generator-Methode anbieten.

Das Objekt wurde entweder schon früher erzeugt und von der Generator-Methode nur ausgeliefert
oder es wird erst beim Aufrufen der Generator-Methode erzeugt. In der Generator-Methode kann auch
eine Validierung durchgeführt werden. Schlägt diese fehl, sollte kein Objekt geliefert werden.
Dann sollte entweder eine Exception fliegen oder das Objekt in ein Ergebnis-Objekt verpackt werden.

Streng genommen ist der raison d'être der Generator-Methode nicht das Erzeugen, sondern das Ausliefern.
Wir bleiben trotzdem beim Ausdruck "Generator"-Methode. Auch wenn es nicht immer akkurat ist, ist die
Vorstellung, daß die Genertor-Methode das gewünschte Objekt herstellt das vorher definiert wurde
ein adäquates Denk-Muster.

===Das Objekt sichern===
Wenn das Objekt nicht erst in der Abschluß-Methode erzeugt wird, muß man dafür sorgen daß es
vom Builder nicht verändert wird. Hält der Builder weiterhin die Referenz auf das erzeugte Objekt,
verändert jeder Aufruf der with-Methode das erzeugte Objekt. Und ein wiederholter Aufruf der
Abschluß-Methode liefert ''jedesmal'' das selbe Objekt.

Man kann im Team die Vereinbarung treffen, daß jedes Builder-Objekt nach Abholen des Objekts
nicht mehr verwendet wird. Das schützt aber nicht vor unbeabsichtigten Fehlern.
Die einfachste Sicherung sieht so aus:
{{java|code=
Foo build() {
result = this.foo;
this.foo = null;
return result;
}}
Jeder Aufruf einer with-Methode führt nun zu einer {{java|NullpointerException}}.
Wenn nötig, kann man die with-Methoden nun mit einer entsprechenden Abfrage sichern um eine
schönere Exception zu erzeugen.

Schüttelreim

2025-01-31T15:23:27Z

Ullrich:

[[Category:Eigenes]]

Ich saß vor meinem Monitor
Und hatte einen Ton im Ohr
undatiert

Ich werde einen Kuchen backen
Und ihn dann zwischen Buchen kacken
19.7.2020

Ich traf dieselben Gecken
Immer bei den gelben Säcken
Januar 2022

Er sitzt auf dem Geschirrspüler
Und lehrt mit viel Gespür Schüler
Januar 2022

Weihnachten wird der Baumkuchen
So knapp, man kann ihn kaum buchen
Januar 2022

Sie aßen ihre Salzstangen
Fortan nur noch mit Stahlzangen
Januar 2023

Er repariert den ganzen Tag Lichtschalter
Und nach der Schicht lallt er
Mai 2023

Das Schiff hat am Rand Latten
Zum Schutz der doofen Landratten
9.7.2023

Die Masten meist im Wege steh'n
Wenn Fahnen an dem Stege weh'n
22.7.2023

Er wollte die Fahne in heroischer Pose hissen
Und mußte dabei sich in die Hose pissen
1.9.2023

Ich greif' nach meiner Beißschiene
Da sticht mich so 'ne Scheißbiene
18.1.2024

Ein Chirurg kann bei Lebewesen
Sehr viel aus dem Gewebe lesen
31.1.2025

Boy Scout Principle

2024-11-29T18:50:05Z

Ullrich: /* Motivation */

[[Category:Quality]]

= Motivation =
Zu den Regeln der Pfadfinderbewegung gehört der Satz:
{{quotation|Always leave the camp ground cleaner than you found it.}}
oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:
{{quotation|Try and leave this world a little better than you found it.}}
In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):
Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren
Müll hinzuzufügen.
Dieses Phänomen wurde in den 80er Jahren als "Broken Window Effect" beschrieben.
Aber was hat das nun mit Software Engineering zu tun?
Zum Äquivalent des Broken Windows Effect im Software Engineering ist [https://blog.codinghorror.com/the-broken-window-theory/ hier] recht nett beschrieben.
Um dessen Vermeidung und die Frage was man statt dessen für die Software-Qualität tun kann soll es im Folgenden gehen.

== Über das Problem ==
Wer lange genug programmiert hat, weiß wie schlimm schlechter Code aussehen kann. Und immer wenn man
denkt man hat schon alles gesehen tritt man in eine Java-Klasse die alles dagewesene in den Schatten stellt. Der
erste Reflex ist meistens "weg damit, alles neu machen". Man bezeichnet dieses Refactoring-Vorgehen auch mit
dem treffenden Namen "Big Bang". Die Umsetzung bereitet in der Praxis allerdings eine ganze Reihe von
Problemen. Das größte ist, daß eine umfassende Refactoring-Maßnahme Aufwände generiert die aus keinem
Budget zu bekommen sind. Das liegt nicht nur an knausrigen Budget-Verwaltern, das liegt auch in der Natur der
Entstehung solcher Code-Höllen. Wer sich beim Codieren nicht um die Qualität kümmert schafft technologische
Schulden, für die keine Deckung existiert und für die in der Regel keine Rücklagen gebildet werden. So kommt Müll
zu Müll und aus kleinen dreckigen Code-Ecken werden langsam aber sicher riesige Müllhalden.
Ein anderes Problem verbirgt sich hinter der Metapher vom Abreißen und Neuaufbau des Systems. Diese aus dem
Hausbau stammende Metapher läßt sich nicht eins zu eins auf die Software-Entwicklung übertragen. Denn das
neue System wird ja nicht einfach aus "neuem" Material gebaut, sondern soll die Substanz des abgerissenen
Systems wiederverwerten. Oder auf den Code bezogen: Die Business-Logik, die sich im Müllhaufen verbirgt – und
das ist ja das eigentliche Kapital der Software, das was das System wertvoll macht – muß erhalten bleiben. Das
funktioniert – vielleicht – wenn man eine exzellente und erschöpfende Dokumentation des Systems hat die genau
die im System enthaltene Fachlichkeit dokumentiert, aber zu welchem System hat man eine solche
Dokumentation?

Der einzige Weg ist dann das akribsche Analysieren des bestehenden Codes und das Übertragen in die neue
Anwendung. Und da es sich um eine vollständige Neuentwicklung handelt muß jede Zeile im Rahmen der
Neuentwicklung untersucht werden; dazu gehört veralteter, nicht mehr verwendeter Code ebenso wie Code-
Gewölle deren Analyse aufgrund der Komplizierteit sehr zeitaufwändig ist. Es gibt keine Möglichkeit, auf
irgendeinen Teil dieser Analyse zu verzichten, denn mit der Migration muß sämtliche Funktionalität übertragen
werden. Sei sie nun offensichtlich oder unter hunderten verschachtelter Klassen vergraben.
Damit ist in vielen Fällen das Migrationsprojekt mangels Budget gestorben. Und weil die Komplettlösung nicht
umsetzbar ist, passiert meistens gar nichts. Dabei muß noch nicht einmal die gesamte Anwendung betroffen sein,
Oft geht es nur darum wesentliche Teile einem Refactoring zu unterziehen, was dann – Budget! Budget! – ebenfalls
nicht geschieht.

= Über die Lösung =
Wenn also der Big-Bang-Ansatz nicht durchführbar ist, was dann? Die kleine, mühsamere und weniger beglückende
Lösung ist der Weg der kleine Schritte. Und wenn man vor lauter Chaos nicht weiß wo anfangen, fängt man am
besten da an wo man gerade steht: Wann immer der Entwickler ein Stück Code bearbeitet oder reviewt – und sei es
noch so klein – dann habe er dabei immer die Frage im Hinterkopf
: Was kann ich hier ohne viel Aufwand besser machen?
Das scheint erstmal für lange Zeit gar nichts zu bringen und es ersetzt auch nicht das kostenintensive
Refactoring größerer Programmteile – besonders, wenn die Architektur Probleme verursacht – aber es hilft auf
lange Sicht Aufwände zu senken und kann den Code so vorbereiten, daß große Refactoring-Maßnahmen überhaupt
erst möglich werden.

= Was kann man konkret tun? =
Erlaubt ist alles, was die Code-Qualität verbessert, dabei aber die Funktionalität nicht beeinträchtigt und solange
man die Schnittstellen nicht anfaßt, ist praktisch alles erlaubt.
* Unit-Tests schreiben
* Dokumentation schreiben
* Kommentare korrigieren und ergänzen
* Methoden- und Klassennamen umbenennen
* Toten und auskommentierten Code entfernen
* Literale durch Konstanten und Konstanten durch Enums ersetzen
* Zweifelhafte Stellen als TODO oder FIXME markieren
* Ungenutzte Teile als "deprecated" markieren
* Code-Blöcke in Methoden auslagern
* Mehrfach verwendete Blöcke in Klassen auslagern
* if-Bedingungen umformen
* ...

= Worauf sollte man achten? =
Entscheidend ist, daß durch das Refactoring nichts kaputt geht. Bevor man also anfängt den Code umzukrempeln
muß man sich darüber klar werden, welche Auswirkung die Änderung hat. Wenn kein eigenes und ausreichendes
Budget für die Überarbeitung zur Verfügung steht, gestaltet man die Änderungen so defensiv wie möglich. Am
besten sichert man die Änderungen immer durch automatische Unit-Tests ab.

Aus diesem Grunde stehen die Unit-Tests in der Aufzählung oben auch ganz oben. Jeder Entwickler sollte immer
alles durch Unit-Tests abdecken – so die Theorie. Die Erhöhung der Testabdeckung ändert zwar überhaupt nichts
an der Code-Qualität, ist aber trotzdem sehr wertvoll. Tests sichern den Code gegen Änderungen ab. Bei der
nächsten Änderung, Erweiterung oder dem nächsten Refactoring merkt man hoffentlich sofort, wenn etwas kaputt
gegangen ist.

Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar
{{quotation|To me, ''legacy code'' is simply code without tests}}

= Noch was? =
Der brave Pfadfinder kümmert sich nicht darum, wer nach ihm kommt. Er sorgt einfach dafür, daß sich der Nächste
wohler fühlt wenn er sein Zelt aufschlägt. Wenn er aber weiß, daß demnächst eine große Gruppe zum Camping
anrückt, dann kann er – mit seinen Genossen – schon mal vorarbeiten. Was heißt das für den Softwerker?
Wenn man weiß, daß irgendwann die großen Refactorings anstehen, daß zum Beispiel das Datenbank-Modell
überholt wird oder ein anderes Framework verwendet werden soll; wenn man also planvoll auf irgendetwas hinarbeiten
möchte, dann kann man die Reinigungsarbeiten schon vorneweg in die richtige Richtung lenken. Hierzu konkrete
Anweisungen vorzugeben ist schwierig, am besten setzt man sich mit dem Team mal hin und überlegt, welches die
schlimmsten Probleme sind, wie man sie beseitigen möchte und wie man da hinkommen kann.

Dazu ein einfaches Beispiel:

Sind beispielsweise Zugriffe auf eine bestimmtes Modul (eine Datenbank oder ein Service) überall im Code verteilt
und auf unterschiedliche Weise implementiert, kann man ein Interface definieren, bei der nächsten Gelegenheit
den ersten Zugriff aus dem Code lösen, damit das Interface mit einer Klasse unterfüttern und verwenden. Kommt
der nächste Entwickler an anderer Stelle auf einen ähnlichen Zugriff, übernimmt er entweder die Implementierung
seines Vorgängers oder er implemetiert eine neue Klasse für das Interface und stellt sie neben die erste.
Irgendwann – wenn zeit ist – nimmt man sich die verschiedenen Implementierungen der Interface vor und konsolidiert die
Implementierungen.

Der Weg zum guten Code

2024-11-28T10:34:27Z

Ullrich: /* Arbeitstechniken */

[[Category:Quality]]
Um entscheiden zu können welcher [https://xkcd.com/844/ Weg zum guten Code] führt, muß man festlegen was
''guten'' Code von schlechtem unterscheidet. Die Erkenntnis, daß es nicht gleichgültig ist, wie Code beschaffen
ist wurde ja offensichtlich schon gewonnen -- andernfalls wäre die Suche eine sinnlose.

"Gut" ist der Code, wenn er über die blanke Funktionalität hinaus weitere Eigenschaften erfüllt. Über diese
nichtfunktionalen Eigenschaften giebt es eine große Literatur, die Worte "Qualiät" und "Architektur" fallen einem in diesem
Zusammenhang ein. Dabei geht es aber in der Regel um die Software-Qualität, also die Qualität des gesamten Erzeugnisses
im Zusammenspiel mit der Umgebung in der es betrieben wird.

Diese Seite engt den Blick ganz bewußt auf den "Code" ein. Damit ist der Quelltext gemeint, aus dem das Erzeugnis
hergestellt wird. Noch genauer geht es dabei um den Programm-Code -- wann kann man diesen als "gut" bezeichnen?

Für den Entwickler -- den Einzigen, der ursächlich an der [https://xkcd.com/1695/ Code-Qualität] interessiert ist --
muß der Code wartbar, erweiterbar und änderbar sein. Der Grad ''dieser'' Eigenschaften bestimmt die Güte des Codes. Die Optimierung dieser Eigenschaften steht bisweilen im Widerspruch zu anderen Eigenschaften -- insbesondere der Performance.
Das Abwägen ist Aufgabe des Architekten und liegt außerhalb des Scope dieses Textes; hier geht es ausschließlich darum
die Code-Qualität zu verbessern.

Es giebt eine unüberschaubare Fülle an Regeln, Tipps, Techniken und Ideologien zum Thema. Nahezu jeder Entwickler,
den man zum Thema Code-Qualität befragt weiß einen anderen Strauß aus seinen Erfahrungen zu binden.

Aus dem Wunsch heraus, einen Überblick über die verwirrende Vielzahl von Begriffe, Ansichten und Ansätzen zu gewinnen
ist die untige Sammlung entstanden. Sie ist weder vollständig noch verbindlich, bietet dem interessierten Leser aber
eine Basis für die weitere Erkundung der Materie. Es wird zwar der Versuch eine Einteilung gemacht um den Überblick zu
verbessern, aber es wird versucht zu vermeiden eine Wertung vorzunehmen.

= Leitgedanken =
Ein Leitgedanke zu dem es bislang noch kein vernünftiges Gegenargument giebt ist folgender:
{{quotation|Die Qualität von Code bemißt sich daran, wie leicht er zu lesen ist}}
Über die Frage, wie "lesbarer" Code konkret auszusehen hat giebt es allerdings unterschiedliche Auffassungen.
Daraus kann man auch ableiten, daß bessere Lesbarkeit nicht automatisch zu besserer Änderbarkeit führt.
Sie führt aber dazu, daß der Code besser zu verstehen ist, daher besser bearbeitet werden kann und damit besser
zu warten ist. "Lesbarkeit" bleibt ein Kernzeil des Qualitäts-Suchenden und er wird sich die Frage bei jeder Code-Zeile
zu stellen haben.

{{quotation|Die Grenzen meiner Sprache sind die Grenzen meiner Welt}}

Im Kontext der Code-Qualität bedeutet das: So klar meine Sprache ist, so klar ist mein Code. Computer-Sprachen
(formale Sprachen überhaupt) lassen keine Mehrdeutigkeiten zu. Wird der gleiche Code bei mehrfacher Ausführung
unterschiedlich interpretiert, so ist das ein Fehler. Eine klare Ausdrucksweise, als Ausdruck klarer Gedanken ist
eine Grundvoraussetzung klaren Programm-Codes.

{{quotation|Separation of Concerns}}

ToDo: Erklärung wie die Idee von Dijkstraa als Leitgedanke zu verstehen ist

= Regeln =
Eine Regel ist eine Richtlinie die vermittelt was man tun – oder lassen – sollte, aber nicht vorgeben wie man das erreicht.
Regeln weisen die Richtung, bestimmen den Generalkurs; bieten aber wenig Hilfe bei der Überwindung konkreter Hindernisse.
Regeln sind keine Naturgesetze; es liegt in ihrer Natur, daß man auch von ihnen abweichen kann.
Es ist wichtig, den Wert einer Regel zu erkennen und daran die Maßnahmen auszuwählen die sie unterstützen.

Die Abgrenzung von Regeln gegen best practices und auch gegen konkrete Maßnahmen ist nicht immer scharf auszumachen.
Aber bevor man sich in exegetische Schlachten begibt, sollte man sich immer fragen, worum es eigentlich geht.
Das Ziel ist klarer, handhabbarer Code, das zu erreichen ist jeder Weg erlaubt.
Das gilt im Übrigen auch für die Gewichtung von Regeln, Ideologie ist immer der falsche Weg -- egal wohin.

* DRY - [[Don't repeat yourself]]
* KISS – Keep it simple stupid [http://www.commitstrip.com/en/2018/10/29/only-the-penitent-coder-will-pass/ commitstrip]
** Ockhams Razor
** Law of Parsimony
** Principle of Least Surprise
* SoC – Separation of Concerns (im Sinne von Aufgaben-Trennung)
* YAGNI – You Aren't Gonna Need It [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Wikipedia]
* [[Cohesion|high cohesion/loose coupling]]
* OCP – Open/Closed Principle
* SRP – Single Responsibility Principle
* Don’t make me think/write your code for everybody
* IoC – Inversion of Control / Dependency Inversion
* Form follows Function – Pragmatismus vor Ästhetik
* ISP – Interface Segregation Principle
* Stick to the Paradigm
* Tell don't ask ([https://martinfowler.com/bliki/TellDontAsk.html Martin Fowler])

Was ist mit SOLID?

Robert C. Martin hat fünf Prinzipien (SRP, open/closed, Liskov, ISP, DI) zusammengefaßt und damit ein tolles backronym zu bilden. Ob man dieser Kollektion einen besonderen Wert zuordnen möchte oder nicht sei mal dahingestellt. Das Liskov-Prinzip wurde hier - wegen seiner Konkretheit - unten den best practices eingeordnet. Die Frage wie man IoC und DI beschreibt und gegen einander abgrenzt ist noch zu diskutieren.

= Best Practice =
Best Practices – auch Heuristiken genannt – sind Techniken oder Vorgehensweisen, die sich in der Praxis in irgendeiner Form
und iregndeiner Situation bewährt haben. Meist lassen sie Gestaltungsspielraum, wenn es um die konkrete Anwendung geht – die
Abgrenzung zwischen einer konkreten Regel und einer allgemeinen Heuristik ist fließend. Und man sollte immer bedenken,
daß best practices in der Regel aus konkreten Situationen heraus entstanden sind und nicht auf jede beliebige Situation übertragbar sind -- dazu giebt es unten ein Antipattern.

* Clean Code (hier nur einige Heuristiken, die sich bei ''meiner'' Arbeit bewährt haben)
** Jeder Bezeichner soll exakt beschreiben, was das Bezeichnete tut oder enthält
** Eine Methode soll eine Wert liefern oder etwas tun, aber nicht beides
** Methoden (auch Konstruktoren) soll nicht mehr als drei Parameter haben
** Death to Magic numbers
** saubere Bezeichner sind besser als gute Kommentare sind besser als keine Kommentare sind besser als falsche Kommentare
** Eine Methode – eine Aufgabe
** lokale Variablen dort deklarieren, wo sie gebraucht werden
* Kent Beck's Design Rules (according to [http://martinfowler.com/bliki/BeckDesignRules.html Martin Fowler])
** Passes the Tests
** Reveals intention
** No Duplication
** Fewest Elements
* DI – Dependency Injection (als Implementierung von IoC)
* LSP - Liskov substitution principle
* Demeter-Prinzip
* Trennung von Abstraktions-Ebenen
* Trennung von Interface und Implementierung siehe dazu auch: Bridge-Pattern
* Interfaces sollen so schmal wie möglich sein und nur das enthalten was tatsächlich erforderlich ist.
* verwende Architektur-Pattern
* verwende das Schichten-Modell
* Integration Operation Segregation Principle (nach unten scrollen: [http://clean-code-developer.de/die-grade/roter-grad/#Integration_Operation_Segregation_Principle_IOSP IOSP])
* verwende Design-Pattern (hier einige GoF-Pattern, die ich besonders häufig verwende)
** Factory Method
** Adapter
** (simplified) Builder
** Singleton
** Proxy
** Facade
** Decorator
* Delegation statt Vererbung (Delegation wird im GoF-Buch nicht als Pattern sondern als Konzept beschrieben)
* Ein Konzept – ein Begriff
::Bsp: die eMail-Adresse sollte im Code nicht durcheinander als "eMail_Adresse", "mail-Adresse", "mail", "eMail" oder sonstwie bezeichnet werden, sondern immer gleich
* vermeide Antipattern
** [https://en.wikipedia.org/wiki/Interface_bloat Interface bloat] -- Interfaces verlangen mehr als erforderlich
** [https://en.wikipedia.org/wiki/Inner-platform_effect Inner-platform effect] – Das System erlaubt soviel Customization, daß eine schlechte Plattform daraus geworden ist.
** [https://en.wikipedia.org/wiki/Constant_interface Constant Interface] -- Interfaces dienen nur der Definition von Konstanten
** [https://en.wikipedia.org/wiki/Sequential_coupling Sequential coupling] -– Die Klasse verlangt den Aufruf ihrer Methoden in einer bestimmten Reihenfolge
** [https://en.wikipedia.org/wiki/Cargo_cult_programming Cargo cult programming] -– Pattern und Methoden verwenden ohne sie zu verstehen
** [https://en.wikipedia.org/wiki/Golden_hammer Golden hammer] / [https://en.wikipedia.org/wiki/No_Silver_Bullet Silver bullet] -– Alle Probleme mit der gleichen (Lieblings-)Methode lösen
** Base Bean – Vererbung soll is-a-Beziehungen abbilden, nicht has-a
** Stellvertreter-Typen – Statt einen Datentyp zu definieren, existierende Klassen (besonders String) mißbrauchen
** [[Petting Zoo]] - keeping code that is not worth it
* vermeide [[Code Smell]]s
* führe regelmäßig Refactoring durch
* Verwende eine durchgehende Nomenklatur
* Stick to the Coding Guidelines
* Das gleiche Problem sollte immer auf gleiche Art und Weise gelöst werden
* Verwende für Kommentare und Bezeichner nur natürliche Sprachen die Du auch beherrschst
:actualValue für den aktuellen Wert (richtig ist current)
:bound als Übersetzung für "verknüpft" (richtig ist linked)
* Don't state the obvious:
{{java|code=
Logger logger = LoggerFactory.obtainLogger();
String stringToBeLogged = "log: logging start of action Foo";
logger.log(stringToBeLogged);
}}

* {{java|toString()}} ist kein Serialisierungs-Tool
* zu viel von etwas ist selten gut:
: <q>If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help.</q>
:([https://en.wikipedia.org/wiki/Michael_A._Padlipsky Michael Padlipsky])

= Hilfsmittel =
Entgegen anderslautender Meinungen erhöht der Einsatz von Tools nicht automatisch die Qualität. Das Berechnen von Werten anhand von Metriken beispielsweise trägt zunächst gar nichts zur Qualität bei, erst die Auswertung und das Durchführen von Maßnahmen zur Änderung der Werte kann als qualitätsstiftende Maßnahme gelten. Nichtsdestotrotz unterstützt die Verwendung von Hilfsmitteln den Entwickler dabei den Weg zum Code hoher Qualität zu beschreiten.

* automatisch durchgeführte Unit-Tests
:Unit-Tests als "Tool" zu beschreiben mag seltsam klingen. Tatsächlich sind Unit-Tests aber nicht Teil des produktiven Codes und daher kann man mit Fug und Recht von einem Tool sprechen.
* Metriken
* Tools zur Code-Analyse (sonar, java-Compiler-Warnings)
* Tools zur Messung der Test-Abdeckung (EclEmma)
* Automatische Code-Formatierung (Eclipse Code Formatter)
* Coding-Guidelines
* [http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html Sun Code Conventions]
:Sie werden seit 1999 nicht mehr gepflegt. Einige Regeln sind überholt, andere zweifelhaft (z.B. 6.2: Variablen-Deklarationen nur am Beginn eines Code-Blocks plazieren), Sie bilden aber die Grundlage für das Code-Layout und man sollte sie kennen und berücksichtigen. 
:(Fun fact: Der Autor hat anscheinend von C abgeschrieben – es sind tatsächlich ein paar Fehler im Dokument)
* Refactoring-Tools (IDEs wie Eclipse bringen eine Menge davon mit

= Arbeitstechniken =
Die klassische Technik des Entwicklers ist das Zurückziehen hinter die Tastatur. Der Entwickler kriecht erst hervor, wenn das Werk vollendet ist. Das beschreibt einen Teil der Tätigkeit, reicht aber schon seit einem halben Jahrhundert nicht mehr aus. Und auch die Handgriffe, mit denen der Entwickler im stillen Kämmerlein den Wandel von Buchstaben in Code vollzieht wandeln sich im Laufe der Zeit. Man muß nicht jede Technik übernehmen, aber man sollte sich damit befassen und zumindest genau wissen, warum man sie nicht einsetzt.

* [[Boy Scout Principle]]
* Code – fremden und eigenen – lesen und reflektieren
* Zuhören
* Diskussion über Code
* Code-Reviews
* XP – extreme Programming
** TDD – Test Driven Development
** Test First Ansatz
** Pair Programming
** Root Cause Analysis
** Incremental Design
* Embrace the CATSAN method
* Programming by Difference (→ Michael Feathers)
* Rubber Duck Debugging
* Technologische Schulden minimieren

= Literatur =
* Edsger Dijkstra [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html On the role of scientific thought]
* Refactoring: Improving the Design of Existing Code (Martin Fowler/Kent Beck)
* Working Effectively with Legacy Code (Michael C. Feathers)
* Clean Code (Robert C. Martin)
* Design Patterns: Elements of Reusable Object-Oriented Software (Gamma/Helm/Vlissides/Johnson)
* The Mythical Man Month (Fred Brooks)
* The Systems Bible – 3rd edition of "Systemantics" (John Gall) [https://en.wikipedia.org/wiki/Systemantics Überblick in der Wikipedia]
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjKitDwvJ3NAhXFKMAKHQ0hBWEQFggpMAE&url=http%3A%2F%2Fworrydream.com%2Frefs%2FBrooks-NoSilverBullet.pdf&usg=AFQjCNGkOYvU4WQgqaHGAqGgicO0XTRcw&bvm=bv.124088155,d.bGg No Silver Bullet] (Fred Brooks)
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiWtayRvZ3NAhUMDMAKHe_JDCYQFggcMAA&url=http%3A%2F%2Fhomepages.cwi.nl%2F~storm%2Fteaching%2Freader%2FDijkstra68.pdf&usg=AFQjCNFIgAgWJ_Aoph79yl9-tFusEGgglQ Goto Considered Harmful] (Edsger Dijkstra)
* [http://clean-code-developer.de/ clean code developer site]
* [http://chris.beams.io/posts/git-commit/ Regeln für GIT-commit-Kommentare]
* [http://www.cs.yale.edu/homes/perlis-alan/quotes.html Epigramme von Alan Perlis]
* [https://www.heise.de/newsticker/meldung/John-Romero-Von-id-Softwares-Anfaengen-und-World-of-Warcraft-Sucht-3296840.html Programmier-Regeln von John Romero]
* [https://sourcemaking.com Gute Sammlung von Pattern, Anti-Pattern etc.]
* [https://xkcd.com/1926 Bad Code in XKCD]

= Zen =
Keine Richtlinien, keine Anweisungen, einfach Aussagen über die man nachdenken kann. Hier kann man beliebig hitzig diskutieren; wichtig ist nur, daß man darüber – möglichst unvoreingenommen – nachdenkt.

* Wer sich nicht klar ausdrückt, denkt auch nicht klar
* big bang features lead to big bang
* Software Engineering ist agnostisch
* Ein Beispiel beweist nichts, widerlegt aber alles – soviel zu TDD- und Test-Abdeckungs-Fetischismus
* Ist TDD die zeitgemäße Formulierung für "trial and error"?
* Wenn Du weißt was Du tust, bist Du gesegnet
* If it ain't broken, don't fix it vs. Refactoring
* Verwende nur was Du auch verstehst ([https://xkcd.com/1597/ Wie XKCD GIT charakterisiert])
* Wer etwas ablehnt oder verteidigt sollte genau wissen warum
* Nichts hält so lange wie ein Provisorium
* Wer trennt schafft Abhängigkeiten, wer nicht trennt schafft Chaos
* Nichts ist so einfach, daß man es nicht falsch machen könnte
* Eine Entscheidung ist richtig, wenn sie rational begründet werden kann
* Was wert ist daß man es tut, ist wert daß man es richtig tut.
* Wenn man versucht Probleme auszusitzen, kriechen sie irgendwann hervor und treten einem in den Hintern

Der Weg zum guten Code

2024-11-28T10:33:15Z

Ullrich: /* Best Practice */

[[Category:Quality]]
Um entscheiden zu können welcher [https://xkcd.com/844/ Weg zum guten Code] führt, muß man festlegen was
''guten'' Code von schlechtem unterscheidet. Die Erkenntnis, daß es nicht gleichgültig ist, wie Code beschaffen
ist wurde ja offensichtlich schon gewonnen -- andernfalls wäre die Suche eine sinnlose.

"Gut" ist der Code, wenn er über die blanke Funktionalität hinaus weitere Eigenschaften erfüllt. Über diese
nichtfunktionalen Eigenschaften giebt es eine große Literatur, die Worte "Qualiät" und "Architektur" fallen einem in diesem
Zusammenhang ein. Dabei geht es aber in der Regel um die Software-Qualität, also die Qualität des gesamten Erzeugnisses
im Zusammenspiel mit der Umgebung in der es betrieben wird.

Diese Seite engt den Blick ganz bewußt auf den "Code" ein. Damit ist der Quelltext gemeint, aus dem das Erzeugnis
hergestellt wird. Noch genauer geht es dabei um den Programm-Code -- wann kann man diesen als "gut" bezeichnen?

Für den Entwickler -- den Einzigen, der ursächlich an der [https://xkcd.com/1695/ Code-Qualität] interessiert ist --
muß der Code wartbar, erweiterbar und änderbar sein. Der Grad ''dieser'' Eigenschaften bestimmt die Güte des Codes. Die Optimierung dieser Eigenschaften steht bisweilen im Widerspruch zu anderen Eigenschaften -- insbesondere der Performance.
Das Abwägen ist Aufgabe des Architekten und liegt außerhalb des Scope dieses Textes; hier geht es ausschließlich darum
die Code-Qualität zu verbessern.

Es giebt eine unüberschaubare Fülle an Regeln, Tipps, Techniken und Ideologien zum Thema. Nahezu jeder Entwickler,
den man zum Thema Code-Qualität befragt weiß einen anderen Strauß aus seinen Erfahrungen zu binden.

Aus dem Wunsch heraus, einen Überblick über die verwirrende Vielzahl von Begriffe, Ansichten und Ansätzen zu gewinnen
ist die untige Sammlung entstanden. Sie ist weder vollständig noch verbindlich, bietet dem interessierten Leser aber
eine Basis für die weitere Erkundung der Materie. Es wird zwar der Versuch eine Einteilung gemacht um den Überblick zu
verbessern, aber es wird versucht zu vermeiden eine Wertung vorzunehmen.

= Leitgedanken =
Ein Leitgedanke zu dem es bislang noch kein vernünftiges Gegenargument giebt ist folgender:
{{quotation|Die Qualität von Code bemißt sich daran, wie leicht er zu lesen ist}}
Über die Frage, wie "lesbarer" Code konkret auszusehen hat giebt es allerdings unterschiedliche Auffassungen.
Daraus kann man auch ableiten, daß bessere Lesbarkeit nicht automatisch zu besserer Änderbarkeit führt.
Sie führt aber dazu, daß der Code besser zu verstehen ist, daher besser bearbeitet werden kann und damit besser
zu warten ist. "Lesbarkeit" bleibt ein Kernzeil des Qualitäts-Suchenden und er wird sich die Frage bei jeder Code-Zeile
zu stellen haben.

{{quotation|Die Grenzen meiner Sprache sind die Grenzen meiner Welt}}

Im Kontext der Code-Qualität bedeutet das: So klar meine Sprache ist, so klar ist mein Code. Computer-Sprachen
(formale Sprachen überhaupt) lassen keine Mehrdeutigkeiten zu. Wird der gleiche Code bei mehrfacher Ausführung
unterschiedlich interpretiert, so ist das ein Fehler. Eine klare Ausdrucksweise, als Ausdruck klarer Gedanken ist
eine Grundvoraussetzung klaren Programm-Codes.

{{quotation|Separation of Concerns}}

ToDo: Erklärung wie die Idee von Dijkstraa als Leitgedanke zu verstehen ist

= Regeln =
Eine Regel ist eine Richtlinie die vermittelt was man tun – oder lassen – sollte, aber nicht vorgeben wie man das erreicht.
Regeln weisen die Richtung, bestimmen den Generalkurs; bieten aber wenig Hilfe bei der Überwindung konkreter Hindernisse.
Regeln sind keine Naturgesetze; es liegt in ihrer Natur, daß man auch von ihnen abweichen kann.
Es ist wichtig, den Wert einer Regel zu erkennen und daran die Maßnahmen auszuwählen die sie unterstützen.

Die Abgrenzung von Regeln gegen best practices und auch gegen konkrete Maßnahmen ist nicht immer scharf auszumachen.
Aber bevor man sich in exegetische Schlachten begibt, sollte man sich immer fragen, worum es eigentlich geht.
Das Ziel ist klarer, handhabbarer Code, das zu erreichen ist jeder Weg erlaubt.
Das gilt im Übrigen auch für die Gewichtung von Regeln, Ideologie ist immer der falsche Weg -- egal wohin.

* DRY - [[Don't repeat yourself]]
* KISS – Keep it simple stupid [http://www.commitstrip.com/en/2018/10/29/only-the-penitent-coder-will-pass/ commitstrip]
** Ockhams Razor
** Law of Parsimony
** Principle of Least Surprise
* SoC – Separation of Concerns (im Sinne von Aufgaben-Trennung)
* YAGNI – You Aren't Gonna Need It [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Wikipedia]
* [[Cohesion|high cohesion/loose coupling]]
* OCP – Open/Closed Principle
* SRP – Single Responsibility Principle
* Don’t make me think/write your code for everybody
* IoC – Inversion of Control / Dependency Inversion
* Form follows Function – Pragmatismus vor Ästhetik
* ISP – Interface Segregation Principle
* Stick to the Paradigm
* Tell don't ask ([https://martinfowler.com/bliki/TellDontAsk.html Martin Fowler])

Was ist mit SOLID?

Robert C. Martin hat fünf Prinzipien (SRP, open/closed, Liskov, ISP, DI) zusammengefaßt und damit ein tolles backronym zu bilden. Ob man dieser Kollektion einen besonderen Wert zuordnen möchte oder nicht sei mal dahingestellt. Das Liskov-Prinzip wurde hier - wegen seiner Konkretheit - unten den best practices eingeordnet. Die Frage wie man IoC und DI beschreibt und gegen einander abgrenzt ist noch zu diskutieren.

= Best Practice =
Best Practices – auch Heuristiken genannt – sind Techniken oder Vorgehensweisen, die sich in der Praxis in irgendeiner Form
und iregndeiner Situation bewährt haben. Meist lassen sie Gestaltungsspielraum, wenn es um die konkrete Anwendung geht – die
Abgrenzung zwischen einer konkreten Regel und einer allgemeinen Heuristik ist fließend. Und man sollte immer bedenken,
daß best practices in der Regel aus konkreten Situationen heraus entstanden sind und nicht auf jede beliebige Situation übertragbar sind -- dazu giebt es unten ein Antipattern.

* Clean Code (hier nur einige Heuristiken, die sich bei ''meiner'' Arbeit bewährt haben)
** Jeder Bezeichner soll exakt beschreiben, was das Bezeichnete tut oder enthält
** Eine Methode soll eine Wert liefern oder etwas tun, aber nicht beides
** Methoden (auch Konstruktoren) soll nicht mehr als drei Parameter haben
** Death to Magic numbers
** saubere Bezeichner sind besser als gute Kommentare sind besser als keine Kommentare sind besser als falsche Kommentare
** Eine Methode – eine Aufgabe
** lokale Variablen dort deklarieren, wo sie gebraucht werden
* Kent Beck's Design Rules (according to [http://martinfowler.com/bliki/BeckDesignRules.html Martin Fowler])
** Passes the Tests
** Reveals intention
** No Duplication
** Fewest Elements
* DI – Dependency Injection (als Implementierung von IoC)
* LSP - Liskov substitution principle
* Demeter-Prinzip
* Trennung von Abstraktions-Ebenen
* Trennung von Interface und Implementierung siehe dazu auch: Bridge-Pattern
* Interfaces sollen so schmal wie möglich sein und nur das enthalten was tatsächlich erforderlich ist.
* verwende Architektur-Pattern
* verwende das Schichten-Modell
* Integration Operation Segregation Principle (nach unten scrollen: [http://clean-code-developer.de/die-grade/roter-grad/#Integration_Operation_Segregation_Principle_IOSP IOSP])
* verwende Design-Pattern (hier einige GoF-Pattern, die ich besonders häufig verwende)
** Factory Method
** Adapter
** (simplified) Builder
** Singleton
** Proxy
** Facade
** Decorator
* Delegation statt Vererbung (Delegation wird im GoF-Buch nicht als Pattern sondern als Konzept beschrieben)
* Ein Konzept – ein Begriff
::Bsp: die eMail-Adresse sollte im Code nicht durcheinander als "eMail_Adresse", "mail-Adresse", "mail", "eMail" oder sonstwie bezeichnet werden, sondern immer gleich
* vermeide Antipattern
** [https://en.wikipedia.org/wiki/Interface_bloat Interface bloat] -- Interfaces verlangen mehr als erforderlich
** [https://en.wikipedia.org/wiki/Inner-platform_effect Inner-platform effect] – Das System erlaubt soviel Customization, daß eine schlechte Plattform daraus geworden ist.
** [https://en.wikipedia.org/wiki/Constant_interface Constant Interface] -- Interfaces dienen nur der Definition von Konstanten
** [https://en.wikipedia.org/wiki/Sequential_coupling Sequential coupling] -– Die Klasse verlangt den Aufruf ihrer Methoden in einer bestimmten Reihenfolge
** [https://en.wikipedia.org/wiki/Cargo_cult_programming Cargo cult programming] -– Pattern und Methoden verwenden ohne sie zu verstehen
** [https://en.wikipedia.org/wiki/Golden_hammer Golden hammer] / [https://en.wikipedia.org/wiki/No_Silver_Bullet Silver bullet] -– Alle Probleme mit der gleichen (Lieblings-)Methode lösen
** Base Bean – Vererbung soll is-a-Beziehungen abbilden, nicht has-a
** Stellvertreter-Typen – Statt einen Datentyp zu definieren, existierende Klassen (besonders String) mißbrauchen
** [[Petting Zoo]] - keeping code that is not worth it
* vermeide [[Code Smell]]s
* führe regelmäßig Refactoring durch
* Verwende eine durchgehende Nomenklatur
* Stick to the Coding Guidelines
* Das gleiche Problem sollte immer auf gleiche Art und Weise gelöst werden
* Verwende für Kommentare und Bezeichner nur natürliche Sprachen die Du auch beherrschst
:actualValue für den aktuellen Wert (richtig ist current)
:bound als Übersetzung für "verknüpft" (richtig ist linked)
* Don't state the obvious:
{{java|code=
Logger logger = LoggerFactory.obtainLogger();
String stringToBeLogged = "log: logging start of action Foo";
logger.log(stringToBeLogged);
}}

* {{java|toString()}} ist kein Serialisierungs-Tool
* zu viel von etwas ist selten gut:
: <q>If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help.</q>
:([https://en.wikipedia.org/wiki/Michael_A._Padlipsky Michael Padlipsky])

= Hilfsmittel =
Entgegen anderslautender Meinungen erhöht der Einsatz von Tools nicht automatisch die Qualität. Das Berechnen von Werten anhand von Metriken beispielsweise trägt zunächst gar nichts zur Qualität bei, erst die Auswertung und das Durchführen von Maßnahmen zur Änderung der Werte kann als qualitätsstiftende Maßnahme gelten. Nichtsdestotrotz unterstützt die Verwendung von Hilfsmitteln den Entwickler dabei den Weg zum Code hoher Qualität zu beschreiten.

* automatisch durchgeführte Unit-Tests
:Unit-Tests als "Tool" zu beschreiben mag seltsam klingen. Tatsächlich sind Unit-Tests aber nicht Teil des produktiven Codes und daher kann man mit Fug und Recht von einem Tool sprechen.
* Metriken
* Tools zur Code-Analyse (sonar, java-Compiler-Warnings)
* Tools zur Messung der Test-Abdeckung (EclEmma)
* Automatische Code-Formatierung (Eclipse Code Formatter)
* Coding-Guidelines
* [http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html Sun Code Conventions]
:Sie werden seit 1999 nicht mehr gepflegt. Einige Regeln sind überholt, andere zweifelhaft (z.B. 6.2: Variablen-Deklarationen nur am Beginn eines Code-Blocks plazieren), Sie bilden aber die Grundlage für das Code-Layout und man sollte sie kennen und berücksichtigen. 
:(Fun fact: Der Autor hat anscheinend von C abgeschrieben – es sind tatsächlich ein paar Fehler im Dokument)
* Refactoring-Tools (IDEs wie Eclipse bringen eine Menge davon mit

= Arbeitstechniken =
Die klassische Technik des Entwicklers ist das Zurückziehen hinter die Tastatur. Der Entwickler kriecht erst hervor, wenn das Werk vollendet ist. Das beschreibt einen Teil der Tätigkeit, reicht aber schon seit einem halben Jahrhundert nicht mehr aus. Und auch die Handgriffe, mit denen der Entwickler im stillen Kämmerlein den Wandel von Buchstaben in Code vollzieht wandeln sich im Laufe der Zeit. Man muß nicht jede Technik übernehmen, aber man sollte sich damit befassen und zumindest genau wissen, warum man sie nicht einsetzt.

* [[Boy Scout Principle]]
* Code – fremden und eigenen – lesen und reflektieren
* zuhören
* Diskussion über Code
* Code-Reviews
* XP – extreme Programming
** TDD – Test Driven Development
** Test First Ansatz
** Pair Programming
** Root Cause Analysis
** Incremental Design
* Embrace the CATSAN method
* Programming by Difference (→ Michael Feathers)
* Rubber Duck Debugging
* Technologische Schulden minimieren

= Literatur =
* Edsger Dijkstra [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html On the role of scientific thought]
* Refactoring: Improving the Design of Existing Code (Martin Fowler/Kent Beck)
* Working Effectively with Legacy Code (Michael C. Feathers)
* Clean Code (Robert C. Martin)
* Design Patterns: Elements of Reusable Object-Oriented Software (Gamma/Helm/Vlissides/Johnson)
* The Mythical Man Month (Fred Brooks)
* The Systems Bible – 3rd edition of "Systemantics" (John Gall) [https://en.wikipedia.org/wiki/Systemantics Überblick in der Wikipedia]
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjKitDwvJ3NAhXFKMAKHQ0hBWEQFggpMAE&url=http%3A%2F%2Fworrydream.com%2Frefs%2FBrooks-NoSilverBullet.pdf&usg=AFQjCNGkOYvU4WQgqaHGAqGgicO0XTRcw&bvm=bv.124088155,d.bGg No Silver Bullet] (Fred Brooks)
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiWtayRvZ3NAhUMDMAKHe_JDCYQFggcMAA&url=http%3A%2F%2Fhomepages.cwi.nl%2F~storm%2Fteaching%2Freader%2FDijkstra68.pdf&usg=AFQjCNFIgAgWJ_Aoph79yl9-tFusEGgglQ Goto Considered Harmful] (Edsger Dijkstra)
* [http://clean-code-developer.de/ clean code developer site]
* [http://chris.beams.io/posts/git-commit/ Regeln für GIT-commit-Kommentare]
* [http://www.cs.yale.edu/homes/perlis-alan/quotes.html Epigramme von Alan Perlis]
* [https://www.heise.de/newsticker/meldung/John-Romero-Von-id-Softwares-Anfaengen-und-World-of-Warcraft-Sucht-3296840.html Programmier-Regeln von John Romero]
* [https://sourcemaking.com Gute Sammlung von Pattern, Anti-Pattern etc.]
* [https://xkcd.com/1926 Bad Code in XKCD]

= Zen =
Keine Richtlinien, keine Anweisungen, einfach Aussagen über die man nachdenken kann. Hier kann man beliebig hitzig diskutieren; wichtig ist nur, daß man darüber – möglichst unvoreingenommen – nachdenkt.

* Wer sich nicht klar ausdrückt, denkt auch nicht klar
* big bang features lead to big bang
* Software Engineering ist agnostisch
* Ein Beispiel beweist nichts, widerlegt aber alles – soviel zu TDD- und Test-Abdeckungs-Fetischismus
* Ist TDD die zeitgemäße Formulierung für "trial and error"?
* Wenn Du weißt was Du tust, bist Du gesegnet
* If it ain't broken, don't fix it vs. Refactoring
* Verwende nur was Du auch verstehst ([https://xkcd.com/1597/ Wie XKCD GIT charakterisiert])
* Wer etwas ablehnt oder verteidigt sollte genau wissen warum
* Nichts hält so lange wie ein Provisorium
* Wer trennt schafft Abhängigkeiten, wer nicht trennt schafft Chaos
* Nichts ist so einfach, daß man es nicht falsch machen könnte
* Eine Entscheidung ist richtig, wenn sie rational begründet werden kann
* Was wert ist daß man es tut, ist wert daß man es richtig tut.
* Wenn man versucht Probleme auszusitzen, kriechen sie irgendwann hervor und treten einem in den Hintern

Der Weg zum guten Code

2024-11-28T10:27:55Z

Ullrich: /* Best Practice */

[[Category:Quality]]
Um entscheiden zu können welcher [https://xkcd.com/844/ Weg zum guten Code] führt, muß man festlegen was
''guten'' Code von schlechtem unterscheidet. Die Erkenntnis, daß es nicht gleichgültig ist, wie Code beschaffen
ist wurde ja offensichtlich schon gewonnen -- andernfalls wäre die Suche eine sinnlose.

"Gut" ist der Code, wenn er über die blanke Funktionalität hinaus weitere Eigenschaften erfüllt. Über diese
nichtfunktionalen Eigenschaften giebt es eine große Literatur, die Worte "Qualiät" und "Architektur" fallen einem in diesem
Zusammenhang ein. Dabei geht es aber in der Regel um die Software-Qualität, also die Qualität des gesamten Erzeugnisses
im Zusammenspiel mit der Umgebung in der es betrieben wird.

Diese Seite engt den Blick ganz bewußt auf den "Code" ein. Damit ist der Quelltext gemeint, aus dem das Erzeugnis
hergestellt wird. Noch genauer geht es dabei um den Programm-Code -- wann kann man diesen als "gut" bezeichnen?

Für den Entwickler -- den Einzigen, der ursächlich an der [https://xkcd.com/1695/ Code-Qualität] interessiert ist --
muß der Code wartbar, erweiterbar und änderbar sein. Der Grad ''dieser'' Eigenschaften bestimmt die Güte des Codes. Die Optimierung dieser Eigenschaften steht bisweilen im Widerspruch zu anderen Eigenschaften -- insbesondere der Performance.
Das Abwägen ist Aufgabe des Architekten und liegt außerhalb des Scope dieses Textes; hier geht es ausschließlich darum
die Code-Qualität zu verbessern.

Es giebt eine unüberschaubare Fülle an Regeln, Tipps, Techniken und Ideologien zum Thema. Nahezu jeder Entwickler,
den man zum Thema Code-Qualität befragt weiß einen anderen Strauß aus seinen Erfahrungen zu binden.

Aus dem Wunsch heraus, einen Überblick über die verwirrende Vielzahl von Begriffe, Ansichten und Ansätzen zu gewinnen
ist die untige Sammlung entstanden. Sie ist weder vollständig noch verbindlich, bietet dem interessierten Leser aber
eine Basis für die weitere Erkundung der Materie. Es wird zwar der Versuch eine Einteilung gemacht um den Überblick zu
verbessern, aber es wird versucht zu vermeiden eine Wertung vorzunehmen.

= Leitgedanken =
Ein Leitgedanke zu dem es bislang noch kein vernünftiges Gegenargument giebt ist folgender:
{{quotation|Die Qualität von Code bemißt sich daran, wie leicht er zu lesen ist}}
Über die Frage, wie "lesbarer" Code konkret auszusehen hat giebt es allerdings unterschiedliche Auffassungen.
Daraus kann man auch ableiten, daß bessere Lesbarkeit nicht automatisch zu besserer Änderbarkeit führt.
Sie führt aber dazu, daß der Code besser zu verstehen ist, daher besser bearbeitet werden kann und damit besser
zu warten ist. "Lesbarkeit" bleibt ein Kernzeil des Qualitäts-Suchenden und er wird sich die Frage bei jeder Code-Zeile
zu stellen haben.

{{quotation|Die Grenzen meiner Sprache sind die Grenzen meiner Welt}}

Im Kontext der Code-Qualität bedeutet das: So klar meine Sprache ist, so klar ist mein Code. Computer-Sprachen
(formale Sprachen überhaupt) lassen keine Mehrdeutigkeiten zu. Wird der gleiche Code bei mehrfacher Ausführung
unterschiedlich interpretiert, so ist das ein Fehler. Eine klare Ausdrucksweise, als Ausdruck klarer Gedanken ist
eine Grundvoraussetzung klaren Programm-Codes.

{{quotation|Separation of Concerns}}

ToDo: Erklärung wie die Idee von Dijkstraa als Leitgedanke zu verstehen ist

= Regeln =
Eine Regel ist eine Richtlinie die vermittelt was man tun – oder lassen – sollte, aber nicht vorgeben wie man das erreicht.
Regeln weisen die Richtung, bestimmen den Generalkurs; bieten aber wenig Hilfe bei der Überwindung konkreter Hindernisse.
Regeln sind keine Naturgesetze; es liegt in ihrer Natur, daß man auch von ihnen abweichen kann.
Es ist wichtig, den Wert einer Regel zu erkennen und daran die Maßnahmen auszuwählen die sie unterstützen.

Die Abgrenzung von Regeln gegen best practices und auch gegen konkrete Maßnahmen ist nicht immer scharf auszumachen.
Aber bevor man sich in exegetische Schlachten begibt, sollte man sich immer fragen, worum es eigentlich geht.
Das Ziel ist klarer, handhabbarer Code, das zu erreichen ist jeder Weg erlaubt.
Das gilt im Übrigen auch für die Gewichtung von Regeln, Ideologie ist immer der falsche Weg -- egal wohin.

* DRY - [[Don't repeat yourself]]
* KISS – Keep it simple stupid [http://www.commitstrip.com/en/2018/10/29/only-the-penitent-coder-will-pass/ commitstrip]
** Ockhams Razor
** Law of Parsimony
** Principle of Least Surprise
* SoC – Separation of Concerns (im Sinne von Aufgaben-Trennung)
* YAGNI – You Aren't Gonna Need It [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Wikipedia]
* [[Cohesion|high cohesion/loose coupling]]
* OCP – Open/Closed Principle
* SRP – Single Responsibility Principle
* Don’t make me think/write your code for everybody
* IoC – Inversion of Control / Dependency Inversion
* Form follows Function – Pragmatismus vor Ästhetik
* ISP – Interface Segregation Principle
* Stick to the Paradigm
* Tell don't ask ([https://martinfowler.com/bliki/TellDontAsk.html Martin Fowler])

Was ist mit SOLID?

Robert C. Martin hat fünf Prinzipien (SRP, open/closed, Liskov, ISP, DI) zusammengefaßt und damit ein tolles backronym zu bilden. Ob man dieser Kollektion einen besonderen Wert zuordnen möchte oder nicht sei mal dahingestellt. Das Liskov-Prinzip wurde hier - wegen seiner Konkretheit - unten den best practices eingeordnet. Die Frage wie man IoC und DI beschreibt und gegen einander abgrenzt ist noch zu diskutieren.

= Best Practice =
Best Practices – auch Heuristiken genannt – sind Techniken oder Vorgehensweisen, die sich in der Praxis in irgendeiner Form
und iregndeiner Situation bewährt haben. Meist lassen sie Gestaltungsspielraum, wenn es um die konkrete Anwendung geht – die
Abgrenzung zwischen einer konkreten Regel und einer allgemeinen Heuristik ist fließend. Und man sollte immer bedenken,
daß best practices in der Regel aus konkreten Situationen heraus entstanden sind und nicht auf jede beliebige Situation übertragbar sind -- dazu giebt es unten ein Antipattern.

* Clean Code (hier nur einige Heuristiken, die sich bei ''meiner'' Arbeit bewährt haben)
** Jeder Bezeichner soll exakt beschreiben, was das Bezeichnete tut oder enthält
** Eine Methode soll eine Wert liefern oder etwas tun, aber nicht beides
** Methoden (auch Konstruktoren) soll nicht mehr als drei Parameter haben
** Death to Magic numbers
** saubere Bezeichner sind besser als gute Kommentare sind besser als keine Kommentare sind besser als falsche Kommentare
** Eine Methode – eine Aufgabe
** lokale Variablen dort deklarieren, wo sie gebraucht werden
* Kent Beck's Design Rules (according to [http://martinfowler.com/bliki/BeckDesignRules.html Martin Fowler])
** Passes the Tests
** Reveals intention
** No Duplication
** Fewest Elements
* DI – Dependency Injection (als Implementierung von IoC)
* LSP - Liskov substitution principle
* Demeter-Prinzip
* Trennung von Abstraktions-Ebenen
* Trennung von Interface und Implementierung siehe dazu auch: Bridge-Pattern
* Interfaces sollen so schmal wie möglich sein und nur das enthalten was tatsächlich erforderlich ist.
* verwende Architektur-Pattern
* verwende das Schichten-Modell
* Integration Operation Segregation Principle (nach unten scrollen: [http://clean-code-developer.de/die-grade/roter-grad/#Integration_Operation_Segregation_Principle_IOSP IOSP])
* verwende Design-Pattern (hier einige GoF-Pattern, die ich besonders häufig verwende)
** Factory Method
** Adapter
** (simplified) Builder
** Singleton
** Proxy
** Facade
** Decorator
* Delegation statt Vererbung (Delegation wird im GoF-Buch nicht als Pattern sondern als Konzept beschrieben)
* Ein Konzept – ein Begriff
::Bsp: die eMail-Adresse sollte im Code nicht durcheinander als "eMail_Adresse", "mail-Adresse", "mail", "eMail" oder sonstwie bezeichnet werden, sondern immer gleich
* vermeide Antipattern
** [https://en.wikipedia.org/wiki/Interface_bloat Interface bloat] -- Interfaces verlangen mehr als erforderlich
** [https://en.wikipedia.org/wiki/Inner-platform_effect Inner-platform effect] – Das System erlaubt soviel Customization, daß eine schlechte Plattform daraus geworden ist.
** [https://en.wikipedia.org/wiki/Constant_interface Constant Interface] -- Interfaces dienen nur der Definition von Konstanten
** [https://en.wikipedia.org/wiki/Sequential_coupling Sequential coupling] -– Die Klasse verlangt den Aufruf ihrer Methoden in einer bestimmten Reihenfolge
** [https://en.wikipedia.org/wiki/Cargo_cult_programming Cargo cult programming] -– Pattern und Methoden verwenden ohne sie zu verstehen
** [https://en.wikipedia.org/wiki/Golden_hammer Golden hammer] / [https://en.wikipedia.org/wiki/No_Silver_Bullet Silver bullet] -– Alle Probleme mit der gleichen (Lieblings-)Methode lösen
** Base Bean – Vererbung soll is-a-Beziehungen abbilden, nicht has-a
** Stellvertreter-Typen – Statt einen Datentyp zu definieren, existierende Klassen (besonders String) mißbrauchen
** [[Petting Zoo]] - keeping code that is not worth it
* vermeide [[Code Smell]]s
* Refactoring
* Verwende eine durchgehende Nomenklatur
* Stick to the Coding Guidelines
* Das gleiche Problem sollte immer auf gleiche Art und Weise gelöst werden
* Verwende für Kommentare und Bezeichner nur natürliche Sprachen die Du auch beherrschst
:actualValue für den aktuellen Wert (richtig ist current)
* bound als Übersetzung für "verknüpft" (richtig ist linked)
* Don't state the obvious:
: Logger logger = LoggerFactory.obtainLogger();
: String stringToBeLogged = "log: logging start of action Foo";
: logger.log(stringToBeLogged);
* toString() ist kein Serialisierungs-Tool
* zu viel von etwas ist selten gut:
: <q>If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help.</q>
:([https://en.wikipedia.org/wiki/Michael_A._Padlipsky Michael Padlipsky])

= Hilfsmittel =
Entgegen anderslautender Meinungen erhöht der Einsatz von Tools nicht automatisch die Qualität. Das Berechnen von Werten anhand von Metriken beispielsweise trägt zunächst gar nichts zur Qualität bei, erst die Auswertung und das Durchführen von Maßnahmen zur Änderung der Werte kann als qualitätsstiftende Maßnahme gelten. Nichtsdestotrotz unterstützt die Verwendung von Hilfsmitteln den Entwickler dabei den Weg zum Code hoher Qualität zu beschreiten.

* automatisch durchgeführte Unit-Tests
:Unit-Tests als "Tool" zu beschreiben mag seltsam klingen. Tatsächlich sind Unit-Tests aber nicht Teil des produktiven Codes und daher kann man mit Fug und Recht von einem Tool sprechen.
* Metriken
* Tools zur Code-Analyse (sonar, java-Compiler-Warnings)
* Tools zur Messung der Test-Abdeckung (EclEmma)
* Automatische Code-Formatierung (Eclipse Code Formatter)
* Coding-Guidelines
* [http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html Sun Code Conventions]
:Sie werden seit 1999 nicht mehr gepflegt. Einige Regeln sind überholt, andere zweifelhaft (z.B. 6.2: Variablen-Deklarationen nur am Beginn eines Code-Blocks plazieren), Sie bilden aber die Grundlage für das Code-Layout und man sollte sie kennen und berücksichtigen. 
:(Fun fact: Der Autor hat anscheinend von C abgeschrieben – es sind tatsächlich ein paar Fehler im Dokument)
* Refactoring-Tools (IDEs wie Eclipse bringen eine Menge davon mit

= Arbeitstechniken =
Die klassische Technik des Entwicklers ist das Zurückziehen hinter die Tastatur. Der Entwickler kriecht erst hervor, wenn das Werk vollendet ist. Das beschreibt einen Teil der Tätigkeit, reicht aber schon seit einem halben Jahrhundert nicht mehr aus. Und auch die Handgriffe, mit denen der Entwickler im stillen Kämmerlein den Wandel von Buchstaben in Code vollzieht wandeln sich im Laufe der Zeit. Man muß nicht jede Technik übernehmen, aber man sollte sich damit befassen und zumindest genau wissen, warum man sie nicht einsetzt.

* [[Boy Scout Principle]]
* Code – fremden und eigenen – lesen und reflektieren
* zuhören
* Diskussion über Code
* Code-Reviews
* XP – extreme Programming
** TDD – Test Driven Development
** Test First Ansatz
** Pair Programming
** Root Cause Analysis
** Incremental Design
* Embrace the CATSAN method
* Programming by Difference (→ Michael Feathers)
* Rubber Duck Debugging
* Technologische Schulden minimieren

= Literatur =
* Edsger Dijkstra [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html On the role of scientific thought]
* Refactoring: Improving the Design of Existing Code (Martin Fowler/Kent Beck)
* Working Effectively with Legacy Code (Michael C. Feathers)
* Clean Code (Robert C. Martin)
* Design Patterns: Elements of Reusable Object-Oriented Software (Gamma/Helm/Vlissides/Johnson)
* The Mythical Man Month (Fred Brooks)
* The Systems Bible – 3rd edition of "Systemantics" (John Gall) [https://en.wikipedia.org/wiki/Systemantics Überblick in der Wikipedia]
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjKitDwvJ3NAhXFKMAKHQ0hBWEQFggpMAE&url=http%3A%2F%2Fworrydream.com%2Frefs%2FBrooks-NoSilverBullet.pdf&usg=AFQjCNGkOYvU4WQgqaHGAqGgicO0XTRcw&bvm=bv.124088155,d.bGg No Silver Bullet] (Fred Brooks)
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiWtayRvZ3NAhUMDMAKHe_JDCYQFggcMAA&url=http%3A%2F%2Fhomepages.cwi.nl%2F~storm%2Fteaching%2Freader%2FDijkstra68.pdf&usg=AFQjCNFIgAgWJ_Aoph79yl9-tFusEGgglQ Goto Considered Harmful] (Edsger Dijkstra)
* [http://clean-code-developer.de/ clean code developer site]
* [http://chris.beams.io/posts/git-commit/ Regeln für GIT-commit-Kommentare]
* [http://www.cs.yale.edu/homes/perlis-alan/quotes.html Epigramme von Alan Perlis]
* [https://www.heise.de/newsticker/meldung/John-Romero-Von-id-Softwares-Anfaengen-und-World-of-Warcraft-Sucht-3296840.html Programmier-Regeln von John Romero]
* [https://sourcemaking.com Gute Sammlung von Pattern, Anti-Pattern etc.]
* [https://xkcd.com/1926 Bad Code in XKCD]

= Zen =
Keine Richtlinien, keine Anweisungen, einfach Aussagen über die man nachdenken kann. Hier kann man beliebig hitzig diskutieren; wichtig ist nur, daß man darüber – möglichst unvoreingenommen – nachdenkt.

* Wer sich nicht klar ausdrückt, denkt auch nicht klar
* big bang features lead to big bang
* Software Engineering ist agnostisch
* Ein Beispiel beweist nichts, widerlegt aber alles – soviel zu TDD- und Test-Abdeckungs-Fetischismus
* Ist TDD die zeitgemäße Formulierung für "trial and error"?
* Wenn Du weißt was Du tust, bist Du gesegnet
* If it ain't broken, don't fix it vs. Refactoring
* Verwende nur was Du auch verstehst ([https://xkcd.com/1597/ Wie XKCD GIT charakterisiert])
* Wer etwas ablehnt oder verteidigt sollte genau wissen warum
* Nichts hält so lange wie ein Provisorium
* Wer trennt schafft Abhängigkeiten, wer nicht trennt schafft Chaos
* Nichts ist so einfach, daß man es nicht falsch machen könnte
* Eine Entscheidung ist richtig, wenn sie rational begründet werden kann
* Was wert ist daß man es tut, ist wert daß man es richtig tut.
* Wenn man versucht Probleme auszusitzen, kriechen sie irgendwann hervor und treten einem in den Hintern

Boy Scout Principle

2024-11-28T10:24:18Z

Ullrich:

[[Category:Quality]]

= Motivation =
Zu den Regeln der Pfadfinderbewegung gehört der Satz:
{{quotation|Always leave the camp ground cleaner than you found it.}}
oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:
{{quotation|Try and leave this world a little better than you found it.}}
In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):
Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren
Müll hinzuzufügen.
Dieses Phänomen wurde in den 80er Jahren als "Broken Window Effect" beschrieben.
Aber was hat das nun mit Software Engineering zu tun?
Zum Äquivalent des Broken Windows Effect im Software Engineering ist hier recht nett beschrieben
(da ist wohl ein Link verloren gegangen).
Um dessen Vermeidung und die Frage was man statt dessen für die Software-Qualität tun kann soll es im Folgenden gehen.

== Über das Problem ==
Wer lange genug programmiert hat, weiß wie schlimm schlechter Code aussehen kann. Und immer wenn man
denkt man hat schon alles gesehen tritt man in eine Java-Klasse die alles dagewesene in den Schatten stellt. Der
erste Reflex ist meistens "weg damit, alles neu machen". Man bezeichnet dieses Refactoring-Vorgehen auch mit
dem treffenden Namen "Big Bang". Die Umsetzung bereitet in der Praxis allerdings eine ganze Reihe von
Problemen. Das größte ist, daß eine umfassende Refactoring-Maßnahme Aufwände generiert die aus keinem
Budget zu bekommen sind. Das liegt nicht nur an knausrigen Budget-Verwaltern, das liegt auch in der Natur der
Entstehung solcher Code-Höllen. Wer sich beim Codieren nicht um die Qualität kümmert schafft technologische
Schulden, für die keine Deckung existiert und für die in der Regel keine Rücklagen gebildet werden. So kommt Müll
zu Müll und aus kleinen dreckigen Code-Ecken werden langsam aber sicher riesige Müllhalden.
Ein anderes Problem verbirgt sich hinter der Metapher vom Abreißen und Neuaufbau des Systems. Diese aus dem
Hausbau stammende Metapher läßt sich nicht eins zu eins auf die Software-Entwicklung übertragen. Denn das
neue System wird ja nicht einfach aus "neuem" Material gebaut, sondern soll die Substanz des abgerissenen
Systems wiederverwerten. Oder auf den Code bezogen: Die Business-Logik, die sich im Müllhaufen verbirgt – und
das ist ja das eigentliche Kapital der Software, das was das System wertvoll macht – muß erhalten bleiben. Das
funktioniert – vielleicht – wenn man eine exzellente und erschöpfende Dokumentation des Systems hat die genau
die im System enthaltene Fachlichkeit dokumentiert, aber zu welchem System hat man eine solche
Dokumentation?

Der einzige Weg ist dann das akribsche Analysieren des bestehenden Codes und das Übertragen in die neue
Anwendung. Und da es sich um eine vollständige Neuentwicklung handelt muß jede Zeile im Rahmen der
Neuentwicklung untersucht werden; dazu gehört veralteter, nicht mehr verwendeter Code ebenso wie Code-
Gewölle deren Analyse aufgrund der Komplizierteit sehr zeitaufwändig ist. Es gibt keine Möglichkeit, auf
irgendeinen Teil dieser Analyse zu verzichten, denn mit der Migration muß sämtliche Funktionalität übertragen
werden. Sei sie nun offensichtlich oder unter hunderten verschachtelter Klassen vergraben.
Damit ist in vielen Fällen das Migrationsprojekt mangels Budget gestorben. Und weil die Komplettlösung nicht
umsetzbar ist, passiert meistens gar nichts. Dabei muß noch nicht einmal die gesamte Anwendung betroffen sein,
Oft geht es nur darum wesentliche Teile einem Refactoring zu unterziehen, was dann – Budget! Budget! – ebenfalls
nicht geschieht.

= Über die Lösung =
Wenn also der Big-Bang-Ansatz nicht durchführbar ist, was dann? Die kleine, mühsamere und weniger beglückende
Lösung ist der Weg der kleine Schritte. Und wenn man vor lauter Chaos nicht weiß wo anfangen, fängt man am
besten da an wo man gerade steht: Wann immer der Entwickler ein Stück Code bearbeitet oder reviewt – und sei es
noch so klein – dann habe er dabei immer die Frage im Hinterkopf
: Was kann ich hier ohne viel Aufwand besser machen?
Das scheint erstmal für lange Zeit gar nichts zu bringen und es ersetzt auch nicht das kostenintensive
Refactoring größerer Programmteile – besonders, wenn die Architektur Probleme verursacht – aber es hilft auf
lange Sicht Aufwände zu senken und kann den Code so vorbereiten, daß große Refactoring-Maßnahmen überhaupt
erst möglich werden.

= Was kann man konkret tun? =
Erlaubt ist alles, was die Code-Qualität verbessert, dabei aber die Funktionalität nicht beeinträchtigt und solange
man die Schnittstellen nicht anfaßt, ist praktisch alles erlaubt.
* Unit-Tests schreiben
* Dokumentation schreiben
* Kommentare korrigieren und ergänzen
* Methoden- und Klassennamen umbenennen
* Toten und auskommentierten Code entfernen
* Literale durch Konstanten und Konstanten durch Enums ersetzen
* Zweifelhafte Stellen als TODO oder FIXME markieren
* Ungenutzte Teile als "deprecated" markieren
* Code-Blöcke in Methoden auslagern
* Mehrfach verwendete Blöcke in Klassen auslagern
* if-Bedingungen umformen
* ...

= Worauf sollte man achten? =
Entscheidend ist, daß durch das Refactoring nichts kaputt geht. Bevor man also anfängt den Code umzukrempeln
muß man sich darüber klar werden, welche Auswirkung die Änderung hat. Wenn kein eigenes und ausreichendes
Budget für die Überarbeitung zur Verfügung steht, gestaltet man die Änderungen so defensiv wie möglich. Am
besten sichert man die Änderungen immer durch automatische Unit-Tests ab.

Aus diesem Grunde stehen die Unit-Tests in der Aufzählung oben auch ganz oben. Jeder Entwickler sollte immer
alles durch Unit-Tests abdecken – so die Theorie. Die Erhöhung der Testabdeckung ändert zwar überhaupt nichts
an der Code-Qualität, ist aber trotzdem sehr wertvoll. Tests sichern den Code gegen Änderungen ab. Bei der
nächsten Änderung, Erweiterung oder dem nächsten Refactoring merkt man hoffentlich sofort, wenn etwas kaputt
gegangen ist.

Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar
{{quotation|To me, ''legacy code'' is simply code without tests}}

= Noch was? =
Der brave Pfadfinder kümmert sich nicht darum, wer nach ihm kommt. Er sorgt einfach dafür, daß sich der Nächste
wohler fühlt wenn er sein Zelt aufschlägt. Wenn er aber weiß, daß demnächst eine große Gruppe zum Camping
anrückt, dann kann er – mit seinen Genossen – schon mal vorarbeiten. Was heißt das für den Softwerker?
Wenn man weiß, daß irgendwann die großen Refactorings anstehen, daß zum Beispiel das Datenbank-Modell
überholt wird oder ein anderes Framework verwendet werden soll; wenn man also planvoll auf irgendetwas hinarbeiten
möchte, dann kann man die Reinigungsarbeiten schon vorneweg in die richtige Richtung lenken. Hierzu konkrete
Anweisungen vorzugeben ist schwierig, am besten setzt man sich mit dem Team mal hin und überlegt, welches die
schlimmsten Probleme sind, wie man sie beseitigen möchte und wie man da hinkommen kann.

Dazu ein einfaches Beispiel:

Sind beispielsweise Zugriffe auf eine bestimmtes Modul (eine Datenbank oder ein Service) überall im Code verteilt
und auf unterschiedliche Weise implementiert, kann man ein Interface definieren, bei der nächsten Gelegenheit
den ersten Zugriff aus dem Code lösen, damit das Interface mit einer Klasse unterfüttern und verwenden. Kommt
der nächste Entwickler an anderer Stelle auf einen ähnlichen Zugriff, übernimmt er entweder die Implementierung
seines Vorgängers oder er implemetiert eine neue Klasse für das Interface und stellt sie neben die erste.
Irgendwann – wenn zeit ist – nimmt man sich die verschiedenen Implementierungen der Interface vor und konsolidiert die
Implementierungen.

Boy Scout Principle

2024-11-28T10:23:38Z

Ullrich:

[[Category:Quality]]

= Motivation =
Zu den Regeln der Pfadfinderbewegung gehört der Satz:
{quotation|Always leave the camp ground cleaner than you found it.}
oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:
{quotation|Try and leave this world a little better than you found it.}
In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):
Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren
Müll hinzuzufügen.
Dieses Phänomen wurde in den 80er Jahren als "Broken Window Effect" beschrieben.
Aber was hat das nun mit Software Engineering zu tun?
Zum Äquivalent des Broken Windows Effect im Software Engineering ist hier recht nett beschrieben
(da ist wohl ein Link verloren gegangen).
Um dessen Vermeidung und die Frage was man statt dessen für die Software-Qualität tun kann soll es im Folgenden gehen.

== Über das Problem ==
Wer lange genug programmiert hat, weiß wie schlimm schlechter Code aussehen kann. Und immer wenn man
denkt man hat schon alles gesehen tritt man in eine Java-Klasse die alles dagewesene in den Schatten stellt. Der
erste Reflex ist meistens "weg damit, alles neu machen". Man bezeichnet dieses Refactoring-Vorgehen auch mit
dem treffenden Namen "Big Bang". Die Umsetzung bereitet in der Praxis allerdings eine ganze Reihe von
Problemen. Das größte ist, daß eine umfassende Refactoring-Maßnahme Aufwände generiert die aus keinem
Budget zu bekommen sind. Das liegt nicht nur an knausrigen Budget-Verwaltern, das liegt auch in der Natur der
Entstehung solcher Code-Höllen. Wer sich beim Codieren nicht um die Qualität kümmert schafft technologische
Schulden, für die keine Deckung existiert und für die in der Regel keine Rücklagen gebildet werden. So kommt Müll
zu Müll und aus kleinen dreckigen Code-Ecken werden langsam aber sicher riesige Müllhalden.
Ein anderes Problem verbirgt sich hinter der Metapher vom Abreißen und Neuaufbau des Systems. Diese aus dem
Hausbau stammende Metapher läßt sich nicht eins zu eins auf die Software-Entwicklung übertragen. Denn das
neue System wird ja nicht einfach aus "neuem" Material gebaut, sondern soll die Substanz des abgerissenen
Systems wiederverwerten. Oder auf den Code bezogen: Die Business-Logik, die sich im Müllhaufen verbirgt – und
das ist ja das eigentliche Kapital der Software, das was das System wertvoll macht – muß erhalten bleiben. Das
funktioniert – vielleicht – wenn man eine exzellente und erschöpfende Dokumentation des Systems hat die genau
die im System enthaltene Fachlichkeit dokumentiert, aber zu welchem System hat man eine solche
Dokumentation?

Der einzige Weg ist dann das akribsche Analysieren des bestehenden Codes und das Übertragen in die neue
Anwendung. Und da es sich um eine vollständige Neuentwicklung handelt muß jede Zeile im Rahmen der
Neuentwicklung untersucht werden; dazu gehört veralteter, nicht mehr verwendeter Code ebenso wie Code-
Gewölle deren Analyse aufgrund der Komplizierteit sehr zeitaufwändig ist. Es gibt keine Möglichkeit, auf
irgendeinen Teil dieser Analyse zu verzichten, denn mit der Migration muß sämtliche Funktionalität übertragen
werden. Sei sie nun offensichtlich oder unter hunderten verschachtelter Klassen vergraben.
Damit ist in vielen Fällen das Migrationsprojekt mangels Budget gestorben. Und weil die Komplettlösung nicht
umsetzbar ist, passiert meistens gar nichts. Dabei muß noch nicht einmal die gesamte Anwendung betroffen sein,
Oft geht es nur darum wesentliche Teile einem Refactoring zu unterziehen, was dann – Budget! Budget! – ebenfalls
nicht geschieht.

= Über die Lösung =
Wenn also der Big-Bang-Ansatz nicht durchführbar ist, was dann? Die kleine, mühsamere und weniger beglückende
Lösung ist der Weg der kleine Schritte. Und wenn man vor lauter Chaos nicht weiß wo anfangen, fängt man am
besten da an wo man gerade steht: Wann immer der Entwickler ein Stück Code bearbeitet oder reviewt – und sei es
noch so klein – dann habe er dabei immer die Frage im Hinterkopf
: Was kann ich hier ohne viel Aufwand besser machen?
Das scheint erstmal für lange Zeit gar nichts zu bringen und es ersetzt auch nicht das kostenintensive
Refactoring größerer Programmteile – besonders, wenn die Architektur Probleme verursacht – aber es hilft auf
lange Sicht Aufwände zu senken und kann den Code so vorbereiten, daß große Refactoring-Maßnahmen überhaupt
erst möglich werden.

= Was kann man konkret tun? =
Erlaubt ist alles, was die Code-Qualität verbessert, dabei aber die Funktionalität nicht beeinträchtigt und solange
man die Schnittstellen nicht anfaßt, ist praktisch alles erlaubt.
* Unit-Tests schreiben
* Dokumentation schreiben
* Kommentare korrigieren und ergänzen
* Methoden- und Klassennamen umbenennen
* Toten und auskommentierten Code entfernen
* Literale durch Konstanten und Konstanten durch Enums ersetzen
* Zweifelhafte Stellen als TODO oder FIXME markieren
* Ungenutzte Teile als "deprecated" markieren
* Code-Blöcke in Methoden auslagern
* Mehrfach verwendete Blöcke in Klassen auslagern
* if-Bedingungen umformen
* ...

= Worauf sollte man achten? =
Entscheidend ist, daß durch das Refactoring nichts kaputt geht. Bevor man also anfängt den Code umzukrempeln
muß man sich darüber klar werden, welche Auswirkung die Änderung hat. Wenn kein eigenes und ausreichendes
Budget für die Überarbeitung zur Verfügung steht, gestaltet man die Änderungen so defensiv wie möglich. Am
besten sichert man die Änderungen immer durch automatische Unit-Tests ab.

Aus diesem Grunde stehen die Unit-Tests in der Aufzählung oben auch ganz oben. Jeder Entwickler sollte immer
alles durch Unit-Tests abdecken – so die Theorie. Die Erhöhung der Testabdeckung ändert zwar überhaupt nichts
an der Code-Qualität, ist aber trotzdem sehr wertvoll. Tests sichern den Code gegen Änderungen ab. Bei der
nächsten Änderung, Erweiterung oder dem nächsten Refactoring merkt man hoffentlich sofort, wenn etwas kaputt
gegangen ist.

Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar
{quotation|To me, ''legacy code'' is simply code without tests}

= Noch was? =
Der brave Pfadfinder kümmert sich nicht darum, wer nach ihm kommt. Er sorgt einfach dafür, daß sich der Nächste
wohler fühlt wenn er sein Zelt aufschlägt. Wenn er aber weiß, daß demnächst eine große Gruppe zum Camping
anrückt, dann kann er – mit seinen Genossen – schon mal vorarbeiten. Was heißt das für den Softwerker?
Wenn man weiß, daß irgendwann die großen Refactorings anstehen, daß zum Beispiel das Datenbank-Modell
überholt wird oder ein anderes Framework verwendet werden soll; wenn man also planvoll auf irgendetwas hinarbeiten
möchte, dann kann man die Reinigungsarbeiten schon vorneweg in die richtige Richtung lenken. Hierzu konkrete
Anweisungen vorzugeben ist schwierig, am besten setzt man sich mit dem Team mal hin und überlegt, welches die
schlimmsten Probleme sind, wie man sie beseitigen möchte und wie man da hinkommen kann.

Dazu ein einfaches Beispiel:

Sind beispielsweise Zugriffe auf eine bestimmtes Modul (eine Datenbank oder ein Service) überall im Code verteilt
und auf unterschiedliche Weise implementiert, kann man ein Interface definieren, bei der nächsten Gelegenheit
den ersten Zugriff aus dem Code lösen, damit das Interface mit einer Klasse unterfüttern und verwenden. Kommt
der nächste Entwickler an anderer Stelle auf einen ähnlichen Zugriff, übernimmt er entweder die Implementierung
seines Vorgängers oder er implemetiert eine neue Klasse für das Interface und stellt sie neben die erste.
Irgendwann – wenn zeit ist – nimmt man sich die verschiedenen Implementierungen der Interface vor und konsolidiert die
Implementierungen.

Boy Scout Principle

2024-11-28T10:20:58Z

Ullrich: Die Seite wurde neu angelegt: „Category:Quality = Motivation = Zu den Regeln der Pfadfinderbewegung gehört der Satz: :<q>Always leave the camp ground cleaner than you found it.</q> oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat: :<q>Try and leave this world a little better than you found it.</q> In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen): Liegt irgendwo Müll herum, dann scheint da…“

[[Category:Quality]]

= Motivation =
Zu den Regeln der Pfadfinderbewegung gehört der Satz:
:<q>Always leave the camp ground cleaner than you found it.</q>
oder wie der Vater der Bewegung – Robert Baden Powell – es ausgedrückt hat:
:<q>Try and leave this world a little better than you found it.</q>
In der Realität herrscht die gegenteilige Praxis vor (oder eben die gleiche Praxis mit negativem Vorzeichen):
Liegt irgendwo Müll herum, dann scheint das die Menschen dazu zu animieren dem herumliegenden Müll weiteren
Müll hinzuzufügen.
Dieses Phänomen wurde in den 80er Jahren als "Broken Window Effect" beschrieben.
Aber was hat das nun mit Software Engineering zu tun?
Zum Äquivalent des Broken Windows Effect im Software Engineering ist hier recht nett beschrieben
(da ist wohl ein Link verloren gegangen).
Um dessen Vermeidung und die Frage was man statt dessen für die Software-Qualität tun kann soll es im Folgenden gehen.

== Über das Problem ==
Wer lange genug programmiert hat, weiß wie schlimm schlechter Code aussehen kann. Und immer wenn man
denkt man hat schon alles gesehen tritt man in eine Java-Klasse die alles dagewesene in den Schatten stellt. Der
erste Reflex ist meistens "weg damit, alles neu machen". Man bezeichnet dieses Refactoring-Vorgehen auch mit
dem treffenden Namen "Big Bang". Die Umsetzung bereitet in der Praxis allerdings eine ganze Reihe von
Problemen. Das größte ist, daß eine umfassende Refactoring-Maßnahme Aufwände generiert die aus keinem
Budget zu bekommen sind. Das liegt nicht nur an knausrigen Budget-Verwaltern, das liegt auch in der Natur der
Entstehung solcher Code-Höllen. Wer sich beim Codieren nicht um die Qualität kümmert schafft technologische
Schulden, für die keine Deckung existiert und für die in der Regel keine Rücklagen gebildet werden. So kommt Müll
zu Müll und aus kleinen dreckigen Code-Ecken werden langsam aber sicher riesige Müllhalden.
Ein anderes Problem verbirgt sich hinter der Metapher vom Abreißen und Neuaufbau des Systems. Diese aus dem
Hausbau stammende Metapher läßt sich nicht eins zu eins auf die Software-Entwicklung übertragen. Denn das
neue System wird ja nicht einfach aus "neuem" Material gebaut, sondern soll die Substanz des abgerissenen
Systems wiederverwerten. Oder auf den Code bezogen: Die Business-Logik, die sich im Müllhaufen verbirgt – und
das ist ja das eigentliche Kapital der Software, das was das System wertvoll macht – muß erhalten bleiben. Das
funktioniert – vielleicht – wenn man eine exzellente und erschöpfende Dokumentation des Systems hat die genau
die im System enthaltene Fachlichkeit dokumentiert, aber zu welchem System hat man eine solche
Dokumentation?

Der einzige Weg ist dann das akribsche Analysieren des bestehenden Codes und das Übertragen in die neue
Anwendung. Und da es sich um eine vollständige Neuentwicklung handelt muß jede Zeile im Rahmen der
Neuentwicklung untersucht werden; dazu gehört veralteter, nicht mehr verwendeter Code ebenso wie Code-
Gewölle deren Analyse aufgrund der Komplizierteit sehr zeitaufwändig ist. Es gibt keine Möglichkeit, auf
irgendeinen Teil dieser Analyse zu verzichten, denn mit der Migration muß sämtliche Funktionalität übertragen
werden. Sei sie nun offensichtlich oder unter hunderten verschachtelter Klassen vergraben.
Damit ist in vielen Fällen das Migrationsprojekt mangels Budget gestorben. Und weil die Komplettlösung nicht
umsetzbar ist, passiert meistens gar nichts. Dabei muß noch nicht einmal die gesamte Anwendung betroffen sein,
Oft geht es nur darum wesentliche Teile einem Refactoring zu unterziehen, was dann – Budget! Budget! – ebenfalls
nicht geschieht.

= Über die Lösung =
Wenn also der Big-Bang-Ansatz nicht durchführbar ist, was dann? Die kleine, mühsamere und weniger beglückende
Lösung ist der Weg der kleine Schritte. Und wenn man vor lauter Chaos nicht weiß wo anfangen, fängt man am
besten da an wo man gerade steht: Wann immer der Entwickler ein Stück Code bearbeitet oder reviewt – und sei es
noch so klein – dann habe er dabei immer die Frage im Hinterkopf
: Was kann ich hier ohne viel Aufwand besser machen?
Das scheint erstmal für lange Zeit gar nichts zu bringen und es ersetzt auch nicht das kostenintensive
Refactoring größerer Programmteile – besonders, wenn die Architektur Probleme verursacht – aber es hilft auf
lange Sicht Aufwände zu senken und kann den Code so vorbereiten, daß große Refactoring-Maßnahmen überhaupt
erst möglich werden.

= Was kann man konkret tun? =
Erlaubt ist alles, was die Code-Qualität verbessert, dabei aber die Funktionalität nicht beeinträchtigt und solange
man die Schnittstellen nicht anfaßt, ist praktisch alles erlaubt.
* Unit-Tests schreiben
* Dokumentation schreiben
* Kommentare korrigieren und ergänzen
* Methoden- und Klassennamen umbenennen
* Toten und auskommentierten Code entfernen
* Literale durch Konstanten und Konstanten durch Enums ersetzen
* Zweifelhafte Stellen als TODO oder FIXME markieren
* Ungenutzte Teile als "deprecated" markieren
* Code-Blöcke in Methoden auslagern
* Mehrfach verwendete Blöcke in Klassen auslagern
* if-Bedingungen umformen
* ...

= Worauf sollte man achten? =
Entscheidend ist, daß durch das Refactoring nichts kaputt geht. Bevor man also anfängt den Code umzukrempeln
muß man sich darüber klar werden, welche Auswirkung die Änderung hat. Wenn kein eigenes und ausreichendes
Budget für die Überarbeitung zur Verfügung steht, gestaltet man die Änderungen so defensiv wie möglich. Am
besten sichert man die Änderungen immer durch automatische Unit-Tests ab.

Aus diesem Grunde stehen die Unit-Tests in der Aufzählung oben auch ganz oben. Jeder Entwickler sollte immer
alles durch Unit-Tests abdecken – so die Theorie. Die Erhöhung der Testabdeckung ändert zwar überhaupt nichts
an der Code-Qualität, ist aber trotzdem sehr wertvoll. Tests sichern den Code gegen Änderungen ab. Bei der
nächsten Änderung, Erweiterung oder dem nächsten Refactoring merkt man hoffentlich sofort, wenn etwas kaputt
gegangen ist.

Nicht umsonst antwortet Michael Feathers auf die Frage "Was ist Legacy Code?" ganz lapidar
: Legacy code is code without unit tests

= Noch was? =
Der brave Pfadfinder kümmert sich nicht darum, wer nach ihm kommt. Er sorgt einfach dafür, daß sich der Nächste
wohler fühlt wenn er sein Zelt aufschlägt. Wenn er aber weiß, daß demnächst eine große Gruppe zum Camping
anrückt, dann kann er – mit seinen Genossen – schon mal vorarbeiten. Was heißt das für den Softwerker?
Wenn man weiß, daß irgendwann die großen Refactorings anstehen, daß zum Beispiel das Datenbank-Modell
überholt wird oder ein anderes Framework verwendet werden soll; wenn man also planvoll auf irgendetwas hinarbeiten
möchte, dann kann man die Reinigungsarbeiten schon vorneweg in die richtige Richtung lenken. Hierzu konkrete
Anweisungen vorzugeben ist schwierig, am besten setzt man sich mit dem Team mal hin und überlegt, welches die
schlimmsten Probleme sind, wie man sie beseitigen möchte und wie man da hinkommen kann.

Dazu ein einfaches Beispiel:

Sind beispielsweise Zugriffe auf eine bestimmtes Modul (eine Datenbank oder ein Service) überall im Code verteilt
und auf unterschiedliche Weise implementiert, kann man ein Interface definieren, bei der nächsten Gelegenheit
den ersten Zugriff aus dem Code lösen, damit das Interface mit einer Klasse unterfüttern und verwenden. Kommt
der nächste Entwickler an anderer Stelle auf einen ähnlichen Zugriff, übernimmt er entweder die Implementierung
seines Vorgängers oder er implemetiert eine neue Klasse für das Interface und stellt sie neben die erste.
Irgendwann – wenn zeit ist – nimmt man sich die verschiedenen Implementierungen der Interface vor und konsolidiert die
Implementierungen.

MediaWiki:Sidebar

2024-11-28T10:07:31Z

Ullrich:

Code Smell

2024-11-28T10:04:36Z

Ullrich:

[[Category:Quality]]
Die erste Erwähnung des Begriffs "code smell" findet sich in Martin Fowlers Buch "Refactoring". Er verwendet ihn
dort als es darum geht die Code-Stellen zu identifizieren an denen Refactoring erforderlich ist. Fowler bleibt dabei
ausgesprochen vage, aber die Andeutung auf verunreinigte Baby-Windeln erzeugt den starken Eindruck, daß es sich
hier um ausgesprochen unangenehme Gerüche handeln muß...

Ein Code Smell ist eine Stelle im Code mit bestimmten Eigenschaften, an denen sie zu erkennen ist. Diese
Eigenschaften bilden den bisweilen charakteristischen Geruch. Eine Methode mit einer langen Parameterliste ist ein Beispiel
dafür, mit jedem weiteren Parameter wird der Geruch intensiver.

Viele Code Smells haben eine Ursache. Eine lange Parameterliste zum Beispiel kann das Ergebnis sukzessiver
Verallgemeinerung sein. Die ursprüngliche Methode hatte vielleicht nur zwei Parameter, aber mit jeder Anpassung
an die geänderten Anforderungen kam ein neuer Parameter hinzu. Nicht jeder Smell hat eine klare Ursache, für
manche Smells gibt es mehrere mögliche Ursachen. In aller Regel ist es sinnvoll die Ursache zu ergründen, denn
unterschiedliche Ursachen können unterschiedliche Refactoring-Maßnahmen nahelegen. Hier endet ein Zipfel der
Analogie, denn Baby-Kacke beseitigt man normalerweise immer auf die gleiche Weise...

Nicht alle Gerüche sind per se unangenehm. Fowler beschreibt zum Beispiel den Geruch von Kommentaren als
angenehm – nachgerade verführerisch angenehm, denn fehlerhafte Kommentaren können Probleme – und die
damit verbundenen Gerüche – verdecken.

Ich strecke die Analogie gerne in eine andere Richtung: Verschiedene Entwickler reagieren auf verschiedene
Gerüche unterschiedlich. Dem einen wird bei einer 10-Zeilen-Methode übel, der andere fühlt sich vom
100-Zeilen-Geruch noch nicht belästigt. Und wieder scheinen den Duft von Methoden um so angenehmer zu emfinden,
je länger sie wird.

Es ist Aufgabe des Teams eine Umgebung zu schaffen die einen vernünftigen Kompromiß bringt.
Es wäre falsch, ganz auf die Beseitigung von Code-Smells zu verzichten. Ebenso falsch aber wäre es,
die Beseitigung bestimmter Smells zu erzwingen –- um bei der Analogie zu bleiben: der Geruch von
Desinfektionsmittel kann durchaus unangenehm sein.

Wie im wirklichen Leben, können Gerüche auf tödliche Gefahren hinweisen -– der Geruch von Bittermandel ist nicht
unbedingt unangenehm, eine Zyanid-Vergiftung ist es aber auf jeden Fall... Doch nicht hinter jedem Geruch steckt ein
verrotteter Fäulnisherd, der die Anwendung in eine einsturzgefährdete Todesfalle verwandelt. Manchmal handelt
es sich lediglich um einen ungewohnten Eigengeruch, an dessen Aroma man sich erst gewöhnen muß.

Nachdem wir nun –- dem Duft der Analogie -– folgend um das eigentliche Thema herummäandert sind, bringen wir
die Sache mal auf den Punkt:
* Ein Code Smell ist der Hinweis auf eine Code-Stelle, die Beachtung verdient
* Ein Code-Smell ist nicht per se schlecht
* Ein Code Smell kann der Hinweis auf eine Schwachstelle sein, die zu ernsthaften Problemen führen kann
* Code-Smells müssen in der Regel mit Rücksicht auf die Ursache behandelt werden
Nachdem wir nun eine Vorsetllung davon haben was einen Code Smell ausmacht, können wir uns nun den
konkreten Beispielen befassen...

"Beliebte" Code Smells...
* Shot Gun Surgery (Martin Fowler)
* Speculative Generalization (Martin Fowler)
* Zu viele Zeilen in der Methoden oder Klasse
* Zu viele (mehr als drei) formale Parameter in der Methoden-Signatur
* Ungenutzte Felder, Parameter, Methoden, Code etc.
* Explizites type casting
* Unangemessener Gebrauch von null
* Auto-unboxing wegen unnötiger Verwendung von Wrapper-Klassen um int, long, etc.

Nachgedanke
:Worte wie "eigentlich" und "wirklich" sind code smells der natürlichen Sprache.
:Sie riechen nach "Ideologie".
:Sie riechen nach "mir sind die rational-logischen Argumente ausgegangen"

Don't repeat yourself

2024-11-28T10:04:06Z

Ullrich: Die Seite wurde neu angelegt: „Category:Quality = Motivation = Software-Entwicklung wird gerne mit der Herstellung von Gegenständen verglichen, also mit der produzierenden Industrie. Das schlägt sich auch in Begriffen wieder wie Software-Architektur oder dem Factory-Pattern. Der Vergleich geschieht nicht ohne Grund und solange man sich nicht scheut sich von der Analogie zu lösen wenn sie nicht mehr passt kann man viele nützliche Erkenntnisse daraus ziehen. Ein Punkt an dem die…“

[[Category:Quality]]

= Motivation =
Software-Entwicklung wird gerne mit der Herstellung von Gegenständen verglichen, also mit der produzierenden
Industrie. Das schlägt sich auch in Begriffen wieder wie Software-Architektur oder dem Factory-Pattern. Der
Vergleich geschieht nicht ohne Grund und solange man sich nicht scheut sich von der Analogie zu lösen wenn sie
nicht mehr passt kann man viele nützliche Erkenntnisse daraus ziehen. Ein Punkt an dem die Analogie versagt
scheint mir besonders wichtig zu sein:

Ein kurzer Blick in die Historie:

Die Industrialisierung hat einen großen Schritt nach vorne getan, als man begann Bauteile zu standardisieren. Die
Errichtung eines Doms erstreckte sich früher über Jahrzehnte. Ein Grund – wenn auch nicht der einzige – war, daß
das Gesamtgebilde aus vielen unterschiedlichen Steinen bestand von denen jeder für sich entworfen und
angefertigt werden mußte. Für dem Chrystal Palace, der anläßlich der Londoner Weltausstellung 1854 errichtet
wurde, ging man einen anderen Weg: Das – gleichfalls imposante – Bauwerk wurde aus verhältnismäßig wenigen
unterschiedlichen Baukasten-Teilen zusammengesetzt. Von jedem Teil wurden zwar große Mengen hergestellt,
aber es gab eben nur eine kleine Anzahl unterschiedlicher Teile.

In der herstellenden Industrie versucht man nach Möglichkeit, immer wieder die gleichen Teile zu verwenden, die
man in großen Mengen produzieren kann. In der Software-Entwicklung marschiert man genau in die
entgegengesetzte Richtung. Ein physisches Bauteile (wie ein Niet, Träger oder Zahnrad) wird hergestellt, angepaßt
und eingebaut. Dann bleibt es dort – unverändert – bis es vielleicht irgendwann ersetzt werden muß. Ein Code-
Fragment – als Beispiel eines nicht physischen, gedanklichen Bauteils – wird irgendwoher kopiert, abgepaßt und an
beliebiger Stelle eingesetzt. Wenn es denn irgendwann nicht mehr paßt, wird es geändert, jederzeit. Das Code-
Fragment gleicht also einer Niete, die morgen ein Träger und übermorgen ein Zahnrad sein kann. Ein kopiertes
Code-Fragment führt vom Augenblick seiner Entstehung ein Eigenleben und ist vollkommen unabhängig von seiner
Vorlage.

Mit jeder Code-Zeile erhöht sich die Komplexität der Anwendung. Denn jedes Code-Fragment hat seine eigene
Entwicklung, kann unabhängig vom Rest verändert werden und muß immer einzeln angepaßt werden.Denn jedes
Code-Fragment hat seine eigene Entwicklung, kann unabhängig vom Rest verändert werden und muß immer
einzeln angepaßt werden. Die Regel lautet daher:

Für jedes Konzept soll es genau eine Implementierung geben.

= Was heißt "wiederholen"? =
Das klingt jetzt erstmal so, als wäre Kopieren die einzige Möglichkeit der Wiederholung. Das stimmt natürlich nicht,
auch wenn es vermutlich die am häufigsten vorkommende Form ist (vielleicht weil 'C' und 'V' auf der Tastatur so
nahe bei einander liegen). Die andere Variante der Wiederholung ist das "nochmal schreiben". Ein Beispiel:
Irgendwo in der Anwendung wird ein Algorithmus ausgeführt, eine Suche in einem Graphen, eine Sortierung, das
Vergleichen zweier Listen, oder auch nur der direkte Zugriff auf eine Datenbank durch öffnen einer Verbindung,
Zusammenbau eines SQL-Statements und auswerten der Antwort. Vergessen wir für einen Augenblick, daß es für
die meisten dieser Tätigkeiten coole Bibliotheken oder Frameworks gibt und nehmen an daß keine zur Verfügung
stünden, daß wir darauf angewiesen sind, unseren Algorithmus komplett selbst zu schreiben. Erstaunlich viele
Entwickler haben solche Algorithmen im Kopf und schreiben sie jedesmal neu, wann sie sie brauchen – so wie man
auch eine for-Schleife oder eine if-Anweisung heruntertippt ohne groß darüber nachzudenken. Das Resultat ist eine
wachsende Zahl von Boilder-Plate-Fragmenten, die – mit leichter Variation – immer wieder das Gleiche tun.

= Wie hält man die Regel ein? =
Ein Verbot läßt sich nur auf eine Art einhalten: Indem man unterläßt. Die Alternative zum Kopieren lautet daher:
Statt das Fragment zu kopieren, lagert man es in eine Methode aus. Statt das Fragment einzufügen ruft man die
Methode auf. Das funktioniert allerdings nur solange, bis das Fragment eine Anpassung erfordert. Im einfachsten
Falle kann man das mit Methoden-Parametern durchführen, stößt damit aber – vor allem wenn das Fragment an
weiteren Stellen verwendet werden soll – schnell an Grenzen (Für Clean Code etwa sind drei Parameter bereits eine
Zumutung). Dann kommen Klassen, Factories und das ganze übrige Arsenal zum Einsatz. Welche Mittel man wählt
und wie weit man gehen sollte um Duplikate zu vermeiden läßt sich nicht pauschal beantworten. Erfahrung und ein
gesundes Urteilsvermögen leisten beim Design wie immer gute Dienste. Die Fragen die sich der Entwickler
zwischen Ctrl-C und Ctrl-V daher immer stellen sollte ist:

Wo kann ich das noch verwenden?

Und wie kann ich das verallgemeinern?

Da Wiederholung auch dann entsteht, wenn man Fragmente wiederholt implementiert, sollte man sich die Fragen
immer dann stellen, wenn man ein Teilproblem implementieren möchte das so klein ist, daß es nicht von
vornherein als eigenes Module konzipiert wurde.

Bliebe noch die Frage, wieviele Code-Zeilen man denn überhaupt noch kopieren darf. Man orientiert sich bei der
Verallgemeinerung am Zweck und nicht an der Menge. Eine Serie von Zuweisungen für eine Objekt-Initialisierung
läßt sich oft gar nicht verallgemeinern, hingegen kann eine Berechnung die nur eine einzelne Zeile durchaus
Wiederverwendungswert haben (man denke da zum Beispiel an die Berechnung der Mehrwertsteuer). Man
orientiert sich da auch an den anderen Regeln: „Separation of Concerns“, „One function, one purpose“, „separation
of abstractations“ etc. Dann sollen die Klassen und Methoden ganz von alleine und im richtigen Format entstehen.

= Spezialfall „Distributed Repetition“ =
In großen Projekten mit vielen Entwicklern verteilt man die Aufgaben gerne so, daß sich die Entwickler möglichst
nicht in die Quere kommen. Da es für viele Algorithmen eine bevorzugte Standard-Implementierung gibt, geschieht
es leicht, daß mehrere Entwickler – mehr oder minder – identischen Code produzieren. Man mag einwenden, daß
hier keine Wiederholung im Wortessinne vorliegt, doch der Effekt ist der gleiche: ein Code-Fragmnet existiert
mehrfach und jede Emanation startet sofort ihre individuelle Entwicklung.
== Was kann man dagegen tun? ==
Grundsätzlich gilt auch hier die oben genannten Fragen, allerdings kommt noch das Problem dazu, daß Entwickler
A in der Regel nicht weiß, was Entwickler B so alles implementiert. Daher kann er auch nicht wissen ob für sein
Teilproblem vielleicht schon irgendwo eine Lösung existiert. Dieses Problem kann man nur organisatorisch lösen
oder zumindest abmildern. Die Kernfrage lautet dabei „Wo finde ich...?“ bzw. "Wohin packe ich?"

'''Struktur definieren'''

Das Team legt fest, wo in der Code-Basis Lösungen abgelegt werden für Teilprobleme die von allgemeinem
Interesse sind. Also zum Beispiel für Konvertierungs-Funktionen, Graphen-Suche, Sortierung etc. Dazu gehören
auch anwendungsspezifische Probleme die allgemein gelöst werden sollten (z.B. Ausgabe von Meldungen an den
Benutzer, Formatierung von Log-Ausgaben, fachspezifische Berechnungen), für die es aber keine Vorgabe oder
Lösung aus höherer Ebene gibt. Lösungen aus verwendeten Frameworks (z.B. EAP) werden natürlich bevorzugt.
Damit haben alle Entwickler ein gemeinsames Source-Forum für allgemeine Lösungen.

'''Dokumentation'''

Umfangreiche Code-Basen sind unübersichtlich und komplexe Problemlösungen erklären sich nicht von selbst. Es
ist empfehlenswert – z. B. mit einem Wiki – neben der Kernfunktionalität der Anwendung auch die Utility-Klassen
und die verwendeten, allgemeinen Algorithmen zu beschreiben und das Customizing zu beschreiben und über die
Dokumentation die Ablagestruktur zu beschreiben. Das ist allerdings zeitintensiv und lohnt sich eigentlich nur bei
Anwendungen die über einen langen Zeitraum gewartet und geändert werden.

'''Kommunikation'''

Entwickler sollten über ihre Arbeit sprechen und von gefundenen Lösungen erzählen. Im Daily geht es meist nur
darum ob die Aufgaben umgesetzt wurden und ob dabei Probleme auftraten, nicht aber darum wie Aufgaben
gelöst wurden und was man mit der Lösung noch anderes anfangen kann. Pair Programming hilft schon etwas
mehr, weil sich die Entwickler gemeinsam mit dem Lösungsweg auseinandersetzen. Allerdings ist die Verbreitung
dabei gering, weil in der Regel nur zwei Entwickler mit einander sprechen. Optimal sind Entwickler-Runden in
denen Entwickler von ihren Lösungen erzählen. Dabei geht es nicht in erster Line darum den Code zu reviewen,
sondern darum daß das Wissen um das Vorhandensein von Lösungen schnell verbreitet wird. Bei dieser
Gelegenheit kann auch über Ablage-Orte gesprochen werden und selbstverständlich kann auch darüber diskutiert
werden, welche Lösungen allgemein verwendet werden sollen und welche nicht. Der Fokus sollte aber immer auf
dem Austausch von Information liegen, nicht auf der Bewertung.

Der Weg zum guten Code

2024-11-28T10:02:54Z

Ullrich:

[[Category:Quality]]
Um entscheiden zu können welcher [https://xkcd.com/844/ Weg zum guten Code] führt, muß man festlegen was
''guten'' Code von schlechtem unterscheidet. Die Erkenntnis, daß es nicht gleichgültig ist, wie Code beschaffen
ist wurde ja offensichtlich schon gewonnen -- andernfalls wäre die Suche eine sinnlose.

"Gut" ist der Code, wenn er über die blanke Funktionalität hinaus weitere Eigenschaften erfüllt. Über diese
nichtfunktionalen Eigenschaften giebt es eine große Literatur, die Worte "Qualiät" und "Architektur" fallen einem in diesem
Zusammenhang ein. Dabei geht es aber in der Regel um die Software-Qualität, also die Qualität des gesamten Erzeugnisses
im Zusammenspiel mit der Umgebung in der es betrieben wird.

Diese Seite engt den Blick ganz bewußt auf den "Code" ein. Damit ist der Quelltext gemeint, aus dem das Erzeugnis
hergestellt wird. Noch genauer geht es dabei um den Programm-Code -- wann kann man diesen als "gut" bezeichnen?

Für den Entwickler -- den Einzigen, der ursächlich an der [https://xkcd.com/1695/ Code-Qualität] interessiert ist --
muß der Code wartbar, erweiterbar und änderbar sein. Der Grad ''dieser'' Eigenschaften bestimmt die Güte des Codes. Die Optimierung dieser Eigenschaften steht bisweilen im Widerspruch zu anderen Eigenschaften -- insbesondere der Performance.
Das Abwägen ist Aufgabe des Architekten und liegt außerhalb des Scope dieses Textes; hier geht es ausschließlich darum
die Code-Qualität zu verbessern.

Es giebt eine unüberschaubare Fülle an Regeln, Tipps, Techniken und Ideologien zum Thema. Nahezu jeder Entwickler,
den man zum Thema Code-Qualität befragt weiß einen anderen Strauß aus seinen Erfahrungen zu binden.

Aus dem Wunsch heraus, einen Überblick über die verwirrende Vielzahl von Begriffe, Ansichten und Ansätzen zu gewinnen
ist die untige Sammlung entstanden. Sie ist weder vollständig noch verbindlich, bietet dem interessierten Leser aber
eine Basis für die weitere Erkundung der Materie. Es wird zwar der Versuch eine Einteilung gemacht um den Überblick zu
verbessern, aber es wird versucht zu vermeiden eine Wertung vorzunehmen.

= Leitgedanken =
Ein Leitgedanke zu dem es bislang noch kein vernünftiges Gegenargument giebt ist folgender:
{{quotation|Die Qualität von Code bemißt sich daran, wie leicht er zu lesen ist}}
Über die Frage, wie "lesbarer" Code konkret auszusehen hat giebt es allerdings unterschiedliche Auffassungen.
Daraus kann man auch ableiten, daß bessere Lesbarkeit nicht automatisch zu besserer Änderbarkeit führt.
Sie führt aber dazu, daß der Code besser zu verstehen ist, daher besser bearbeitet werden kann und damit besser
zu warten ist. "Lesbarkeit" bleibt ein Kernzeil des Qualitäts-Suchenden und er wird sich die Frage bei jeder Code-Zeile
zu stellen haben.

{{quotation|Die Grenzen meiner Sprache sind die Grenzen meiner Welt}}

Im Kontext der Code-Qualität bedeutet das: So klar meine Sprache ist, so klar ist mein Code. Computer-Sprachen
(formale Sprachen überhaupt) lassen keine Mehrdeutigkeiten zu. Wird der gleiche Code bei mehrfacher Ausführung
unterschiedlich interpretiert, so ist das ein Fehler. Eine klare Ausdrucksweise, als Ausdruck klarer Gedanken ist
eine Grundvoraussetzung klaren Programm-Codes.

{{quotation|Separation of Concerns}}

ToDo: Erklärung wie die Idee von Dijkstraa als Leitgedanke zu verstehen ist

= Regeln =
Eine Regel ist eine Richtlinie die vermittelt was man tun – oder lassen – sollte, aber nicht vorgeben wie man das erreicht.
Regeln weisen die Richtung, bestimmen den Generalkurs; bieten aber wenig Hilfe bei der Überwindung konkreter Hindernisse.
Regeln sind keine Naturgesetze; es liegt in ihrer Natur, daß man auch von ihnen abweichen kann.
Es ist wichtig, den Wert einer Regel zu erkennen und daran die Maßnahmen auszuwählen die sie unterstützen.

Die Abgrenzung von Regeln gegen best practices und auch gegen konkrete Maßnahmen ist nicht immer scharf auszumachen.
Aber bevor man sich in exegetische Schlachten begibt, sollte man sich immer fragen, worum es eigentlich geht.
Das Ziel ist klarer, handhabbarer Code, das zu erreichen ist jeder Weg erlaubt.
Das gilt im Übrigen auch für die Gewichtung von Regeln, Ideologie ist immer der falsche Weg -- egal wohin.

* DRY - [[Don't repeat yourself]]
* KISS – Keep it simple stupid [http://www.commitstrip.com/en/2018/10/29/only-the-penitent-coder-will-pass/ commitstrip]
** Ockhams Razor
** Law of Parsimony
** Principle of Least Surprise
* SoC – Separation of Concerns (im Sinne von Aufgaben-Trennung)
* YAGNI – You Aren't Gonna Need It [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it Wikipedia]
* [[Cohesion|high cohesion/loose coupling]]
* OCP – Open/Closed Principle
* SRP – Single Responsibility Principle
* Don’t make me think/write your code for everybody
* IoC – Inversion of Control / Dependency Inversion
* Form follows Function – Pragmatismus vor Ästhetik
* ISP – Interface Segregation Principle
* Stick to the Paradigm
* Tell don't ask ([https://martinfowler.com/bliki/TellDontAsk.html Martin Fowler])

Was ist mit SOLID?

Robert C. Martin hat fünf Prinzipien (SRP, open/closed, Liskov, ISP, DI) zusammengefaßt und damit ein tolles backronym zu bilden. Ob man dieser Kollektion einen besonderen Wert zuordnen möchte oder nicht sei mal dahingestellt. Das Liskov-Prinzip wurde hier - wegen seiner Konkretheit - unten den best practices eingeordnet. Die Frage wie man IoC und DI beschreibt und gegen einander abgrenzt ist noch zu diskutieren.

= Best Practice =
Best Practices – auch Heuristiken genannt – sind Techniken oder Vorgehensweisen, die sich in der Praxis in irgendeiner Form
und iregndeiner Situation bewährt haben. Meist lassen sie Gestaltungsspielraum, wenn es um die konkrete Anwendung geht – die
Abgrenzung zwischen einer konkreten Regel und einer allgemeinen Heuristik ist fließend. Und man sollte immer bedenken,
daß best practices in der Regel aus konkreten Situationen heraus entstanden sind und nicht auf jede beliebige Situation übertragbar sind -- dazu giebt es unten ein Antipattern.

* Clean Code (hier nur einige Heuristiken, die sich bei ''meiner'' Arbeit bewährt haben)
** Jeder Bezeichner soll exakt beschreiben, was das Bezeichnete tut oder enthält
** Eine Methode soll eine Wert liefern oder etwas tun, aber nicht beides
** Methoden (auch Konstruktoren) soll nicht mehr als drei Parameter haben
** Death to Magic numbers
** saubere Bezeichner sind besser als gute Kommentare sind besser als keine Kommentare sind besser als falsche Kommentare
** Eine Methode – eine Aufgabe
** lokale Variablen dort deklarieren, wo sie gebraucht werden
* Kent Beck's Design Rules (according to [http://martinfowler.com/bliki/BeckDesignRules.html Martin Fowler])
** Passes the Tests
** Reveals intention
** No Duplication
** Fewest Elements
* DI – Dependency Injection (als Implementierung von IoC)
* LSP - Liskov substitution principle
* Demeter-Prinzip
* Trennung von Abstraktions-Ebenen
* Trennung von Interface und Implementierung siehe dazu auch: Bridge-Pattern
* Interfaces sollen so schmal wie möglich sein und nur das enthalten was tatsächlich erforderlich ist.
* verwende Architektur-Pattern
* verwende das Schichten-Modell
* [http://clean-code-developer.de/die-grade/roter-grad/#Integration_Operation_Segregation_Principle_IOSP IOSP]– Integration Operation Segregation Principle
* verwende Design-Pattern (hier einige GoF-Pattern, die ich besonders häufig verwende)
** Factory Method
** Adapter
** (simplified) Builder
** Singleton
** Proxy
** Facade
** Decorator
* Delegation statt Vererbung (Delegation wird im GoF-Buch nicht als Pattern sondern als Konzept beschrieben)
* Ein Konzept – ein Begriff
::Bsp: die eMail-Adresse sollte im Code nicht durcheinander als "eMail_Adresse", "mail-Adresse", "mail", "eMail" oder sonstwie bezeichnet werden, sondern immer gleich
* vermeide Antipattern
** [https://en.wikipedia.org/wiki/Interface_bloat Interface bloat] -- Interfaces verlangen mehr als erforderlich
** [https://en.wikipedia.org/wiki/Inner-platform_effect Inner-platform effect] – Das System erlaubt soviel Customization, daß eine schlechte Plattform daraus geworden ist.
** [https://en.wikipedia.org/wiki/Constant_interface Constant Interface] -- Interfaces dienen nur der Definition von Konstanten
** [https://en.wikipedia.org/wiki/Sequential_coupling Sequential coupling] -– Die Klasse verlangt den Aufruf ihrer Methoden in einer bestimmten Reihenfolge
** [https://en.wikipedia.org/wiki/Cargo_cult_programming Cargo cult programming] -– Pattern und Methoden verwenden ohne sie zu verstehen
** [https://en.wikipedia.org/wiki/Golden_hammer Golden hammer] / [https://en.wikipedia.org/wiki/No_Silver_Bullet Silver bullet] -– Alle Probleme mit der gleichen (Lieblings-)Methode lösen
** Base Bean – Vererbung soll is-a-Beziehungen abbilden, nicht has-a
** Stellvertreter-Typen – Statt einen Datentyp zu definieren, existierende Klassen (besonders String) mißbrauchen
** [[Petting Zoo]] - keeping code that is not worth it
* vermeide [[Code Smell]]s
* Refactoring
* Verwende eine durchgehende Nomenklatur
* Stick to the Coding Guidelines
* Das gleiche Problem sollte immer auf gleiche Art und Weise gelöst werden
* Verwende für Kommentare und Bezeichner nur natürliche Sprachen die Du auch beherrschst
:actualValue für den aktuellen Wert (richtig ist current)
* bound als Übersetzung für "verknüpft" (richtig ist linked)
* Don't state the obvious:
: Logger logger = LoggerFactory.obtainLogger();
: String stringToBeLogged = "log: logging start of action Foo";
: logger.log(stringToBeLogged);
* toString() ist kein Serialisierungs-Tool
* zu viel von etwas ist selten gut:
: <q>If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help.</q>
:([https://en.wikipedia.org/wiki/Michael_A._Padlipsky Michael Padlipsky])

= Hilfsmittel =
Entgegen anderslautender Meinungen erhöht der Einsatz von Tools nicht automatisch die Qualität. Das Berechnen von Werten anhand von Metriken beispielsweise trägt zunächst gar nichts zur Qualität bei, erst die Auswertung und das Durchführen von Maßnahmen zur Änderung der Werte kann als qualitätsstiftende Maßnahme gelten. Nichtsdestotrotz unterstützt die Verwendung von Hilfsmitteln den Entwickler dabei den Weg zum Code hoher Qualität zu beschreiten.

* automatisch durchgeführte Unit-Tests
:Unit-Tests als "Tool" zu beschreiben mag seltsam klingen. Tatsächlich sind Unit-Tests aber nicht Teil des produktiven Codes und daher kann man mit Fug und Recht von einem Tool sprechen.
* Metriken
* Tools zur Code-Analyse (sonar, java-Compiler-Warnings)
* Tools zur Messung der Test-Abdeckung (EclEmma)
* Automatische Code-Formatierung (Eclipse Code Formatter)
* Coding-Guidelines
* [http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html Sun Code Conventions]
:Sie werden seit 1999 nicht mehr gepflegt. Einige Regeln sind überholt, andere zweifelhaft (z.B. 6.2: Variablen-Deklarationen nur am Beginn eines Code-Blocks plazieren), Sie bilden aber die Grundlage für das Code-Layout und man sollte sie kennen und berücksichtigen. 
:(Fun fact: Der Autor hat anscheinend von C abgeschrieben – es sind tatsächlich ein paar Fehler im Dokument)
* Refactoring-Tools (IDEs wie Eclipse bringen eine Menge davon mit

= Arbeitstechniken =
Die klassische Technik des Entwicklers ist das Zurückziehen hinter die Tastatur. Der Entwickler kriecht erst hervor, wenn das Werk vollendet ist. Das beschreibt einen Teil der Tätigkeit, reicht aber schon seit einem halben Jahrhundert nicht mehr aus. Und auch die Handgriffe, mit denen der Entwickler im stillen Kämmerlein den Wandel von Buchstaben in Code vollzieht wandeln sich im Laufe der Zeit. Man muß nicht jede Technik übernehmen, aber man sollte sich damit befassen und zumindest genau wissen, warum man sie nicht einsetzt.

* [[Boy Scout Principle]]
* Code – fremden und eigenen – lesen und reflektieren
* zuhören
* Diskussion über Code
* Code-Reviews
* XP – extreme Programming
** TDD – Test Driven Development
** Test First Ansatz
** Pair Programming
** Root Cause Analysis
** Incremental Design
* Embrace the CATSAN method
* Programming by Difference (→ Michael Feathers)
* Rubber Duck Debugging
* Technologische Schulden minimieren

= Literatur =
* Edsger Dijkstra [https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html On the role of scientific thought]
* Refactoring: Improving the Design of Existing Code (Martin Fowler/Kent Beck)
* Working Effectively with Legacy Code (Michael C. Feathers)
* Clean Code (Robert C. Martin)
* Design Patterns: Elements of Reusable Object-Oriented Software (Gamma/Helm/Vlissides/Johnson)
* The Mythical Man Month (Fred Brooks)
* The Systems Bible – 3rd edition of "Systemantics" (John Gall) [https://en.wikipedia.org/wiki/Systemantics Überblick in der Wikipedia]
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjKitDwvJ3NAhXFKMAKHQ0hBWEQFggpMAE&url=http%3A%2F%2Fworrydream.com%2Frefs%2FBrooks-NoSilverBullet.pdf&usg=AFQjCNGkOYvU4WQgqaHGAqGgicO0XTRcw&bvm=bv.124088155,d.bGg No Silver Bullet] (Fred Brooks)
* [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiWtayRvZ3NAhUMDMAKHe_JDCYQFggcMAA&url=http%3A%2F%2Fhomepages.cwi.nl%2F~storm%2Fteaching%2Freader%2FDijkstra68.pdf&usg=AFQjCNFIgAgWJ_Aoph79yl9-tFusEGgglQ Goto Considered Harmful] (Edsger Dijkstra)
* [http://clean-code-developer.de/ clean code developer site]
* [http://chris.beams.io/posts/git-commit/ Regeln für GIT-commit-Kommentare]
* [http://www.cs.yale.edu/homes/perlis-alan/quotes.html Epigramme von Alan Perlis]
* [https://www.heise.de/newsticker/meldung/John-Romero-Von-id-Softwares-Anfaengen-und-World-of-Warcraft-Sucht-3296840.html Programmier-Regeln von John Romero]
* [https://sourcemaking.com Gute Sammlung von Pattern, Anti-Pattern etc.]
* [https://xkcd.com/1926 Bad Code in XKCD]

= Zen =
Keine Richtlinien, keine Anweisungen, einfach Aussagen über die man nachdenken kann. Hier kann man beliebig hitzig diskutieren; wichtig ist nur, daß man darüber – möglichst unvoreingenommen – nachdenkt.

* Wer sich nicht klar ausdrückt, denkt auch nicht klar
* big bang features lead to big bang
* Software Engineering ist agnostisch
* Ein Beispiel beweist nichts, widerlegt aber alles – soviel zu TDD- und Test-Abdeckungs-Fetischismus
* Ist TDD die zeitgemäße Formulierung für "trial and error"?
* Wenn Du weißt was Du tust, bist Du gesegnet
* If it ain't broken, don't fix it vs. Refactoring
* Verwende nur was Du auch verstehst ([https://xkcd.com/1597/ Wie XKCD GIT charakterisiert])
* Wer etwas ablehnt oder verteidigt sollte genau wissen warum
* Nichts hält so lange wie ein Provisorium
* Wer trennt schafft Abhängigkeiten, wer nicht trennt schafft Chaos
* Nichts ist so einfach, daß man es nicht falsch machen könnte
* Eine Entscheidung ist richtig, wenn sie rational begründet werden kann
* Was wert ist daß man es tut, ist wert daß man es richtig tut.
* Wenn man versucht Probleme auszusitzen, kriechen sie irgendwann hervor und treten einem in den Hintern

Code Smell

2024-11-28T10:02:05Z

Ullrich: Die Seite wurde neu angelegt: „Category:IT Die erste Erwähnung des Begriffs "code smell" findet sich in Martin Fowlers Buch "Refactoring". Er verwendet ihn dort als es darum geht die Code-Stellen zu identifizieren an denen Refactoring erforderlich ist. Fowler bleibt dabei ausgesprochen vage, aber die Andeutung auf verunreinigte Baby-Windeln erzeugt den starken Eindruck, daß es sich hier um ausgesprochen unangenehme Gerüche handeln muß... Ein Code Smell ist eine Stelle im Code…“

[[Category:IT]]
Die erste Erwähnung des Begriffs "code smell" findet sich in Martin Fowlers Buch "Refactoring". Er verwendet ihn
dort als es darum geht die Code-Stellen zu identifizieren an denen Refactoring erforderlich ist. Fowler bleibt dabei
ausgesprochen vage, aber die Andeutung auf verunreinigte Baby-Windeln erzeugt den starken Eindruck, daß es sich
hier um ausgesprochen unangenehme Gerüche handeln muß...

Ein Code Smell ist eine Stelle im Code mit bestimmten Eigenschaften, an denen sie zu erkennen ist. Diese
Eigenschaften bilden den bisweilen charakteristischen Geruch. Eine Methode mit einer langen Parameterliste ist ein Beispiel
dafür, mit jedem weiteren Parameter wird der Geruch intensiver.

Viele Code Smells haben eine Ursache. Eine lange Parameterliste zum Beispiel kann das Ergebnis sukzessiver
Verallgemeinerung sein. Die ursprüngliche Methode hatte vielleicht nur zwei Parameter, aber mit jeder Anpassung
an die geänderten Anforderungen kam ein neuer Parameter hinzu. Nicht jeder Smell hat eine klare Ursache, für
manche Smells gibt es mehrere mögliche Ursachen. In aller Regel ist es sinnvoll die Ursache zu ergründen, denn
unterschiedliche Ursachen können unterschiedliche Refactoring-Maßnahmen nahelegen. Hier endet ein Zipfel der
Analogie, denn Baby-Kacke beseitigt man normalerweise immer auf die gleiche Weise...

Nicht alle Gerüche sind per se unangenehm. Fowler beschreibt zum Beispiel den Geruch von Kommentaren als
angenehm – nachgerade verführerisch angenehm, denn fehlerhafte Kommentaren können Probleme – und die
damit verbundenen Gerüche – verdecken.

Ich strecke die Analogie gerne in eine andere Richtung: Verschiedene Entwickler reagieren auf verschiedene
Gerüche unterschiedlich. Dem einen wird bei einer 10-Zeilen-Methode übel, der andere fühlt sich vom
100-Zeilen-Geruch noch nicht belästigt. Und wieder scheinen den Duft von Methoden um so angenehmer zu emfinden,
je länger sie wird.

Es ist Aufgabe des Teams eine Umgebung zu schaffen die einen vernünftigen Kompromiß bringt.
Es wäre falsch, ganz auf die Beseitigung von Code-Smells zu verzichten. Ebenso falsch aber wäre es,
die Beseitigung bestimmter Smells zu erzwingen –- um bei der Analogie zu bleiben: der Geruch von
Desinfektionsmittel kann durchaus unangenehm sein.

Wie im wirklichen Leben, können Gerüche auf tödliche Gefahren hinweisen -– der Geruch von Bittermandel ist nicht
unbedingt unangenehm, eine Zyanid-Vergiftung ist es aber auf jeden Fall... Doch nicht hinter jedem Geruch steckt ein
verrotteter Fäulnisherd, der die Anwendung in eine einsturzgefährdete Todesfalle verwandelt. Manchmal handelt
es sich lediglich um einen ungewohnten Eigengeruch, an dessen Aroma man sich erst gewöhnen muß.

Nachdem wir nun –- dem Duft der Analogie -– folgend um das eigentliche Thema herummäandert sind, bringen wir
die Sache mal auf den Punkt:
* Ein Code Smell ist der Hinweis auf eine Code-Stelle, die Beachtung verdient
* Ein Code-Smell ist nicht per se schlecht
* Ein Code Smell kann der Hinweis auf eine Schwachstelle sein, die zu ernsthaften Problemen führen kann
* Code-Smells müssen in der Regel mit Rücksicht auf die Ursache behandelt werden
Nachdem wir nun eine Vorsetllung davon haben was einen Code Smell ausmacht, können wir uns nun den
konkreten Beispielen befassen...

"Beliebte" Code Smells...
* Shot Gun Surgery (Martin Fowler)
* Speculative Generalization (Martin Fowler)
* Zu viele Zeilen in der Methoden oder Klasse
* Zu viele (mehr als drei) formale Parameter in der Methoden-Signatur
* Ungenutzte Felder, Parameter, Methoden, Code etc.
* Explizites type casting
* Unangemessener Gebrauch von null
* Auto-unboxing wegen unnötiger Verwendung von Wrapper-Klassen um int, long, etc.

Nachgedanke
:Worte wie "eigentlich" und "wirklich" sind code smells der natürlichen Sprache.
:Sie riechen nach "Ideologie".
:Sie riechen nach "mir sind die rational-logischen Argumente ausgegangen"

Parametrisierte Tests

2024-11-19T18:39:27Z

Ullrich:

[[Category:Java]]
[[Category:junit]]
Ein einzelner Unit-Tests befaßt sich mit einem einzelnen Test-Fall und hat im Regelfall eine einzelne Assertion.
Dieses einfache Beispiel testet die korrekte Konvertierung von Datum-Strings in ein Date-Objekt. Die drei Assertions
prüfen hier zusammen, ob das Datum korrekt ist:
{{java|code=
@Test
public void toDateLiefertKorrektesDatum() {
Date convertedDate = Convert.toDate("01.5.1985");
assertThat(convertedDate).hasDayOfMonth(1);
assertThat(convertedDate).hasMonth(5);
assertThat(convertedDate).hasYear(1985);
}
}}
Nun soll er Konverter mit unterschiedlichen Datums-Angaben umgehen: Mit und ohne führende Nullen, mit und
ohne Jahrhundert, vielleicht soll auch ein Minuszeichen anstelle des Punkts erlaubt sein. Für jeden Testfall kann
man nun die Test-Methode kopieren und entsprechend anpassen. Die Folgen sind klar: jede Menge Test-Code,
sinkende Übersichtlichkeit und für jede neue Test-Methode braucht es einen neuen Namen. Das DRY-Prinzip soll
auch für Test-Code gelten.

Eine wesentliche Bereicherung von JUnit-5 ist die Unterstützung von Parameter-gesteuerten Test-Methoden die
weit über das hinausgeht was JUnit-4 oder Test-NG zu bieten hatten. Eine Vielzahl von Test-Situationen läßt sich
damit abdecken und vor allem eindampfen.
== Eine Liste einzelner Parameter ==
Betrachten wir –- angelehnt an das einleitende Beispiel -– die einfachste Situation: Einen Testfall soll mit einer Reihe
einzelner Strings aufgerufen werden. Dazu parametrisieren wir zunächst die Test-Methode und ziehen den Datum-String als Parameter heraus:
{{java|code=
void toDateLiefertKorrektesDatum(String datum) {
Date convertedDate = Convert.toDate(datum);
assertThat(convertedDate).hasDayOfMonth(1);
assertThat(convertedDate).hasMonth(5);
assertThat(convertedDate).hasYear(1985);
}
}}
Dann legen wir die Datum-Strings fest mit denen getestet werden soll:
{{java|"1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985"}}.
Um die neue Test-Methode mit den Test-Fälle zu verknüpfen, verwenden wir JUnit5-Annotationen und setzen sie
über unsere parametrisierte Test-Methode:
{{java|code=
@ParameterizedTest
@ValueSource(strings = { "1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985" })
}}
Die erste Annotation ersetzt die {{java|@Test}}-Annotation und macht die Methode zum (parametrisierten) Test.
Die zweite Annotation legt die Quelle der zu verwendenden Werte fest.
In diesem Falle ist dies eine Liste von Strings. Der Test wird bei der
Ausführung für jeden String einmal aufgerufen, wobei der jeweilige String als Argument übergeben wird.
Anstelle von Strings sind hier auch alle numerischen, primitiven Typen int, long, float und einiges mehr erlaubt.
Die Anntotations-Parameter kann man in Eclipse mit Code-Assist erkunden oder in der JUnit5-Doku nachlesen.

Beachtenswert ist, daß Annotationen nur Konstanten als Argumente übernehmen,
also Ausdrücke die zur Compile-Zeit ausgewertet werden können. Objekte zu übergeben ist so nicht möglich.

Wie man damit umgeht, sehen wir in den folgenden Abschnitten.
Vorher aber noch ein Wort zu {{java|null}}.

=== Was ist mit null? ===
Die eben vorgestellte Werte-Liste hat einen kleinen Haken: Es ist nicht möglich, den Wert null als Argument zu
verwenden. Um einen Testfall für null zu erzeugen, kann man nun freilich eine neue Test-Methode erstellen und
null separat in diesem Test prüfen. Man kann dem Test aber auch zusätzlich die Annotation {{java|@NullSource}}
hinzufügen. JUnit5 erzeugt dann einen zusätzlichen Testfall für {{java|null}}:
{{java|code=
@ParameterizedTest
@NullSource
@ValueSource(strings = { "1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985" })
public void toDateLiefertKorrektesDatum(String datum) {
// hier kommt der Test-Code hin...
}
}}
Unterstützt wird {{java|@NullSource}} ab Version 5.4.

== Einzelne Argumente aus einer Methode ==
Anstelle der Angabe von Annotations-Parametern kann man eine Methode schreiben die die Argumente liefert.
Die Methode muß {{java|static}} sein und einen {{java|Stream}} von "irgendwas" liefern.
Das obige Beispiel kann man dann so schreiben:
{{java|code=
@ParameterizedTest
@MethodSource("testDatenMethode")
void toDateLiefertKorrektesDatum(String datum) {
// sieht genauso aus wie oben
}

static Stream<String> testDatenMethode() {
return Stream.of("1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985");
}}

Das Beispiel hat den gleichen Effekt wie die Implementierung im vorabgegangenen Abschnitt,
aber die Möglichkeiten sind offensichtlich viel weiterreichend. In der Test-Daten-Methode lassen
sich beliebige Objete liefern, die bei bedarf auch dynamisch erzeugt werden können.
Der Wert {{java|null} ist hier kein Problem, er darf im Stream enthalten sein.

Hat die Testdaten-Methode den gleichen Namen wie die parameterisierte Test-Methode,
kann man den Parameter der Annotation {{java|@MethodSource}} übrigens weglassen.

== Mehrere Parameter für die Test-Methode ==
Für viele Unit-Tests reicht die Extraktion eines einzelnen Parameters nicht aus. Im folgenden Beispiel wird die
Qualität von Passworten getestet. Das Wort "Hallo" zum Beispiel wird abgewiesen, weil es nur Buchstaben enthält:
public void passwortWirdNichtAkzeptiert() {
assertThat(policy.validate("Hallo")).as("nur Buchstaben").isFalse();
}
Wofür die Parameter in der Test-Methode verwendet werden, spielen keine Rolle, es geht nur darum, den Test
mehrfach aufzurufen und dabei ''mehrere'' Parameter zu übergeben. Im vorliegenden Falle möchten wir
unterschiedliche Passwort-Kandidaten testen und dabei jeden Test mit einer Beschreibung versehen, der Auskunft
gibt warum das Wort nicht als Passwort akzeptiert wird. Die Test-Methode sieht nun so aus:
{{java|code=
public void passwortWirdNichtAkzeptiert(String passwort, String grund) {
assertThat(policy.validate(passwort)).as(grund).isFalse();
}
}}
Für die Erzeugung der Test-Daten schreiben wir diesmal eine weitere Methode.
Sie erzeugt einen Stream von Arguments-Objekten von denen jedes die Daten für ''einen'' Test-Aufruf enthält:
{{java|code=
static Stream<Arguments> pwdWirdNichtAkzeptiert() {
return Stream.of(
Arguments.of("Hallo", "nur Buchstaben"),
Arguments.of("1234567", "nur Ziffern"),
Arguments.of("!%#&/()", "nur Sonderzeichen")
);
}
}}
Die Methode für die Testdaten-Erzeugung muß folgende Eigenschaften haben:
*sie muß static deklariert sein
*sie muß zur Test-Klasse gehören
*sie darf keinen Parameter haben und muß einen Stream von Arguments-Objekten liefern
*sie darf in beliebiger Sichtbarkeit deklariert werden
Die Methode darf zwar private deklariert werden, Java wird sich aber darüber beschweren, daß die Methode
nirgends verwendet wird. Warum das so ist, erfahren wir weiter unten.
Am einfachsten deklariert man sie daher package visible.

Die Klasse
{{java|org.junit.jupiter.params.provider.Arguments}}
ist ein Container, der eine Reihe von Werten beliebigen Typs (mit Ausnahme von {{Lambda}}-Ausdrücken) in fester
Reihenfolge aufnimmt. JUnit5 mappt die Werte der {{java|Arguments}}-Objekte auf die Parameter der Test-Methode. Das
geschieht allerdings erst zur Laufzeit, der Entwickler ist daher selbst dafür verantwortlich die Typen zwischen
Testdaten-Provider und Test-Methode in Übereinstimmung zu halten.

Wir bringen nun Test-Methode und Testdaten-Provider-Methode zusammen. Das geschieht mithilfe folgender JUnit5-Annotationen:
{{java|code=
@ParameterizedTest
@MethodSource("pwdWirdNichtAkzeptiert")
}}
Die erste Annotation kennen wir schon aus dem vorangegangenen Abschnitt. Die zweite Annotation weist die Test-Methode an
die Testdaten aus der Methode "pwdWirdNichtAkzeptiert" zu beziehen. Der Name der Methode wird als String angegeben.
Das bedeutet, daß der Entwickler für die korrekte Schreibweise verantwortlich ist, Fehler treten auch hier erst zur Laufzeit auf.
Hat die Test-Daten-Methode den gleichen Namen wie die Test-Methode kann sie in
der Annotation auch weggelassen werden. Die Annotation selbst hingegen kann ''nicht'' weggelassen werden.
Da die Methode nur über den Namen referenziert wird, muß der Compiler tatsächlich annehmen,
daß die Method nicht verwendet wird wenn sie als private deklariert wurde.
=== Lambda-Ausdrücke ===
Warum sollte man {{lambda}}-Ausdrücke in einem parametrisierten Test verwenden?
Denkt man etwa an ein Objekt mit einer Reihe von getter- und setter-Methoden,
läßt sich mithilfe von {{lambda}}-Ausdrücken die Objekt-Bestückung sehr kompakt vertesten.

ersetzt man in der oben vorgestellten Befüll-Methode ein String-Argument durch einen {{lambda}}-Ausdruck
läuft der compiler allerdings ganz flott auf einen Fehler, weil der {{lambda}}-Ausdruck nicht in ein Objekt
gecastet werden kann. Dazu braucht es eines (funktionalen) Interfaces. Man kann dazu die vom JDK bereitgestellten
Interfaces nutzen oder eigene Interfaces definieren. Für Unit-Tests ist das zweitere vorzuziehen.

Stellen wir uns also mal eine POJO mit dem klassischen Getter und Setter vor:
{{java|code=
public class Person {
private String vorname;
}}

==Weitere Test-Daten-Provider==
JUnit5 unterstützt noch eine Reihe weiterer Möglichkeiten, Testdaten für parametrisierte Tests zur Verfügung zu
stellen:
*Java-enums
*CSV-Dateien
*Daten im CSV-Format
*separate Klassen
==Enums==
Eine besondere Unterstützung bei der Erstellung parametrisierter Tests erfahren die Java-enums. Grundsätzlich
erfolgt die Parametrisierung wie dies hier am Beispiel von String-Argumenten beschrieben wurde. Auf die
spezifischen Eigenschaften von enums und ihrem besonderen Wert für Unit-Tests wird hier eingegangen.
Betrachten wir ein enum das Versandwege beschreibt:
{{java|code=
enum Versandweg {
E_MAIL,
SMS,
POST
}
}}
und die zu testende Methode die eine TAN über einen Versandweg verschickt:
{{java|code=
public class Versender {
Response sendTan(Versandweg weg) {
...
}
}
}}
===Alle Ausprägungen testen===
Wir können nun für jeden Versandweg eine Test-Methode schreiben. Das geht auch einfacher, wenn wir immer das
gleiche Ergebnis erwarten:
{{java|code=
@ParameterizedTest
@EnumSource(value=Versandweg.class)
void verwandWegLiefertOk(Versandweg weg) {
Assertions.assertThat(new Versender().sendTan(weg)).isEqualTo(Response.OK);
}
}}
Die erste Annotation weist die Methode als parametrisierten Test aus. Die zweite Annotation gibt an, welches enum
für den Test zu verwenden ist. Die Test-Methode selbst muß ein Argument vom Typ des Enums akzeptieren.
Die parametrisierte Version ist nicht nur kompakter. Wird das enum um weitere Ausprägungen ergänzt, werden
automatisch Test dafür generiert. Ob das Ergebnis tatsächlich der gewünschten Anforderung entspricht kann JUnit
natürlich nicht vorhersehen, aber die neue enum-Ausprägung wird zumindest betrachtet und läuft günstigenfalls
auf einen Fehler.
=== Einzelne Ausprägungen testen ===
Möchte man nicht alle Ausprägungen testen sondern nur ganz bestimmte, kann man das der Annotation mitgeben.
dafür gibt es zwei Modes: ''einschließend'' und ''ausschließend''.
Möchten wir etwa nur die Versandwege eMail und SMS testen, können wir die Annotation so schreiben (der ganze Rest bleibt gleich):
{{java|code=@EnumSource(value = Versandweg.class, mode = Mode.INCLUDE, names = { "E_MAIL", "SMS" })}}
Der Parameter {{java|mod}} gibt an, daß nur die angegebenen Ausprägungen getestet werden sollen. Da "Include" der
default ist, kann de Mo in diesem Falle auch weggelassen werden. Der Parameter {{java|names}} ist eine Liste von enum-Ausprägung-Namen die als Strings angegeben werden.
Man kann das vorgehen auch umdrehen un den Versandweg "POST" – als einzigen nicht-elektronischen Weg
ausschließen. Die Annotation sieht dann so aus:
{{java|code=@EnumSource(value = Versandweg.class, mode = Mode.EXCLUDE, names = { "POST" })}}
Der {{java|mode}}-Parameter hat nun den Wert {{java|EXCLUDE}} und darf natürlich nicht weggelassen werden. Der Parameter
{{java|names}} ist wieder eine Liste von enum-Ausprägung-Namen die hier aus einem einzigen Wert besteht.
In beiden Fällen ist der Entwickler für die korrekte Schreibweise der Namen der enum-Ausprägungen
verantwortlich. Stimmt sie nicht überein, giebt's einen Laufzeitfehler bei der Test-Ausführung.
Während bei "INCLUDE" nur so viel Tests erzeugt werden, wie enum-Ausprägungen spezifiziert wurden, werden bei
"EXCLUDE" Tests für alle Ausprägungen erzeugt die nicht angegeben sind. Wird das enum um Ausprägungen
erweitert, dann werden im EXCLUDE-Falle neue Tests generiert, im INCLUDE-Falle nicht.

===Pattern-Matching===
Mit den beiden Modes MATCH_ALL und MATCH_ANY können die Namen von enum-Ausprägungen mit Hilfe von
regulären Ausdrücken spezifiziert werden. Dieses Vorgehen ist jedoch problematisch und soll hier nicht weiter
erörtert werden. Macht man bei Definition der Ausdrücke Fehler, kann es beispielsweise passieren, daß
Ausprägungen ausgelassen werden und für diese dann keine Tests erzeugt werden. Das fällt nur auf wenn die TestAusführung manuell überprüft wird.
===Test-Fälle als Enumerationen===
bei der Verwendung von enum-Sources ist man nicht auf "produktive" enums beschränkt. Man kann auch Test-Situationen über enums definieren und diese
enums dann verwenden um parametrisierte Tests zu füttern. Man kann zum Beispiel für die Test-Klasse enum "Kunde" definieren, dessen Ausprägungen
jeweils einzelne Test-Konstellationen beschreiben. Damit lassen sich parametrisierte Tests definieren, die alle oder ausgewählte Konstellationen testen:
{{java|code=
@ParameterizedTest
@EnumSource(value = Kunde.class, names = { "MIT_KDNR", "MIT_IHNR", "MIT_KDNR_UND_IHNR" })
void darfElektronischeDokumentEinstellungSehen(Kunde kunde) {
assertThat(verwalter(kunde).darfElectronicDocumentsSehen()).isTrue();
}
}}
In diesem Beispiel wurde Kunden konfiguriert die ein Kunden- oder Inhabernummer oder beides haben. Jeder der
Kunden muß seine elektronischen Dokumente sehen dürfen.

== Test-Beschreibung ==
Parameterisierte Tests unterscheiden sich zunächst nur in ihren Argumenten. Wenn JUnit die Tests ausführt,
wird aus den Argumenten eine beschreibung generiert die nicht immer leicht zu entziffern ist.

Alternativ kann man der Annotation einen String mitgeben aus dem der Name generiert wird:
{{java|code=
@ParameterizedTest(name = "Test")
}}
Das Beispiel ist extrem unnütz, denn jetzt haben alle Einzel-Tests die gleiche Beschreibung -- "Test".
Um daraus eine brauchbare Beschreibung zu machen bietet JUnit5 Textersatz an:

Verwendet man {{java|{index}}} in der Beschreibung, wird die Nummer des Tests angezeigt. Sehr praktisch, wenn man den Testfall später sucht.

Die übergebenen Parameter kann man mit {{java|{x}}} anzeigen, wobei {{java|x}} für die Positions-Nummer eines Parameters steht -- beginnend mit 0.

Java 17: Switch

2024-03-28T20:04:49Z

Ullrich:

[[Category:Java]]
Um die Erwartungen vorab zu dämpfen:
Auch Java 17 erlaubt nur die aufzählbaren Daten-Type sowie String, aber keine anderne Objekt-Typen.
Auch führt der Aufruf mit {{java|null}} weiterhin unweigerlich zu einer Null-Pointer-Exception.
So ''richtig'' cool wird das {{java|switch}} allerdings mit Java 21...

Betrachten wir die klassische Anwendung der {{java|switch}}-Kontrollstruktur:
{{java|code=
public void oldStyleOhneBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
case ANT, BEE:
System.out.println("6 legs");
default:
System.out.println("strange animal");
}
}
}}
Der Aufruf von {{java|oldStyleOhneBreak(Animal.ANT)}} liefert:
6 legs
strange animal
Wegen des "fall-through"-Verhaltens (was man berechtigterweise mit "Durchfall" übersetzen kann) werden
alle nachfolgenden Fälle durchlaufen, sobald der erste Match auftritt. Um das zu verhindern, muß man nach
jeder {{java|case}}-Anweisung ein {{java|break}} einfügen:
{{java|code=
public void oldStyleWithBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
break;
case ANT, BEE:
System.out.println("6 legs");
break;
default:
System.out.println("strange animal");
}
}
}}
Das ist viel Code, unübersichtlich, fehleranfällig -- und kontrovers.
Java 17 bietet nun eine Alternative, bei der der {{java|:}} in der Case-Anweisung durch {{java|->}}.
Es muß aber ausdrücklich darauf hingeweisen werden, daß es sich hier um '''keinen''' {{lambda}}-Ausdruck handelt.
Das Ergebnis der ersten Fassung sieht nun so aus:
{{java|code=
public void newStyle(Animal animal) {
switch (animal) {
case SPIDER -> System.out.println("8 legs");
case ANT, BEE -> System.out.println("6 legs");
default -> System.out.println("strange animal");
}
}
}}
Da für jeden Fall hier nur eine Zeile verwendet wird, ist der gesamte Ausdruck kompakter.
Das könnte man durchaus auch mit dem klassischen {{java|case}}-Konstrukt hinkriegen.

Überraschender ist aber das Ergebnis, wenn man {{java|newStyle(Animal.ANT)}} ausführt:
6 legs
Das {{java|break}} wird nicht mehr benötigt, der neue Stil hat keine Durchfall-Symptome mehr!

Nach dem {{java|->}} darf eine beliebige Anweisung kommen.
Anstelle einer ''einzelnen'' Anweisung ist also auch ein beliebig großer Code-Block erlaubt.

Da wir in jedem der Fälle die gleiche Aktion ausführen, könnten wir uns auch den Ausgabe-Text liefern lassen
und ihn im Anschluß ausgeben. Genau dafür bietet das neue {{java|switch}} eine Möglichkeit:
{{java|code=
public void newStyleWithReturnValue(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
default -> "strange animal";
};
System.out.println(legs);
}
}}
Man kann sich vorstellen, daß {{java|switch}} ''immer'' einen Rückgabe-Typ hat, der allerdings in den vorangehenden Beispielen
{{java|void}} war und daher nicht gespeichert werden konnte. Java prüft in jedem Fall den Typ und meldet Verstöße die durch
Inkompatibilität entstehen.

Was machen wir nun, wenn nach dem {{java|->}} kein Ausdruck vom gewünschten Typ kommt, sondern ein ganzer Code-Block?
Hier hilft das {{java|yield}}. Es kommt am Ende des Code-Blocks und giebt den Wert zurück:
{{java|code=
public void newStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
case CENTIPEDE -> {
System.err.println("lost count");
yield "many legs";
}
default -> "strange animal";
};
System.out.println(legs);
}
}}

{{java|yield}} ist -- entgegen der ersten Vermutung -- ''kein'' keyword, sondern ein "reservierter Identifier".
So ist die Anweisung
{{java|code=
int yield = 5;
}}
durchaus erlaubt. Es erübrigt sich, darauf hinzuweisen diese Verwendung zu vermeiden.

Freundlicherweise darf man das {{java|yield}} auch mit dem {{java|switch}} im alten Stil verwenden.
Da dabei das {{java|switch}} unmittelbar verlassen wird, spart man sich dabei das {{java|break}}:
{{java|code=
public void oldStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER:
yield "8 legs";
case ANT, BEE:
yield "6 legs";
default:
yield "strange animal";
};
System.out.println(legs);
}
}}

== Fazit ==

Das gemeine {{java|switch}} wird durch die Verwendung von {{java|->}} kompakter und veständlicher.
Folgt man allerdings der Regel möglichst kleine Methoden zu schreiben, wird man praktisch jedes {{java|witch}}
in eine eigene Methode auslagern. Die Rückgabe-Notation bietet dann keine nennenswerten Gewinn mehr,
man spart sich allerdings bei Verwendung von {{java|->}} das {{java|return}}.

Nichstdestotrotz hilft das Feature dabei, legacy-Code zu optimieren und darüber zu refactorn.
Dazu schreibt man das {{java|switch}} erst auf die Rückgabe-Notation um und lagert sie dann in eine eigene Methode aus.

Java 17: Switch

2024-03-28T20:04:31Z

Ullrich:

[[Category:Java]]
Um die Erwartungen vorab zu dämpfen:
Auch Java 17 erlaubt nur die aufzählbaren Daten-Type sowie String, aber keine anderne Objekt-Typen.
Auch führt der Aufruf mit {{java|null}} weiterhin unweigerlich zu einer Null-Pointer-Exception.
So richtig ''cool'' wird das {{java|switch}} allerdings mit Java 21...

Betrachten wir die klassische Anwendung der {{java|switch}}-Kontrollstruktur:
{{java|code=
public void oldStyleOhneBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
case ANT, BEE:
System.out.println("6 legs");
default:
System.out.println("strange animal");
}
}
}}
Der Aufruf von {{java|oldStyleOhneBreak(Animal.ANT)}} liefert:
6 legs
strange animal
Wegen des "fall-through"-Verhaltens (was man berechtigterweise mit "Durchfall" übersetzen kann) werden
alle nachfolgenden Fälle durchlaufen, sobald der erste Match auftritt. Um das zu verhindern, muß man nach
jeder {{java|case}}-Anweisung ein {{java|break}} einfügen:
{{java|code=
public void oldStyleWithBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
break;
case ANT, BEE:
System.out.println("6 legs");
break;
default:
System.out.println("strange animal");
}
}
}}
Das ist viel Code, unübersichtlich, fehleranfällig -- und kontrovers.
Java 17 bietet nun eine Alternative, bei der der {{java|:}} in der Case-Anweisung durch {{java|->}}.
Es muß aber ausdrücklich darauf hingeweisen werden, daß es sich hier um '''keinen''' {{lambda}}-Ausdruck handelt.
Das Ergebnis der ersten Fassung sieht nun so aus:
{{java|code=
public void newStyle(Animal animal) {
switch (animal) {
case SPIDER -> System.out.println("8 legs");
case ANT, BEE -> System.out.println("6 legs");
default -> System.out.println("strange animal");
}
}
}}
Da für jeden Fall hier nur eine Zeile verwendet wird, ist der gesamte Ausdruck kompakter.
Das könnte man durchaus auch mit dem klassischen {{java|case}}-Konstrukt hinkriegen.

Überraschender ist aber das Ergebnis, wenn man {{java|newStyle(Animal.ANT)}} ausführt:
6 legs
Das {{java|break}} wird nicht mehr benötigt, der neue Stil hat keine Durchfall-Symptome mehr!

Nach dem {{java|->}} darf eine beliebige Anweisung kommen.
Anstelle einer ''einzelnen'' Anweisung ist also auch ein beliebig großer Code-Block erlaubt.

Da wir in jedem der Fälle die gleiche Aktion ausführen, könnten wir uns auch den Ausgabe-Text liefern lassen
und ihn im Anschluß ausgeben. Genau dafür bietet das neue {{java|switch}} eine Möglichkeit:
{{java|code=
public void newStyleWithReturnValue(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
default -> "strange animal";
};
System.out.println(legs);
}
}}
Man kann sich vorstellen, daß {{java|switch}} ''immer'' einen Rückgabe-Typ hat, der allerdings in den vorangehenden Beispielen
{{java|void}} war und daher nicht gespeichert werden konnte. Java prüft in jedem Fall den Typ und meldet Verstöße die durch
Inkompatibilität entstehen.

Was machen wir nun, wenn nach dem {{java|->}} kein Ausdruck vom gewünschten Typ kommt, sondern ein ganzer Code-Block?
Hier hilft das {{java|yield}}. Es kommt am Ende des Code-Blocks und giebt den Wert zurück:
{{java|code=
public void newStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
case CENTIPEDE -> {
System.err.println("lost count");
yield "many legs";
}
default -> "strange animal";
};
System.out.println(legs);
}
}}

{{java|yield}} ist -- entgegen der ersten Vermutung -- ''kein'' keyword, sondern ein "reservierter Identifier".
So ist die Anweisung
{{java|code=
int yield = 5;
}}
durchaus erlaubt. Es erübrigt sich, darauf hinzuweisen diese Verwendung zu vermeiden.

Freundlicherweise darf man das {{java|yield}} auch mit dem {{java|switch}} im alten Stil verwenden.
Da dabei das {{java|switch}} unmittelbar verlassen wird, spart man sich dabei das {{java|break}}:
{{java|code=
public void oldStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER:
yield "8 legs";
case ANT, BEE:
yield "6 legs";
default:
yield "strange animal";
};
System.out.println(legs);
}
}}

== Fazit ==

Das gemeine {{java|switch}} wird durch die Verwendung von {{java|->}} kompakter und veständlicher.
Folgt man allerdings der Regel möglichst kleine Methoden zu schreiben, wird man praktisch jedes {{java|witch}}
in eine eigene Methode auslagern. Die Rückgabe-Notation bietet dann keine nennenswerten Gewinn mehr,
man spart sich allerdings bei Verwendung von {{java|->}} das {{java|return}}.

Nichstdestotrotz hilft das Feature dabei, legacy-Code zu optimieren und darüber zu refactorn.
Dazu schreibt man das {{java|switch}} erst auf die Rückgabe-Notation um und lagert sie dann in eine eigene Methode aus.

Java 17: Switch

2024-03-28T20:03:03Z

Ullrich:

[[Category:Java]]
Um die Erwartungen vorab zu dämpfen:
Auch Java 17 erlaubt nur die aufzählbaren Daten-Type sowie String, aber keine anderne Objekt-Typen.
Auch führt der Aufruf mit {{java|null}} weiterhin unweigerlich zu einer Null-Pointer-Exception.

Betrachten wir die klassische Anwendung der {{java|switch}}-Kontrollstruktur:
{{java|code=
public void oldStyleOhneBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
case ANT, BEE:
System.out.println("6 legs");
default:
System.out.println("strange animal");
}
}
}}
Der Aufruf von {{java|oldStyleOhneBreak(Animal.ANT)}} liefert:
6 legs
strange animal
Wegen des "fall-through"-Verhaltens (was man berechtigterweise mit "Durchfall" übersetzen kann) werden
alle nachfolgenden Fälle durchlaufen, sobald der erste Match auftritt. Um das zu verhindern, muß man nach
jeder {{java|case}}-Anweisung ein {{java|break}} einfügen:
{{java|code=
public void oldStyleWithBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
break;
case ANT, BEE:
System.out.println("6 legs");
break;
default:
System.out.println("strange animal");
}
}
}}
Das ist viel Code, unübersichtlich, fehleranfällig -- und kontrovers.
Java 17 bietet nun eine Alternative, bei der der {{java|:}} in der Case-Anweisung durch {{java|->}}.
Es muß aber ausdrücklich darauf hingeweisen werden, daß es sich hier um '''keinen''' {{lambda}}-Ausdruck handelt.
Das Ergebnis der ersten Fassung sieht nun so aus:
{{java|code=
public void newStyle(Animal animal) {
switch (animal) {
case SPIDER -> System.out.println("8 legs");
case ANT, BEE -> System.out.println("6 legs");
default -> System.out.println("strange animal");
}
}
}}
Da für jeden Fall hier nur eine Zeile verwendet wird, ist der gesamte Ausdruck kompakter.
Das könnte man durchaus auch mit dem klassischen {{java|case}}-Konstrukt hinkriegen.

Überraschender ist aber das Ergebnis, wenn man {{java|newStyle(Animal.ANT)}} ausführt:
6 legs
Das {{java|break}} wird nicht mehr benötigt, der neue Stil hat keine Durchfall-Symptome mehr!

Nach dem {{java|->}} darf eine beliebige Anweisung kommen.
Anstelle einer ''einzelnen'' Anweisung ist also auch ein beliebig großer Code-Block erlaubt.

Da wir in jedem der Fälle die gleiche Aktion ausführen, könnten wir uns auch den Ausgabe-Text liefern lassen
und ihn im Anschluß ausgeben. Genau dafür bietet das neue {{java|switch}} eine Möglichkeit:
{{java|code=
public void newStyleWithReturnValue(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
default -> "strange animal";
};
System.out.println(legs);
}
}}
Man kann sich vorstellen, daß {{java|switch}} ''immer'' einen Rückgabe-Typ hat, der allerdings in den vorangehenden Beispielen
{{java|void}} war und daher nicht gespeichert werden konnte. Java prüft in jedem Fall den Typ und meldet Verstöße die durch
Inkompatibilität entstehen.

Was machen wir nun, wenn nach dem {{java|->}} kein Ausdruck vom gewünschten Typ kommt, sondern ein ganzer Code-Block?
Hier hilft das {{java|yield}}. Es kommt am Ende des Code-Blocks und giebt den Wert zurück:
{{java|code=
public void newStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
case CENTIPEDE -> {
System.err.println("lost count");
yield "many legs";
}
default -> "strange animal";
};
System.out.println(legs);
}
}}

{{java|yield}} ist -- entgegen der ersten Vermutung -- ''kein'' keyword, sondern ein "reservierter Identifier".
So ist die Anweisung
{{java|code=
int yield = 5;
}}
durchaus erlaubt. Es erübrigt sich, darauf hinzuweisen diese Verwendung zu vermeiden.

Freundlicherweise darf man das {{java|yield}} auch mit dem {{java|switch}} im alten Stil verwenden.
Da dabei das {{java|switch}} unmittelbar verlassen wird, spart man sich dabei das {{java|break}}:
{{java|code=
public void oldStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER:
yield "8 legs";
case ANT, BEE:
yield "6 legs";
default:
yield "strange animal";
};
System.out.println(legs);
}
}}

== Fazit ==

Das gemeine {{java|switch}} wird durch die Verwendung von {{java|->}} kompakter und veständlicher.
Folgt man allerdings der Regel möglichst kleine Methoden zu schreiben, wird man praktisch jedes {{java|witch}}
in eine eigene Methode auslagern. Die Rückgabe-Notation bietet dann keine nennenswerten Gewinn mehr,
man spart sich allerdings bei Verwendung von {{java|->}} das {{java|return}}.

Nichstdestotrotz hilft das Feature dabei, legacy-Code zu optimieren und darüber zu refactorn.
Dazu schreibt man das {{java|switch}} erst auf die Rückgabe-Notation um und lagert sie dann in eine eigene Methode aus.

Java 17: Switch

2024-03-28T19:59:03Z

Ullrich:

[[Category:Java]]
Um die Erwartungen vorab zu dämpfen:
Auch Java 17 erlaubt nur die aufzählbaren Daten-Type sowie String, aber keine anderne Objekt-Typen.
Auch führt der Aufruf mit {{java|null}} weiterhin unweigerlich zu einer Null-Pointer-Exception.

Betrachten wir die klassische Anwendung der {{java|switch}}-Kontrollstruktur:
{{java|code=
public void oldStyleOhneBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
case ANT, BEE:
System.out.println("6 legs");
default:
System.out.println("strange animal");
}
}
}}
Der Aufruf von {{java|oldStyleOhneBreak(Animal.ANT)}} liefert:
6 legs
strange animal
Wegen des "fall-through"-Verhaltens (was man berechtigterweise mit "Durchfall" übersetzen kann) werden
alle nachfolgenden Fälle durchlaufen, sobald der erste Match auftritt. Um das zu verhindern, muß man nach
jeder {{java|case}}-Anweisung ein {{java|break}} einfügen:
{{java|code=
public void oldStyleWithBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
break;
case ANT, BEE:
System.out.println("6 legs");
break;
default:
System.out.println("strange animal");
}
}
}}
Das ist viel Code, unübersichtlich, fehleranfällig -- und kontrovers.
Java 17 bietet nun eine Alternative, bei der der {{java|:}} in der Case-Anweisung durch {{java|->}}.
Es muß aber ausdrücklich darauf hingeweisen werden, daß es sich hier um '''keinen''' {{lambda}}-Ausdruck handelt.
Das Ergebnis der ersten Fassung sieht nun so aus:
{{java|code=
public void newStyle(Animal animal) {
switch (animal) {
case SPIDER -> System.out.println("8 legs");
case ANT, BEE -> System.out.println("6 legs");
default -> System.out.println("strange animal");
}
}
}}
Da für jeden Fall hier nur eine Zeile verwendet wird, ist der gesamte Ausdruck kompakter.
Das könnte man durchaus auch mit dem klassischen {{java|case}}-Konstrukt hinkriegen.

Überraschender ist aber das Ergebnis, wenn man {{java|newStyle(Animal.ANT)}} ausführt:
6 legs
Das {{java|break}} wird nicht mehr benötigt, der neue Stil hat keine Durchfall-Symptome mehr!

Nach dem {{java|->}} darf eine beliebige Anweisung kommen.
Anstelle einer ''einzelnen'' Anweisung ist also auch ein beliebig großer Code-Block erlaubt.

Da wir in jedem der Fälle die gleiche Aktion ausführen, könnten wir uns auch den Ausgabe-Text liefern lassen
und ihn im Anschluß ausgeben. Genau dafür bietet das neue switch eine Möglichkeit:
{{java|code=
public void newStyleWithReturnValue(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
default -> "strange animal";
};
System.out.println(legs);
}
}}
Man kann sich vorstellen, daß switch ''immer'' einen Rückgabe-Typ hat, der allerdings in den vorangehenden Beispielen
{{java|void}} war und daher nicht gespeichert werden konnte. Java prüft in jedem Fall den typ und meldet Verstöße die durch
Inkompatibilität entstehen.

Was machen wir nun, wenn nach dem {{java|->}} kein Ausdruck vom gewünschten Typ kommt, sondern ein ganzer Code-Block?
Hier hilft das {{java|yield}}. Es kommt am Ende des Code-Blocks und giebt den Wert zurück:
{{java|code=
public void newStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
case CENTIPEDE -> {
System.err.println("lost count");
yield "many legs";
}
default -> "strange animal";
};
System.out.println(legs);
}
}}

{{java|yield}} ist -- entgegen der ersten Vermutung -- ''kein'' keyword, sondern ein "reservierter Identifier".
So ist die Anweisung
{{java|code=
int yield = 5;
}}
duirchaus erlaubt. Es erübrigt sich, darauf hinzuweisen diese Verwendung zu vermeiden.

Freundlicherweise darf man das {{java|yield}} auch mit dem {{java|switch}} im alten Stil verwenden.
Da dabei das {{java|switch}} unmittelbar verlassen wird, spart man sich dabei das {{java|break}}:
{{java|code=
public void oldStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER:
yield "8 legs";
case ANT, BEE:
yield "6 legs";
default:
yield "strange animal";
};
System.out.println(legs);
}
}}

== Fazit ==

Das gemeine {{java|switch}} wird durch die Verwendung von {{java|->}} kompakter und veständlicher.
Folgt man allerdings der Regel möglichst kleine Methoden zu schreiben, wird man praktisch jedes {{java|witch}}
in eine eigene Methode auslagern. Die Rückgabe-Notation bietet dann keine nennenswerten Gewinn mehr.

Nichstdestotrotz hilft das Feature dabei, legacy-Code zu optimieren und darüber zu refactorn.
Dazu schreibt man das {{java|switch}} erst auf die Rückgabe-Notation um und lagert sie dann in eine eigene Methode aus.

Java 17: Switch

2024-03-28T19:57:55Z

Ullrich:

[[Category:Java]]
Um die Erwartungen vorab zu dämpfen:
Auch Java 17 erlaubt nur die aufzählbaren Daten-Type sowie String, aber keine anderne Objekt-Typen.
Auch führt der Aufruf mit {{java|null}} weiterhin unweigerlich zu einer Null-Pointer-Exception.

Betrachten wir die klassische Anwendung der {{java|switch}}-Kontrollstruktur:
{{java|code=
public void oldStyleOhneBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
case ANT, BEE:
System.out.println("6 legs");
default:
System.out.println("strange animal");
}
}
}}
Der Aufruf von {{java|oldStyleOhneBreak(Animal.ANT)}} liefert:
6 legs
strange animal
Wegen des "fall-through"-Verhaltens (was man berechtigterweise mit "Durchfall" übersetzen kann) werden
alle nachfolgenden Fälle durchlaufen, sobald der erste Match auftritt. Um das zu verhindern, muß man nach
jeder {{java|case}}-Anweisung ein {{java|break}} einfügen:
{{java|code=
public void oldStyleWithBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
break;
case ANT, BEE:
System.out.println("6 legs");
break;
default:
System.out.println("strange animal");
}
}
}}
Das ist viel Code, unübersichtlich, fehleranfällig -- und kontrovers.
Java 17 bietet nun eine Alternative, bei der der {{java|:}} in der Case-Anweisung durch {{java|->}}.
Es muß aber ausdrücklich darauf hingeweisen werden, daß es sich hier um '''keinen''' {{lambda}}-Ausdruck handelt.
Das Ergebnis der ersten Fassung sieht nun so aus:
{{java|code=
public void newStyle(Animal animal) {
switch (animal) {
case SPIDER -> System.out.println("8 legs");
case ANT, BEE -> System.out.println("6 legs");
default -> System.out.println("strange animal");
}
}
}}
Da für jeden Fall hier nur eine Zeile verwendet wird, ist der gesamte Ausdruck kompakter.
Das könnte man durchaus auch mit dem klassischen {{java|case}}-Konstrukt hinkriegen.

Überraschender ist aber das Ergebnis, wenn man {{java|newStyle(Animal.ANT)}} ausführt:
6 legs
Das {{java|break}} wird nicht mehr benötigt, der neue Stil hat keine Durchfall-Symptome mehr!

Nach dem {{java|->}} darf eine beliebige Anweisung kommen.
Anstelle einer ''einzelnen'' Anweisung ist also auch ein beliebig großer Code-Block erlaubt.

Da wir in jedem der Fälle die gleiche Aktion ausführen, könnten wir uns auch den Ausgabe-Text liefern lassen
und ihn im Anschluß ausgeben. Genau dafür bietet das neue switch eine Möglichkeit:
{{java|code=
public void newStyleWithReturnValue(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
default -> "strange animal";
};
System.out.println(legs);
}
}}
Man kann sich vorstellen, daß switch ''immer'' einen Rückgabe-Typ hat, der allerdings in den vorangehenden Beispielen
{{java|void}} war und daher nicht gespeichert werden konnte. Java prüft in jedem Fall den typ und meldet Verstöße die durch
Inkompatibilität entstehen.

Was machen wir nun, wenn nach dem {{java|->}} kein Ausdruck vom gewünschten Typ kommt, sondern ein ganzer Code-Block?
Hier hilft das {{java|yield}}. Es kommt am Ende des Code-Blocks und giebt den Wert zurück:
{{java|code=
public void newStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
case CENTIPEDE -> {
System.err.println("lost count");
yield "many legs";
}
default -> "strange animal";
};
System.out.println(legs);
}
}}

{{java|yield}} ist -- entgegen der ersten Vermutung -- ''kein'' keyword, sondern ein "reservierter Identifier".
So ist die Anweisung
{{java|code=
int yield = 5;
}}
duirchaus erlaubt. Es erübrigt sich, darauf hinzuweisen diese Verwendung zu vermeiden.

Freundlicherweise darf man das {{java|yield}} auch mit dem {{java|switch}} im alten Stil verwenden.
Da dabei das {{java|switch}} unmittelbar verlassen wird, spart man sich dabei das {{break}}:
{{java|code=
public void oldStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER:
yield "8 legs";
case ANT, BEE:
yield "6 legs";
default:
yield "strange animal";
};
System.out.println(legs);
}
}}

== Fazit ==

Das gemeine {{java|switch}} wird durch die Verwendung von {{java|->}} kompakter und veständlicher.
Folgt man allerdings der Regel möglichst kleine Methoden zu schreiben, wird man praktisch jedes {{java|witch}}
in eine eigene Methode auslagern. Die Rückgabe-Notation bietet dann keine nennenswerten Gewinn mehr.

Nichstdestotrotz hilft das Feature dabei, legacy-Code zu optimieren und darüber zu refactorn.
Dazu schreibt man das {{java|switch}} erst auf die Rückgabe-Notation um und lagert sie dann in eine eigene Methode aus.

Parametrisierte Tests

2024-03-19T19:19:52Z

Ullrich: /* Und was ist mit null? */

[[Category:Java]]
[[Category:junit]]
Ein einzelner Unit-Tests befaßt sich mit einem einzelnen Test-Fall und hat im Regelfall eine einzelne Assertion.
Dieses einfache Beispiel testet die korrekte Konvertierung von Datum-Strings in ein Date-Objekt. Die drei Assertions
prüfen hier zusammen, ob das Datum korrekt ist:
{{java|code=
@Test
public void toDateLiefertKorrektesDatum() {
Date convertedDate = Convert.toDate("01.5.1985");
assertThat(convertedDate).hasDayOfMonth(1);
assertThat(convertedDate).hasMonth(5);
assertThat(convertedDate).hasYear(1985);
}
}}
Nun soll er Konverter mit unterschiedlichen Datums-Angaben umgehen: Mit und ohne führende Nullen, mit und
ohne Jahrhundert, vielleicht soll auch ein Minuszeichen anstelle des Punkts erlaubt sein. Für jeden Testfall kann
man nun die Test-Methode kopieren und entsprechend anpassen. Die Folgen sind klar: jede Menge Test-Code,
sinkende Übersichtlichkeit und für jede neue Test-Methode braucht es einen neuen Namen. Das DRY-Prinzip soll
auch für Test-Code gelten.

Eine wesentliche Bereicherung von JUnit-5 ist die Unterstützung von Parameter-gesteuerten Test-Methoden die
weit über das hinausgeht was JUnit-4 oder Test-NG zu bieten hatten. Eine Vielzahl von Test-Situationen läßt sich
damit abdecken und vor allem eindampfen.
==Eine Liste einzelner Parameter==
Betrachten wir –- angelehnt an das einleitende Beispiel -– die einfachste Situation: Einen Testfall soll mit einer Reihe
einzelner Strings aufgerufen werden. Dazu parametrisieren wir zunächst die Test-Methode und ziehen den Datum-String als Parameter heraus:
{{java|code=
public void toDateLiefertKorrektesDatum(String datum) {
Date convertedDate = Convert.toDate(datum);
assertThat(convertedDate).hasDayOfMonth(1);
assertThat(convertedDate).hasMonth(5);
assertThat(convertedDate).hasYear(1985);
}
}}
Dann legen wir die Datum-Strings fest mit denen getestet werden soll:
{{java|"1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985"}}
Um die neue Test-Methode mit den Test-Fälle zu verknüpfen verwenden wir JUnit5-Annotations und setzen sie
über unsere parametrisierte Test-Methode:
{{java|code=
@ParameterizedTest
@ValueSource(strings = { "1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985" })
}}
Die erste Annotation ersetzt die @Test-Annotation und macht die Methode zum (parametrisierten) Test.
Die zweite Annotation legt die Quelle der zu verwendenden Werte fest.
In diesem Falle ist dies eine Liste von Strings. Der Test wird bei der
Ausführung für jeden String einmal aufgerufen, wobei der jeweilige String als Argument übergeben wird.
Anstelle von Strings sind hier auch alle numerischen, primitiven Typen int, long, float und einiges mehr erlaubt.
Die Anntotations-Parameter kann man in Eclipse mit Code-Assist erkunden oder in der JUnit5-Doku nachlesen.
=== Und was ist mit null? ===
Die eben vorgestellte Werte-Liste hat einen kleinen Haken: Es ist nicht möglich, den Wert null als Argument zu
verwenden. Um einen Testfall für null zu erzeugen, kann man nun freilich eine neue Test-Methode erstellen und
null separat in diesem Test prüfen. Man kann dem Test aber auch zusätzlich die Annotation {{java|@NullSource}}
hinzufügen. JUnit5 erzeugt dann einen zusätzlichen Testfall für null:
{{java|code=
@ParameterizedTest
@NullSource
@ValueSource(strings = { "1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985" })
public void toDateLiefertKorrektesDatum(String datum) {
// hier kommt der Test-Code hin...
}
}}
Unterstützt wird {{java|@NullSource}} ab Version 5.4

== Mehrere Parameter für die Test-Methode ==
Dieser Abschnitt beschreibt die einfachste Variante, weitere Möglichkeiten werden [[Testdaten-Provider|hier]] beschrieben.

Für viele Unit-Tests reicht die Extraktion eines einzelnen Parameters nicht aus. Im folgenden Beispiel wird die
Qualität von Passworten getestet. Das Wort "Hallo" zum Beispiel wird abgewiesen, weil es nur Buchstaben enthält:
public void passwortWirdNichtAkzeptiert() {
assertThat(policy.validate("Hallo")).as("nur Buchstaben").isFalse();
}
Wofür die Parameter in der Test-Methode verwendet werden, spielen keine Rolle, es geht nur darum, den Test
mehrfach aufzurufen und dabei ''mehrere'' Parameter zu übergeben. Im vorliegenden Falle möchten wir
unterschiedliche Passwort-Kandidaten testen und dabei jeden Test mit einer Beschreibung versehen, der Auskunft
gibt warum das Wort nicht als Passwort akzeptiert wird. Die Test-Methode sieht nun so aus:
{{java|code=
public void passwortWirdNichtAkzeptiert(String passwort, String grund) {
assertThat(policy.validate(passwort)).as(grund).isFalse();
}
}}
Für die Erzeugung der Test-Daten schreiben wir diesmal eine weitere Methode.
Sie erzeugt einen Stream von Arguments-Objekten von denen jedes die Daten für ''einen'' Test-Aufruf enthält:
{{java|code=
static Stream<Arguments> pwdWirdNichtAkzeptiert() {
return Stream.of(
Arguments.of("Hallo", "nur Buchstaben"),
Arguments.of("1234567", "nur Ziffern"),
Arguments.of("!%#&/()", "nur Sonderzeichen")
);
}
}}
Die Methode für die Testdaten-Erzeugung muß folgende Eigenschaften haben:
*sie muß static deklariert sein
*sie muß zur Test-Klasse gehören
*sie darf keinen Parameter haben und muß einen Stream von Arguments-Objekten liefern
*sie darf in beliebiger Sichtbarkeit deklariert werden
Die Methode darf zwar private deklariert werden, Java wird sich aber darüber beschweren, daß die Methode
nirgends verwendet wird. Warum das so ist, erfahren wir weiter unten.
Am einfachsten deklariert man sie daher package visible.

Die Klasse
{{java|org.junit.jupiter.params.provider.Arguments}}
ist ein Container, der eine Reihe von Werten beliebigen Typs (mit Ausnahme von {{Lambda}}-Ausdrücken) in fester
Reihenfolge aufnimmt. JUnit5 mappt die Werte der {{java|Arguments}}-Objekte auf die Parameter der Test-Methode. Das
geschieht allerdings erst zur Laufzeit, der Entwickler ist daher selbst dafür verantwortlich die Typen zwischen
Testdaten-Provider und Test-Methode in Übereinstimmung zu halten.

Wir bringen nun Test-Methode und Testdaten-Provider-Methode zusammen. Das geschieht mithilfe folgender JUnit5-Annotationen:
{{java|code=
@ParameterizedTest
@MethodSource("pwdWirdNichtAkzeptiert")
}}
Die erste Annotation kennen wir schon aus dem vorangegangenen Abschnitt. Die zweite Annotation weist die Test-Methode an
die Testdaten aus der Methode "pwdWirdNichtAkzeptiert" zu beziehen. Der Name der Methode wird als String angegeben.
Das bedeutet, daß der Entwickler für die korrekte Schreibweise verantwortlich ist, Fehler treten auch hier erst zur Laufzeit auf.
Hat die Test-Daten-Methode den gleichen Namen wie die Test-Methode kann sie in
der Annotation auch weggelassen werden. Die Annotation selbst hingegen kann ''nicht'' weggelassen werden.
Da die Methode nur über den Namen referenziert wird, muß der Compiler tatsächlich annehmen,
daß die Method nicht verwendet wird wenn sie als private deklariert wurde.
=== Lambda-Ausdrücke ===

==Weitere Test-Daten-Provider==
JUnit5 unterstützt noch eine Reihe weiterer Möglichkeiten, Testdaten für parametrisierte Tests zur Verfügung zu
stellen:
*Java-enums
*CSV-Dateien
*Daten im CSV-Format
*separate Klassen
==Enums==
Eine besondere Unterstützung bei der Erstellung parametrisierter Tests erfahren die Java-enums. Grundsätzlich
erfolgt die Parametrisierung wie dies hier am Beispiel von String-Argumenten beschrieben wurde. Auf die
spezifischen Eigenschaften von enums und ihrem besonderen Wert für Unit-Tests wird hier eingegangen.
Betrachten wir ein enum das Versandwege beschreibt:
{{java|code=
enum Versandweg {
E_MAIL,
SMS,
POST
}
}}
und die zu testende Methode die eine TAN über einen Versandweg verschickt:
{{java|code=
public class Versender {
Response sendTan(Versandweg weg) {
...
}
}
}}
===Alle Ausprägungen testen===
Wir können nun für jeden Versandweg eine Test-Methode schreiben. Das geht auch einfacher, wenn wir immer das
gleiche Ergebnis erwarten:
{{java|code=
@ParameterizedTest
@EnumSource(value=Versandweg.class)
void verwandWegLiefertOk(Versandweg weg) {
Assertions.assertThat(new Versender().sendTan(weg)).isEqualTo(Response.OK);
}
}}
Die erste Annotation weist die Methode als parametrisierten Test aus. Die zweite Annotation gibt an, welches enum
für den Test zu verwenden ist. Die Test-Methode selbst muß ein Argument vom Typ des Enums akzeptieren.
Die parametrisierte Version ist nicht nur kompakter. Wird das enum um weitere Ausprägungen ergänzt, werden
automatisch Test dafür generiert. Ob das Ergebnis tatsächlich der gewünschten Anforderung entspricht kann JUnit
natürlich nicht vorhersehen, aber die neue enum-Ausprägung wird zumindest betrachtet und läuft günstigenfalls
auf einen Fehler.
=== Einzelne Ausprägungen testen ===
Möchte man nicht alle Ausprägungen testen sondern nur ganz bestimmte, kann man das der Annotation mitgeben.
dafür gibt es zwei Modes: ''einschließend'' und ''ausschließend''.
Möchten wir etwa nur die Versandwege eMail und SMS testen, können wir die Annotation so schreiben (der ganze Rest bleibt gleich):
{{java|code=@EnumSource(value = Versandweg.class, mode = Mode.INCLUDE, names = { "E_MAIL", "SMS" })}}
Der Parameter {{java|mod}} gibt an, daß nur die angegebenen Ausprägungen getestet werden sollen. Da "Include" der
default ist, kann de Mo in diesem Falle auch weggelassen werden. Der Parameter {{java|names}} ist eine Liste von enum-Ausprägung-Namen die als Strings angegeben werden.
Man kann das vorgehen auch umdrehen un den Versandweg "POST" – als einzigen nicht-elektronischen Weg
ausschließen. Die Annotation sieht dann so aus:
{{java|code=@EnumSource(value = Versandweg.class, mode = Mode.EXCLUDE, names = { "POST" })}}
Der {{java|mode}}-Parameter hat nun den Wert {{java|EXCLUDE}} und darf natürlich nicht weggelassen werden. Der Parameter
{{java|names}} ist wieder eine Liste von enum-Ausprägung-Namen die hier aus einem einzigen Wert besteht.
In beiden Fällen ist der Entwickler für die korrekte Schreibweise der Namen der enum-Ausprägungen
verantwortlich. Stimmt sie nicht überein, giebt's einen Laufzeitfehler bei der Test-Ausführung.
Während bei "INCLUDE" nur so viel Tests erzeugt werden, wie enum-Ausprägungen spezifiziert wurden, werden bei
"EXCLUDE" Tests für alle Ausprägungen erzeugt die nicht angegeben sind. Wird das enum um Ausprägungen
erweitert, dann werden im EXCLUDE-Falle neue Tests generiert, im INCLUDE-Falle nicht.

===Pattern-Matching===
Mit den beiden Modes MATCH_ALL und MATCH_ANY können die Namen von enum-Ausprägungen mit Hilfe von
regulären Ausdrücken spezifiziert werden. Dieses Vorgehen ist jedoch problematisch und soll hier nicht weiter
erörtert werden. Macht man bei Definition der Ausdrücke Fehler, kann es beispielsweise passieren, daß
Ausprägungen ausgelassen werden und für diese dann keine Tests erzeugt werden. Das fällt nur auf wenn die TestAusführung manuell überprüft wird.
===Test-Fälle als Enumerationen===
bei der Verwendung von enum-Sources ist man nicht auf "produktive" enums beschränkt. Man kann auch Test-Situationen über enums definieren und diese
enums dann verwenden um parametrisierte Tests zu füttern. Man kann zum Beispiel für die Test-Klasse enum "Kunde" definieren, dessen Ausprägungen
jeweils einzelne Test-Konstellationen beschreiben. Damit lassen sich parametrisierte Tests definieren, die alle oder ausgewählte Konstellationen testen:
{{java|code=
@ParameterizedTest
@EnumSource(value = Kunde.class, names = { "MIT_KDNR", "MIT_IHNR", "MIT_KDNR_UND_IHNR" })
void darfElektronischeDokumentEinstellungSehen(Kunde kunde) {
assertThat(verwalter(kunde).darfElectronicDocumentsSehen()).isTrue();
}
}}
In diesem Beispiel wurde Kunden konfiguriert die ein Kunden- oder Inhabernummer oder beides haben. Jeder der
Kunden muß seine elektronischen Dokumente sehen dürfen.

Parametrisierte Tests

2024-03-19T19:17:11Z

Ullrich: /* Mehrere Parameter für die Test-Methode */

[[Category:Java]]
[[Category:junit]]
Ein einzelner Unit-Tests befaßt sich mit einem einzelnen Test-Fall und hat im Regelfall eine einzelne Assertion.
Dieses einfache Beispiel testet die korrekte Konvertierung von Datum-Strings in ein Date-Objekt. Die drei Assertions
prüfen hier zusammen, ob das Datum korrekt ist:
{{java|code=
@Test
public void toDateLiefertKorrektesDatum() {
Date convertedDate = Convert.toDate("01.5.1985");
assertThat(convertedDate).hasDayOfMonth(1);
assertThat(convertedDate).hasMonth(5);
assertThat(convertedDate).hasYear(1985);
}
}}
Nun soll er Konverter mit unterschiedlichen Datums-Angaben umgehen: Mit und ohne führende Nullen, mit und
ohne Jahrhundert, vielleicht soll auch ein Minuszeichen anstelle des Punkts erlaubt sein. Für jeden Testfall kann
man nun die Test-Methode kopieren und entsprechend anpassen. Die Folgen sind klar: jede Menge Test-Code,
sinkende Übersichtlichkeit und für jede neue Test-Methode braucht es einen neuen Namen. Das DRY-Prinzip soll
auch für Test-Code gelten.

Eine wesentliche Bereicherung von JUnit-5 ist die Unterstützung von Parameter-gesteuerten Test-Methoden die
weit über das hinausgeht was JUnit-4 oder Test-NG zu bieten hatten. Eine Vielzahl von Test-Situationen läßt sich
damit abdecken und vor allem eindampfen.
==Eine Liste einzelner Parameter==
Betrachten wir –- angelehnt an das einleitende Beispiel -– die einfachste Situation: Einen Testfall soll mit einer Reihe
einzelner Strings aufgerufen werden. Dazu parametrisieren wir zunächst die Test-Methode und ziehen den Datum-String als Parameter heraus:
{{java|code=
public void toDateLiefertKorrektesDatum(String datum) {
Date convertedDate = Convert.toDate(datum);
assertThat(convertedDate).hasDayOfMonth(1);
assertThat(convertedDate).hasMonth(5);
assertThat(convertedDate).hasYear(1985);
}
}}
Dann legen wir die Datum-Strings fest mit denen getestet werden soll:
{{java|"1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985"}}
Um die neue Test-Methode mit den Test-Fälle zu verknüpfen verwenden wir JUnit5-Annotations und setzen sie
über unsere parametrisierte Test-Methode:
{{java|code=
@ParameterizedTest
@ValueSource(strings = { "1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985" })
}}
Die erste Annotation ersetzt die @Test-Annotation und macht die Methode zum (parametrisierten) Test.
Die zweite Annotation legt die Quelle der zu verwendenden Werte fest.
In diesem Falle ist dies eine Liste von Strings. Der Test wird bei der
Ausführung für jeden String einmal aufgerufen, wobei der jeweilige String als Argument übergeben wird.
Anstelle von Strings sind hier auch alle numerischen, primitiven Typen int, long, float und einiges mehr erlaubt.
Die Anntotations-Parameter kann man in Eclipse mit Code-Assist erkunden oder in der JUnit5-Doku nachlesen.
===Und was ist mit null?===
Die eben vorgestellte Werte-Liste hat einen kleinen Haken: Es ist nicht möglich, den Wert null als Argument zu
verwenden. Um einen Testfall für null zu erzeugen, kann man nun freilich eine neue Test-Methode erstellen und
null separat in diesem Test prüfen. Man kann dem Test aber auch zusätzlich die Annotation @NullSource
hinzufügen. JUnit5 erzeugt dann einen zusätzlichen Testfall für null:
{{java|code=
@ParameterizedTest
@NullSource
@ValueSource(strings = { "1.5.1985", "01.5.1985", "1.05.1985", "01.05.1985" })
public void toDateLiefertKorrektesDatum(String datum) {
// hier kommt der Test-Code hin...
}
}}
Unterstützt wird {{java|@NullSource}} ab Version 5.4

== Mehrere Parameter für die Test-Methode ==
Dieser Abschnitt beschreibt die einfachste Variante, weitere Möglichkeiten werden [[Testdaten-Provider|hier]] beschrieben.

Für viele Unit-Tests reicht die Extraktion eines einzelnen Parameters nicht aus. Im folgenden Beispiel wird die
Qualität von Passworten getestet. Das Wort "Hallo" zum Beispiel wird abgewiesen, weil es nur Buchstaben enthält:
public void passwortWirdNichtAkzeptiert() {
assertThat(policy.validate("Hallo")).as("nur Buchstaben").isFalse();
}
Wofür die Parameter in der Test-Methode verwendet werden, spielen keine Rolle, es geht nur darum, den Test
mehrfach aufzurufen und dabei ''mehrere'' Parameter zu übergeben. Im vorliegenden Falle möchten wir
unterschiedliche Passwort-Kandidaten testen und dabei jeden Test mit einer Beschreibung versehen, der Auskunft
gibt warum das Wort nicht als Passwort akzeptiert wird. Die Test-Methode sieht nun so aus:
{{java|code=
public void passwortWirdNichtAkzeptiert(String passwort, String grund) {
assertThat(policy.validate(passwort)).as(grund).isFalse();
}
}}
Für die Erzeugung der Test-Daten schreiben wir diesmal eine weitere Methode.
Sie erzeugt einen Stream von Arguments-Objekten von denen jedes die Daten für ''einen'' Test-Aufruf enthält:
{{java|code=
static Stream<Arguments> pwdWirdNichtAkzeptiert() {
return Stream.of(
Arguments.of("Hallo", "nur Buchstaben"),
Arguments.of("1234567", "nur Ziffern"),
Arguments.of("!%#&/()", "nur Sonderzeichen")
);
}
}}
Die Methode für die Testdaten-Erzeugung muß folgende Eigenschaften haben:
*sie muß static deklariert sein
*sie muß zur Test-Klasse gehören
*sie darf keinen Parameter haben und muß einen Stream von Arguments-Objekten liefern
*sie darf in beliebiger Sichtbarkeit deklariert werden
Die Methode darf zwar private deklariert werden, Java wird sich aber darüber beschweren, daß die Methode
nirgends verwendet wird. Warum das so ist, erfahren wir weiter unten.
Am einfachsten deklariert man sie daher package visible.

Die Klasse
{{java|org.junit.jupiter.params.provider.Arguments}}
ist ein Container, der eine Reihe von Werten beliebigen Typs (mit Ausnahme von {{Lambda}}-Ausdrücken) in fester
Reihenfolge aufnimmt. JUnit5 mappt die Werte der {{java|Arguments}}-Objekte auf die Parameter der Test-Methode. Das
geschieht allerdings erst zur Laufzeit, der Entwickler ist daher selbst dafür verantwortlich die Typen zwischen
Testdaten-Provider und Test-Methode in Übereinstimmung zu halten.

Wir bringen nun Test-Methode und Testdaten-Provider-Methode zusammen. Das geschieht mithilfe folgender JUnit5-Annotationen:
{{java|code=
@ParameterizedTest
@MethodSource("pwdWirdNichtAkzeptiert")
}}
Die erste Annotation kennen wir schon aus dem vorangegangenen Abschnitt. Die zweite Annotation weist die Test-Methode an
die Testdaten aus der Methode "pwdWirdNichtAkzeptiert" zu beziehen. Der Name der Methode wird als String angegeben.
Das bedeutet, daß der Entwickler für die korrekte Schreibweise verantwortlich ist, Fehler treten auch hier erst zur Laufzeit auf.
Hat die Test-Daten-Methode den gleichen Namen wie die Test-Methode kann sie in
der Annotation auch weggelassen werden. Die Annotation selbst hingegen kann ''nicht'' weggelassen werden.
Da die Methode nur über den Namen referenziert wird, muß der Compiler tatsächlich annehmen,
daß die Method nicht verwendet wird wenn sie als private deklariert wurde.
=== Lambda-Ausdrücke ===

==Weitere Test-Daten-Provider==
JUnit5 unterstützt noch eine Reihe weiterer Möglichkeiten, Testdaten für parametrisierte Tests zur Verfügung zu
stellen:
*Java-enums
*CSV-Dateien
*Daten im CSV-Format
*separate Klassen
==Enums==
Eine besondere Unterstützung bei der Erstellung parametrisierter Tests erfahren die Java-enums. Grundsätzlich
erfolgt die Parametrisierung wie dies hier am Beispiel von String-Argumenten beschrieben wurde. Auf die
spezifischen Eigenschaften von enums und ihrem besonderen Wert für Unit-Tests wird hier eingegangen.
Betrachten wir ein enum das Versandwege beschreibt:
{{java|code=
enum Versandweg {
E_MAIL,
SMS,
POST
}
}}
und die zu testende Methode die eine TAN über einen Versandweg verschickt:
{{java|code=
public class Versender {
Response sendTan(Versandweg weg) {
...
}
}
}}
===Alle Ausprägungen testen===
Wir können nun für jeden Versandweg eine Test-Methode schreiben. Das geht auch einfacher, wenn wir immer das
gleiche Ergebnis erwarten:
{{java|code=
@ParameterizedTest
@EnumSource(value=Versandweg.class)
void verwandWegLiefertOk(Versandweg weg) {
Assertions.assertThat(new Versender().sendTan(weg)).isEqualTo(Response.OK);
}
}}
Die erste Annotation weist die Methode als parametrisierten Test aus. Die zweite Annotation gibt an, welches enum
für den Test zu verwenden ist. Die Test-Methode selbst muß ein Argument vom Typ des Enums akzeptieren.
Die parametrisierte Version ist nicht nur kompakter. Wird das enum um weitere Ausprägungen ergänzt, werden
automatisch Test dafür generiert. Ob das Ergebnis tatsächlich der gewünschten Anforderung entspricht kann JUnit
natürlich nicht vorhersehen, aber die neue enum-Ausprägung wird zumindest betrachtet und läuft günstigenfalls
auf einen Fehler.
=== Einzelne Ausprägungen testen ===
Möchte man nicht alle Ausprägungen testen sondern nur ganz bestimmte, kann man das der Annotation mitgeben.
dafür gibt es zwei Modes: ''einschließend'' und ''ausschließend''.
Möchten wir etwa nur die Versandwege eMail und SMS testen, können wir die Annotation so schreiben (der ganze Rest bleibt gleich):
{{java|code=@EnumSource(value = Versandweg.class, mode = Mode.INCLUDE, names = { "E_MAIL", "SMS" })}}
Der Parameter {{java|mod}} gibt an, daß nur die angegebenen Ausprägungen getestet werden sollen. Da "Include" der
default ist, kann de Mo in diesem Falle auch weggelassen werden. Der Parameter {{java|names}} ist eine Liste von enum-Ausprägung-Namen die als Strings angegeben werden.
Man kann das vorgehen auch umdrehen un den Versandweg "POST" – als einzigen nicht-elektronischen Weg
ausschließen. Die Annotation sieht dann so aus:
{{java|code=@EnumSource(value = Versandweg.class, mode = Mode.EXCLUDE, names = { "POST" })}}
Der {{java|mode}}-Parameter hat nun den Wert {{java|EXCLUDE}} und darf natürlich nicht weggelassen werden. Der Parameter
{{java|names}} ist wieder eine Liste von enum-Ausprägung-Namen die hier aus einem einzigen Wert besteht.
In beiden Fällen ist der Entwickler für die korrekte Schreibweise der Namen der enum-Ausprägungen
verantwortlich. Stimmt sie nicht überein, giebt's einen Laufzeitfehler bei der Test-Ausführung.
Während bei "INCLUDE" nur so viel Tests erzeugt werden, wie enum-Ausprägungen spezifiziert wurden, werden bei
"EXCLUDE" Tests für alle Ausprägungen erzeugt die nicht angegeben sind. Wird das enum um Ausprägungen
erweitert, dann werden im EXCLUDE-Falle neue Tests generiert, im INCLUDE-Falle nicht.

===Pattern-Matching===
Mit den beiden Modes MATCH_ALL und MATCH_ANY können die Namen von enum-Ausprägungen mit Hilfe von
regulären Ausdrücken spezifiziert werden. Dieses Vorgehen ist jedoch problematisch und soll hier nicht weiter
erörtert werden. Macht man bei Definition der Ausdrücke Fehler, kann es beispielsweise passieren, daß
Ausprägungen ausgelassen werden und für diese dann keine Tests erzeugt werden. Das fällt nur auf wenn die TestAusführung manuell überprüft wird.
===Test-Fälle als Enumerationen===
bei der Verwendung von enum-Sources ist man nicht auf "produktive" enums beschränkt. Man kann auch Test-Situationen über enums definieren und diese
enums dann verwenden um parametrisierte Tests zu füttern. Man kann zum Beispiel für die Test-Klasse enum "Kunde" definieren, dessen Ausprägungen
jeweils einzelne Test-Konstellationen beschreiben. Damit lassen sich parametrisierte Tests definieren, die alle oder ausgewählte Konstellationen testen:
{{java|code=
@ParameterizedTest
@EnumSource(value = Kunde.class, names = { "MIT_KDNR", "MIT_IHNR", "MIT_KDNR_UND_IHNR" })
void darfElektronischeDokumentEinstellungSehen(Kunde kunde) {
assertThat(verwalter(kunde).darfElectronicDocumentsSehen()).isTrue();
}
}}
In diesem Beispiel wurde Kunden konfiguriert die ein Kunden- oder Inhabernummer oder beides haben. Jeder der
Kunden muß seine elektronischen Dokumente sehen dürfen.

Testdaten-Provider

2024-03-19T19:15:17Z

Ullrich: Die Seite wurde neu angelegt: „Category:Java Category:junit Um einen parametrisierte Test-Methode mit Daten zu versorgen bieten sich Methoden als Testdaten-Provider an. Eine solcher Provider-Methode liefert einen {{java|Stream}} von Testdaten-Sätzen. Ein Testdaten-Satz besteht in der Regel auf mehreren Einzeldaten, er kann aber natürlich auch aus einem einzelnen Datum bestehen. Jeder Satz ist in ein {{java|Arguments}}-Objekt verpackt und besteht daher immer aus Objekten; Date…“

[[Category:Java]]
[[Category:junit]]
Um einen parametrisierte Test-Methode mit Daten zu versorgen bieten sich Methoden als Testdaten-Provider an.
Eine solcher Provider-Methode liefert einen {{java|Stream}} von Testdaten-Sätzen. Ein Testdaten-Satz besteht in der Regel
auf mehreren Einzeldaten, er kann aber natürlich auch aus einem einzelnen Datum bestehen. Jeder Satz ist in
ein {{java|Arguments}}-Objekt verpackt und besteht daher immer aus Objekten; Daten atomarer Typen werden dabei in
Objekte der korrespondierenden Klassen verpackt.

Betrachten wir eine einfache Test-Methode die für die Ausführung zwei Strings benötigt.
Wie jede Test-Methode die eine nichtleere Parameterliste hat, muß sie mit der Annotation {{java|@ParameterizedTest}}
versehen sein:
{{java|code=
@ParameterizedTest
void passwortWirdNichtAkzeptiert(String passwort, String grund) {
assertThat(policy.validate(passwort)).as(grund).isFalse();
}
}}
== Variante 1: die statische Methode ==
Der einfachste Weg einen Testdaten-Provider zu definieren führt über eine statische Methode
die sich in der selben Klasse befindet wie die Test-Methode:
{{java|code=
static Stream<Arguments> pwdWirdNichtAkzeptiert() {
return Stream.of(
Arguments.of("Hallo", "nur Buchstaben"),
Arguments.of("1234567", "nur Ziffern"),
Arguments.of("!%#&/()", "nur Sonderzeichen")
);
}
}}
Stimmt der Name des Testdaten-Providers mit dem Namen der Test-Methode überein, kann man den Parameter
in der Annotation auch weglassen. Für diese Variante gelten folgende Einschränkungen:
* Die Methode muß in der gleichen Klasse liegen wie die Test-Methode
* Die Methode muß als {{java|static}} deklariert sein
* Die Methode darf ''nicht'' {{java|private}} deklariert sein

== Variante 2: die qualifizierte statische Methode ==
Nachteil der ersten Variante ist, daß sich der Testdaten-Provider in der gleichen Klasse befinden muß
wie die Test-Methode. Das gilt auch, wenn sich die Methode in einer Member Class oder einer Inner Class befindet.
Damit lassen sich keine Testdaten-Provider definieren, die von mehreren geschachtelte Test-Klassen
-- per Annotation {{java|@Nested}} -- gemeinsam genutzt werden.

Befindet sich der Testdaten-Provider in einer anderen Klasse als die Test-Methode, kann man zusätzlich zur Methode
die Klasse angeben in der sich die Methode befindet. Die Package-Angabe muß '''voll qualifiziert''' sein, die Methode
wird mit {{java|#}} getrennt angefügt:
{{java|code=
MethodSource("org.mletkin.unittest.TestDaten#pwdWirdNichtAkzeptiert")
}}
Wie in Variante 1 erfolgt die Angabe in Form eines Strings. Das ist fehleranfällg, weil die Klasse und die Methode
erst zur Laufzeit -- also bei der Test-Ausführung -- auf Existenz geprüft werden.

Man kann das mitigieren, indem man den String in eine Konstante auslagert:
{{java|code=
private static final String TEST_DATA = "org.mletkin.unittest.TestDaten#pwdWirdNichtAkzeptiert";
...
@MethodSource(TEST_DATA)
}}
Das eröffnet zum einen die Möglichkeit Test-Methoden zentral bereitzustellen und zum anderen die Möglichkeit
die Strings auf Gültigkeit zu überprüfen. Das geschieht dann zwar auch erst zur Laufzeit, der Fehler tritt
dann aber wenigstens da auf wo er geschehen ist.

== Variante 3: die Testdaten-Provider-Klasse ==
Eine weitere Möglichkeit den Testdaten-Provider zu implementieren ist die Definition in einer eigenen Klasse.
Eine solche Klasse kann allerdings nur eine einzige Testdaten-Methode anbieten, da der Zugriff über ein Interface erfolgt:
{{java|code=
public class UngueltigePassworte implements ArgumentsProvider {
@Override
public Stream<Arguments> provideArguments(ExtensionContext context) {
return Stream.of(
Arguments.of("Hallo", "nur Buchstaben"),
Arguments.of("1234567", "nur Ziffern"),
Arguments.of("!%#&/()", "nur Sonderzeichen")
);
}
}
}}
Die Testdaten-Provider-Klasse muß das Interface {{java|ArgumentsProvider}} implementieren und dazu die oben gezeigte Methode
implementierten. Sie erhält als Argument ein Kontext-Objekt das Informationen zur Umgebung der Test-Ausführung enthält.
In unserem Beispiel machen wir keinen Gebrauch davon.

Die Verwendung erfolgt über die Annotation {{java|@ArgumentsSource}}, der jetzt die Testdaten-Provider-Klasse in Form eines
{{java|Class}}-Objekts übergeben wird:
{{java|code=
@ArgumentSource(UngueltigePassworte .class)
}}
Im Gegensatz zur {{java|@MethodSource}}-Verwendung in den vorangegangenen Varianten wird hier schon zur Compile-Zeit sichergestellt
daß die Testdaten-Provider-Klasse und die -Methode existieren.

Schüttelreim

2024-01-19T10:48:21Z

Ullrich:

[[Category:Eigenes]]

Ich saß vor meinem Monitor
Und hatte einen Ton im Ohr
undatiert

Ich werde einen Kuchen backen
Und ihn dann zwischen Buchen kacken
19.7.2020

Ich traf dieselben Gecken
Immer bei den gelben Säcken
Januar 2022

Er sitzt auf dem Geschirrspüler
Und lehrt mit viel Gespür Schüler
Januar 2022

Weihnachten wird der Baumkuchen
So knapp, man kann ihn kaum buchen
Januar 2022

Sie aßen ihre Salzstangen
Fortan nur noch mit Stahlzangen
Januar 2023

Er repariert den ganzen Tag Lichtschalter
Und nach der Schicht lallt er
Mai 2023

Das Schiff hat am Rand Latten
Zum Schutz der doofen Landratten
9.7.2023

Die Masten meist im Wege steh'n
Wenn Fahnen an dem Stege weh'n
22.7.2023

Er wollte die Fahne in heroischer Pose hissen
Und mußte dabei sich in die Hose pissen
1.9.2023

Ich griff nach meiner Beißschiene
Da sticht mich so 'ne Scheißbiene
18.1.2024

Schüttelreim

2024-01-19T10:39:37Z

Ullrich:

[[Category:Eigenes]]

Er saß vor seinem Monitor
Und hatte einen Ton im Ohr
undatiert

Ich werde einen Kuchen backen
Und ihn dann zwischen Buchen kacken
19.7.2020

Ich traf dieselben Gecken
Immer bei den gelben Säcken
Januar 2022

Er sitzt auf dem Geschirrspüler
Und lehrt mit viel Gespür Schüler
Januar 2022

Weihnachten wird der Baumkuchen
So knapp, man kann ihn kaum buchen
Januar 2022

Sie aßen ihre Salzstangen
Fortan nur noch mit Stahlzangen
Januar 2023

Er repariert den ganzen Tag Lichtschalter
Und nach der Schicht lallt er
Mai 2023

Das Schiff hat am Rand Latten
Zum Schutz der doofen Landratten
9.7.2023

Die Masten meist im Wege steh'n
Wenn Fahnen an dem Stege weh'n
22.7.2023

Er wollte die Fahne in heroischer Pose hissen
Und mußte dabei sich in die Hose pissen
1.9.2023

ich griff nach meiner Beißschiene
Da sticht mich so 'ne Scheißbiene
18.1.2024

Schüttelreim

2024-01-19T10:37:45Z

Ullrich:

[[Category:Eigenes]]

Er saß vor seinem Monitor
Und hatte einen Ton im Ohr
undatiert

Ich werde einen Kuchen backen
Und ihn dann zwischen Buchen kacken
19.7.2020

Ich traf dieselben Gecken
Immer bei den gelben Säcken
Januar 2022

Er sitzt auf dem Geschirrspüler
Und lehrt mit viel Gespür Schüler
Januar 2022

Weihnachten wird der Baumkuchen
So knapp, man kann ihn kaum buchen
Januar 2022

Sie aßen ihre Salzstangen
Fortan nur noch mit Stahlzangen
Januar 2023

Er repariert den ganzen Tag Lichtschalter
Und nach der Schicht lallt er
Mai 2023

Das Schiff hat am Rand Latten
Zum Schutz der doofen Landratten
9.7.2023

Die Masten meist im Wege steh'n
Wenn Fahnen an dem Stege weh'n
22.7.2023

Er wollte die Fahne in heroischer Pose hissen
Und mußt dabei in die Hose pissen
1.9.2023

Er greift nach seiner Beißschiene
Da sticht ihn so 'ne Scheißbiene
18.1.2024

Mockito: Verify

2024-01-11T08:13:59Z

Ullrich: Ullrich verschob die Seite Mockito Verify nach Mockito: Verify, ohne dabei eine Weiterleitung anzulegen

[[Kategorie:Java]]
[[Kategorie:Mockito]]
== Voraussetzungen ==
Die Voraussetzungen für die Anwendung von {{java|verify}} sind simpel.
Man benötigt dazu einen Mock oder einen Spy der ein "echtes" Objekt umwickelt.
Mocks und Spies werden [[Partieller Mock|hier]] beschrieben.

== Die grundsätzliche Anwendung ==
Wir stellen uns hier einen Handler vor, dessen {{java|onMessage}}-Methode die {{java|send}}-Methode
des {{java|WebSocketConnection}}-Objekts aufrufen soll.
{{java|code=
@Test
public void auftragNullSendetFehlermeldung() {
WebSocketConnection connection = Mockito.mock(WebSocketConnection.class);
handler.onMessage(connection, (String) null);
Mockito.verify(connection, Mockito.atLeastOnce())
.send("Die Anfrage kann nicht verarbeitet werden.");
}}
Die ersten beiden Zeilen führen den Test durch, die dritte Zeile prüft, daß die {{java|send}}-Methode
mit dem angegebenen Text mindestens einmal aufgerufen wird.

Der erste Parameter von {{java|verify}} ist das zu untersuchende Objekt. Der zweite Parameter giebt die das erwartete
Ergebnis an. Auf das Ergebnis wird die Methode aufgerufen, deren Aufruf überprüft werden soll.

Das gleiche {{java|verify}} würde auch funktioneren, wenn statt des Mocks eine echte Connection erzeugt um mit spy
ummantelt würde:
{{java|code=WebSocketConnection connection = Mockito.spy(new MyWebSocketConnectionImplementation());}}

== Prüfungen ==
:'''atLeastOnce'''
:: Die Methode wurde mindestens einmal aufgerufen

:'''times(n)'''
:: Die Methode wurde ''n'' mal aufgerufen

:'''times(0)''' oder '''never()'''
:: Die Methode wurde nicht aufgerufen

Mockito: Einführung

2024-01-11T08:13:26Z

Ullrich: Ullrich verschob die Seite Mockito Einführung nach Mockito: Einführung, ohne dabei eine Weiterleitung anzulegen

[[Category:Java]]
[[Category:Mockito]]
= Einführung =
Ein Mock – im Sinne dieser Einführung – ist ein Objekt, das so aussieht aber sich nicht so verhält wie das "echte" Objekt das es ersetzt.
Man kann sich das vorstellen wie eine Theater-Requisite: Benötigt man auf der Bühne ein Buch, verwendet man einen Pappkarton,
der von außen aussieht wie ein Buch aber keines ist. So versteht diese Einführung unter einem "Mock" -- salopp ausgedrückt:
{{Quotation|
ein Objekt, das ein anderes ersetzt und dabei das originale Objekt in bestimmten Aspekten nachahmen kann,

aber niemals dessen vollständige Funtionalität hat.
Es kann Funktionalität und Seiteneffekte hinzufügen falls erforderlich.}}

Tatsächlich ist die Verwendung der Begriffe Dummy, Fake, Stub und Mock durchaus uneinheitlich.
Für diese Einführung verzichten wir auf eine akademische Unterscheidung, gehen pragmatisch vor,
sprechen durchgehend vom "Mock" und meinen das oben genannte.
Dem Sprachenthusiasten, der an einer genaueren Definition interessiert ist,
sei zum Einstieg der Blog-Artikel von
[https://martinfowler.com/articles/mocksArentStubs.html Martin Fowler] empfohlen.

== Aufgaben ==
Ein Mock kann bei der Implementierung von Unit-Tests für verschiedene Aufgaben genutzt werden.
Man kann diese Aufgaben in der Regel auch anders lösen, aber wir möchten hier natürlich erörtern
wie ''Mockito'' uns bei der Erfüllung unterstützen kann.

Typische Aufgaben für Mocks sind
*Das Emulieren von Klassen, deren wahre Funktionalität nicht ausgeführt werden kann, darf oder soll
*Das Erzeugen von Instanzen von Interfaces und Klassen, von denen keine konkrete Implementierung erzeugt werden kann
*Der Überprüfung, ob –- und mit welchen Argumenten -– Methoden einer Klasse aufgerufen wurden.

'''So tun als täte es:''' Jeder Unit-Test muß isoliert und ohne externe Abhängigkeiten ausgeführt werden können. Es
reicht nicht, wenn der Test lokal im Eclipse läuft, er muß auch jederzeit vom Jenkins-Build ausgeführt werden
können. Greift beispielsweise eine Methode auf einen Web-Service oder eine lokale Datenbank zu, kann der Test
nicht ausgeführt werden. Man kann dann Mock-Implementierungen der Service-Klasse bzw. der Persistenz-Schicht
erzeugen und mit diesen als Ersatz den Unit-Test durchführen.

'''So tun als gäbe es:''' Der Typ eines Parameters der zu testenden Methode sei ein Interface. Dann benötigt man
für den Aufruf der Methode im Rahmen des Unit-Tests eine Objekt-Instanz einer Klasse die das Interface implementiert.
Statt das Interface selbst zu implementieren, überläßt man Mockito die Fußarbeit und nutzt einen Mock.

'''Prüfen, ob:''' In vielen Unit-Tests möchte man sicherstellen, daß beim Durchlauf eine bestimmte Methode
aufgerufen wird (oder garantiert nicht aufgerufen wird) oder daß eine Methode mit bestimmten Argumenten aufgerufen wird.
Das läßt sich bei allen Mockito-Mocks serienmäßig überprüfen, Mockito erlaubt es aber auch, "echte" Objekte
mit einem Spy-Objekt zu umwickeln über das die entsprechende Information abgerufen werden kann.

== Abgrenzung ==
Anstelle von Mockito-Mocks kann man auch einfach
Interfaces implementieren und Klassen ableiten um zu Mock-Implementierungen zu kommen. Java-Interfaces
wurden ja auch zu dem Zweck geschaffen, unterschiedlicher Implementierungen mit der gleichen Schnittstelle zu
schaffen – warum also Mockito nutzen? Die Erzeugung eines Mockito-Mocks nimmt eine Zeile Code in Anspruch;
gleichgültig wieviele Methoden implementiert oder überschrieben werden. Eine konkrete Klasse braucht eine
explizite Implementierung und das wird schnell unübersichtlich. Zudem aktualisiert sich der Mock automatisch,
weil er erst zur Laufzeit entsteht. Eine händische Implementierung eines Interface muß jedesmal angefaßt werden,
wenn sich das Interface ändert – ein Mockito-Mock nicht.

Zum Schluß der Einleitung sei darauf hingewiesen, was Mockito nicht mocken kann:
*statische Methoden
*private Methoden
*finale Klassen und Methoden

Auf dieser Seite geht es um die Erstellung von Mocks. Spies und alternative Vorgehen werden [[Partieller Mock|hier]]
behandelt, um das Überprüfen des Aufrufverhaltens [[Mockito Verify|hier]].

= Mocking =
Mocking hat zwei Schritte. Zunächst wird ein Mock-Objekt von der gewünschten Klasse erzeugt,
dann werden Methoden des Objekts in der Weise implementiert wie es für den Test erforderlich ist.

Der zweite Schritt ist optional, ein vollständig funktionsloser Mock ist in vielen Fällen schon
ausreichend. In aller Regel wird man dem Mock jedoch Funktionalität hinzufügen wollen.
Diese Einführung folgt diesem Vorgehen und beschreibt die nötigen Werkzeuge. Alternative
Ansätze werden hier [[Partieller_Mock|besprochen]].

== Das Mock-Objekt ==

Der einfachste Mock für ein Objekte einer Klasse oder eines Interfaces erlaubt den Aufruf jeder nicht-statischen,
non-private, non-final Methode ohne daß dabei eine Exception auftritt.
Er wird so erzeugt:
{{java|code=Foo mock = Mockito.mock(Foo.class);}}
Die Methoden des Mocks tun nichts, sie rufen auch keine super-Methoden auf. Es wird nur sichergestellt daß jede Methode
gefahrlos aufgerufen werden kann und ggf. einen gültigen, wenn auch bedeutungslosen Wert liefert. Anstelle von Objekten
(dazu gehören auch Strings) erhält man stets {{java|null}}, numerische Ergebnisse sind immer ''0''
und boolean-Methoden liefern immer {{java|false}}.

Wird eine Klasse gemockt, erzeugt Mockito eine Ableitung der zu mockenden Klasse. In der Folge können weder finale
Klassen noch finale Methoden gemockt werden. Gleiches gilt für statische Methoden, die nicht vererbt werden.

Der Mock kann auf Felder der gemockten Klasse zugreifen, solange diese nicht private sind. Allerdings kann
er keine eigenen Felder definieren. Auf public und package visible Felder kann auch von außen zugegriffen werden.

== Mocken von Methoden ==

Wie erwähnt, liefern Methoden gemockter Klassen nur default-Werte; das ist selten ausreichend.
Betrachten wir zunächst die einfachste Variante:
bei jedem Aufruf der Methode solleb die gleichen, feste Werte geliefert werden.
Wir mocken dafür das folgende Interface:
{{java|code=
public interface Person {
String id();
String abteilung();
int foo(String dings);
}
}}
=== Parameterlose Methoden ===
Soll etwa die ID der Person immer den Wert 5 liefern, könnte das so aussehen:
{{java|code=
person = Mockito.mock(Person.class);
Mockito.when(person.id()).thenReturn(5);
}}
Das Argument der {{java|when}}-Methode ist ein Methoden-Aufruf auf den Mock,
das Argument der {{java|thenReturn}}-Methode ist der zu liefernde Wert.
Soll die Methode eine Abfolge fester Werte liefern, kann man eine Liste angeben:
{{java|code=Mockito.when(person.abteilung()).thenReturn("BLA", "FOO");}}
Beim ersten Aufruf liefert die Methode den String {{java|BLA}} und beim zweiten {{java|FOO}}.
Man kann die Werte auch einzeln angeben:
{{java|code=
Mockito.when(person.abteilung())
.thenReturn("BLA")
.thenReturn("FOO");
}}
Verwendet man die zweite Variante, kann man die gemockte Methode auch dazu bringen, zwischendurch Exceptions zu werfen:
{{java|code=
Mockito.when(person.abteilung())
.thenReturn("BLA")
.thenThrow(new RuntimeException());
.thenReturn("FOO");
}}
Sind alle Werte durch Aufruf verbraucht, liefert die Methode wieder den default-Wert.

=== Methoden mit Parametern ===
Die meisten Methoden haben einen oder mehrere Parameter. Will man solche Methoden mocken, muß man
spezifizieren bei welchen Argumenten welche Ergebnisse geliefert werden sollen. Im einfachsten Falle gibt man den
Argument-Wert als Literal vor:
{{java|code=
Foo p = Mockito.mock(Person.class);
Mockito.when(p.foo("x")).thenReturn(10);
Assertions.assertThat(p.foo("x")).isEqualTo(10);
}}
Die Methode {{java|foo}} liefert für {{java|foo("X")}} nun den Wert ''10'' und für alle anderen Argumente einen undefinierten Wert.
Wie erwähnt wird die Methode für alle anderen Argumente den Wert ''0'' liefern, aber man sollte sich nicht darauf verlassen,
daß das auch immer und unter allen Umständen so sein wird.

In den meisten Fällen wird man nicht auf einzelne Werte reagieren wollen, sondern auf Gruppen von Werten oder
auf alle möglichen Werte. Um das zu bewerkstelligen werden Matcher benötigt, die beim Aufruf versuchen die Argumente zu matchen.
Die Mockito-Matcher werden über statische Methoden der Klasse {{java|ArgumentMatchers}} bereitgestellt.

Da unsere Einstiegsklasse {{java|Mockito}} davon ableitet, "erbt" sie alle dort beheimateten statischen Methodem. Der Kürze halber
wird man sie also –- wie hier dargestellt –- über die Mockito-Klasse referenzieren. Das ist nach der reinen Java-Lehre eigentlich
nicht sauber, da statische Methoden nicht vererbbar sind. Aber da hier keine Probleme zu erwaretn sind, darf der Test-Code sich das erlauben.

Im Folgenden werden einige häufig benutzte Matcher vorgestellt.

==== Immer das Gleiche ====
Um für ''jedes'' beliebige Argument den gleichen Wert zuliefern, verwendet man einen der vielen {{java|any}}-Matcher.
{{java|Mockito.anyString()}} etwa akzeptiert jeden String mit Ausnahme von {{java|null}} -- dazu später:
{{java|code=Mockito.when(p.foo(Mockito.anyString())).thenReturn(12);}}
Die Methode {{java|foo}} liefert nun für jedes beliebige String-Argument – ganz verläßlich – den Wert ''12''.
Analog zu String bietet Mockito für eine Vielzahl von Typen – darunter auch für alle simplen Typen
wie {{java|int}} oder {{java|boolean}} – Matcher an, die jeweils mit "any" beginnen.
Kann der Compiler den Typ selbst erkennen, geht auch das generische {{java|any()}}:
{{java|code=Mockito.when(p.foo(Mockito.any())).thenReturn(10);}}
Handelt es sich um eine Klasse, kann man den Typ auch explizit angeben:
{{java|code=Mockito.when(p.foo(Mockito.any(String.class))).thenReturn(10);}}
Soll neben echten Objekten auch {{java|null}} als Argument akzeptiert werden, verwendet man {{java|nullable}};
das geht nur unter Angabe einer Klasse:
{{java|code=Mockito.when(p.foo(Mockito.nullabe(String.class))).thenReturn(10);}}
Möchte man ''nur'' auf {{java|null}} reagieren geht das auch, diesmal ohne Klasse:
{{java|code=Mockito.when(p.foo(Mockito.isNull())).thenReturn(10);}}

==== Manchmal das Gleiche ====
Das Konstrukt {{java|Mockito.anyString()}} liefert einen Matcher. Das ist ein Objekt, das beim Aufruf den Eingabe-Wert
analysiert und Übereinstimmungen signalisiert. Erkennt der Matcher im {{java|when()}}-Teil das definierte Muster,
wird der Wert des {{java|thenReturn()}} als Ergebnis geliefert.

Neben den any-Matchern giebt es eine Fülle anderer Matcher die auf verschiedene Auswahlen von Argumenten passen.
Zum Gebrauch sei auf die API-Doku von {{java|ArgumentMatchers}} verwiesen.

Die meisten Fälle lassen sich aber mit dem Universal-Matcher {{java|argThat}} behandeln. Er verlangt als Argument
eine Implementierung des (funktionalen) Interfaces {{java|ArgumentMatcher <T>}} ('''ohne -s!''').
Das Interface ist äquivalent zum JDK-Interface {{java|Predicate}}, es hat einen Objekt-Parameter und liefert
{{java|true}} für "Match" oder {{java|false}} oder "kein Match".
Dadurch läßt sich jeder passende {{lambda}}-Ausdruck als Matcher verwenden.
In voller {{lambda}}-Geschwätzigkeit sieht das zum Beispiel so aus:
{{java|code=Mockito.when(p.foo(ArgumentMatchers.argThat((String s) -> s.length() > 5))).thenReturn(10);}}
Wenn das das alles nicht reicht, findet man in der hamcrest-Bibliothek eine unglaubliche Fülle weiterer Matcher.

==== Mal dies -- mal das ====
Man kann beliebig viele {{java|.when}}-Konstrukte verwenden um den Mock für unterschiedlichen Argumente
unterschiedliche Ergebnisse liefern zu lassen. Mockito wendet die Matcher bei der späteren Ausführung in der
'''umgekehrten''' Reihenfolge ihrer Definition an. In der folgenden Kombination
{{java|code=
Foo p = Mockito.mock(Foo.class);
Mockito.when(p.foo(Mockito.anyString())).thenReturn(12);
Mockito.when(p.foo("x")).thenReturn(10);
}}
liefert {{java|foo("x")}} daher den Wert ''10'' und für jedes andere Argument liefert {{java|foo}} den Wert ''12''.
Selbstverständlich lassen sich in jedem Ausdruck beliebige Matcher verwenden.
Man muß bei der Definition aber darauf achten, daß die allgemeineren Matcher zuerst kommen.
Fügt man dem letzten Beispiel etwa noch ein {{java|.when}} mit einem {{java|anyString()}} an:
{{java|code=Mockito.when(Mockito.anyString()).thenReturn(4711);}}
dann werden alle vorher definierten Regeln ignoriert weil die letzte und allgemeinste Regel zuerst zieht.

=== Methoden responsive mocken ===
Die oben vorgestellten Verfahren liefern bei jedem Methoden-Aufruf feste Werte die bei der Mock-Definition festgelegt werden.
Oft ist es aber erforderlich, daß bei Aufruf der gemockten Methode Werte zurückgeliefert die aus den Argumenten errechnet werden.
Oder es ist erforderlich, daß die gemockte Methode irgendwelche Aktivitäten ausführt.

Mit den genannten Verfahren ist das nicht möglich, man benötigt eine "Answer". Dazu stehen zwei Varianten
zur Verfügung die sich in der Reihenfolge der Definition unterscheiden. Welche Variante man bevorzugt ist in vielen
Fällen unerheblich, when ... thenAnswer ist vielleicht etwas "intuitiver". Keine Wahl hat man, wenn man eine
void-Methode mocken möchte. Auch beim Mocken einzelner Methoden eines [[Partieller_Mock|Spys]] muß man die zweite Variante verwenden.
Als Beispiel sei für das Interface
{{java|code=
public interface Transform {
String calc(int value);
}
}}
ein Mock definiert durch:
{{java|code=Transform trans = Mockito.mock(Transform.class);}}

Um das Verhalten der Methode {{java|calc}} zu definieren bauen wir ein Objekt vom Typ {{java|Answer<T>}}.
Der Typ {{java|T}} wird ersetzt durch den Ergebnis-Typ der zu mockenden Methode -- in diesem Falle {{java|String}}.

Das {{java|Answer<T>}}-Objekt muß eine Methode überschreiben die ein Objekt der Klasse {{java|InvocationOnMock}}
als Argument nimmt. Über dieses Objekt erhalten wir Informtionen zu den Argumenten beim Aufruf der Mock-Methode.
Wir können sie mit der Methode {{java|getArgument}} über ihren Index abrufen, der Index beginnt bei 0.
Für die weiteren Methoden der Klasse sei auf die API-Dokumentation verwiesen.

Betrachten wir dazu eine konkrete Implementierung.

==== when ... thenAnswer ====
Die erste Variante nennt ''erst'' den Mock und ''dann'' die zu mockende Methode:
{{java|code=
Mockito.when(trans.calc(Mockito.anyString())).thenAnswer(new Answer<String>() {
@Override
public String answer(InvocationOnMock invocation) throws Throwable {
Integer value = invocation.getArgument(0);
return value.toString();
}
});
}}
Mit Java-8 läßt sich die anonyme Klasse auch eleganter mit einem {{lambda}}-Ausdruck schreiben:
{{java|code=
Mockito.when(trans.calc(Mockito.anyString())).thenAnswer(
(Answer<String>) invocation -> {
Integer value = invocation.getArgument(0);
return value.toUpperCase();
}
);
}}
Der Ergebnis-Typ von {{java|getArgument}} wird hier durch die Variable bestimmt der das Ergebnis zugewiesen wird.
Ob die Argument-Typen tatsächlich übereinstimmen, kann Java zur Compile-Zeit leider nicht kontrollieren.
Der Entwickler muß also selber darauf achten, daß alle Typen korrekt angegeben werden.

Im Gegensatz zur anonymen-Klasse-Variante kann im {{lambda}}-Ausdruck der Ergebnis-Typ {{java|Answer<String>}}
weggelassen werden. Man sollte ihn aber trotzdem hinschreiben, damit der Typ dokumentiert ist – man tut sich damit
bei der Fehlersuche erheblich leichter.

In den obigen Beispielen werden die Argumente vor Gebrauch in lokale Variablen abgefüllt, bevor diese im return-Ausdruck
verwendet werden. Das ist in der Regel nicht erforderlich, man kann die Typen von der Java-Magie bestimmern lassen.
Die geschwätzige Variante mit den lokalen Variablen hat aber den Vorteil, daß die Typen auf den ersten Blick zu erkennen
sind. Werden schrecklich Methoden mit vielen Parametern aufgerufen, wird das schnell zum Geduldspiel.

==== doAnswer ... when ====
Bei dieser Variante wird ''erst'' die Answer definiert und ''hinterher'' der Mock und die aufzurufende Methode.
Auch hier gewinnt der Aufruf durch die Verwendung von {{lambda}}-Ausdrücken durchaus an Lesbarkeit --
wir lassen die konventionelle Variante diesmal weg:
{{java|code=
Mockito.doAnswer(
(Answer<String>) invocation -> {
Integer value = invocation.getArgument(0);
return value.toString();
}
).when(trans.calc(Mockito.anyString()));
}}
Das Konstrukt funktioniert genauso wie das im vorangegangenen Abschnitt beschrieben.

Allerdings kann man den Aufruf auch subtil anders gestalten (hier wird nur die {{lambda}}-Variante wiedergegeben):
{{java|code=
Mockito.doAnswer(
(Answer<String>) invocation -> {
Integer value = invocation.getArgument(0);
return value.toString();
}
).when(trans).calc(Mockito.anyString());
}}
Der Unterschied liegt in der letzten Zeile. Im ersten Falle wird {{java|.when()}} mit dem Mock der gemockten ''Methode'' aufgerufen.
Im zweiten Falle wird {{java|.when()}} mit dem Mock der gemockten ''Klasse'' aufgerufen. Die zweite Variante macht das
Mocking von void-Methoden möglich und erlaubt, einzelne Methoden von Spy-Objekten zu mocken und damit [[Partieller Mock|partielle Mocks]] zu erzeugen.

=== void-Methoden: Methoden ohne Ergebnis ===
Eine void-Methode ist eine Methode, die kein Ergebnis liefert – was sollte man hier mocken?
Betrachten wir dazu folgendes Beispiel:
{{java|code=
public class CustomerManager {
public void save(Customer customer) {
getDatabaseLink().merge(customer);
}
}
}}
Die {{java|save}}-Methode nimmt als Parameter ein Entity und persistiert dessen Inhalt in der Datenbank.
Das ist etwas, was wir im Unit-Test normalerweise nicht tun möchten. Wir würden stattdessen
den vielleicht den Aufruf protokollieren oder die Persistierung in einem Java-Objekt emulieren.

Beim Mocking geht es also darum, beim Ausführen der gemockten void-Methode einen Seiteneffekt herbeizuführen.
Wie bereits beschrieben, giebt es prinzipiell zwei Muster nach denen sich in Mockito Methoden-Verhalten
implementieren läßt. Im Falle von void-Methoden fällt das when...then-Pattern jedoch aus, da die
Methode {{java|Mockito.when()}} keine void-Methoden verdauen kann.

Wir erzeugen also erstmal einen Mock:
{{java|code=Transform mock = Mockito.mock(CustomerManager.class);}}
und definieren die Antwort so:
{{java|code=
Mockito.doAnswer(new Answer<Void>() {
@Override
public Void answer(InvocationOnMock invocation) throws Throwable {
// Seiteneffekt
return null;
}
}).when(mock).save(Mockito.any(Customer.class));
}}
Der Trick ist die Verwendung der – übrigens schon seit JDK 1.1 existierenden – Klasse {{java|Void}}(mit großem Vau).
Zu jedem primitiven Typ gibt es in Java eine passende Wrapper-Klasse; ein Analogon hat der Ergebnis-Typ {{java|void}} in der
{{java|Void}}-Klasse. Da es keine {{java|void}}-Werte giebt, giebt es auch keine Instanzen der {{java|Void}}-Klasse;
die Klasse selbst gibt es aber und hier finden wir eine Gelegenheit sie zu nutzen: wir definieren damit den Ergebnis-Typ
der Answer-Methode.

Da {{java|Void}} – im Gegensatz zu {{java|void}} – eine Klasse ist, muß die {{java|answer}}-Methode ein Ergebnis liefern und
benötigt daher am Ende die Anweisung {{java|return null}}.

Natürlich läßt sich das auch mit einem {{lambda}}-Ausdruck schreiben:
{{java|code=
Mockito.doAnswer((Answer<Void>) invocation -> {
// Seiteneffekt
return null;
}).when(mock).save(Mockito.any(Customer .class));
}}
=== Methoden die Class-Objekte liefern ===
Dieses Problem wird [[Mockito: Methoden die Class-Objekte liefern|hier]] beschrieben
=== Methoden mit Variablen Argument-Listen ===
Weichen wir mal der Diskussion aus, ob Var-Arg-Methoden schön, sinnvoll oder wünschenswert sind und welche
Probleme sie mit sich bringen (könnten). Nehmen wir einfach an, wir hätten so ein Ding und ''müßten'' es mocken -- wie geht das?
Die Methode {{java|process}} akzeptiere eine beliebige Anzahl von {{java|Customer}}-Objekten, tue irgendwas damit und liefere
die Anzahl der verarbeiteten Objekte.
{{java|code=
public interface Transform {
int process(Customer... customer);
}
}}
Wie bereits beschrieben, können wir über ein Objekt der Klasse {{java|InvocationOnMock}} auf die Argumente zugreifen
die beim Aufruf der gemockten Methode übergeben werden. Die vararg-Argumente erhalten wir so als array und können z.B.
mit einer for-Schleife darüber iterieren. Versuchen wir es hier etwas hübscher aussehen zu lassen, indem wir das array in
eine typisierte Liste überführen.

Wir schreiben zunächst die Mock-Methode mit dem doAnswer...when-Pattern:
{{java|code=
void test() {
Mockito.doAnswer(new Answer<Integer>() {
@Override
public Integer answer(InvocationOnMock invocation) throws Throwable {
List<Customer> kunden = argliste(invocation.getArguments());
return kunden.size();
}
}).when(mock).process(Mockito.any());
}
}}
Und nun zur {{java|.argliste()}}-Methode, die das Object-array in ein {{java|List<Customer>}}-Objekt umwandelt. Es giebt
viele Möglichkeiten, die elegantesten arbeitet natürlich mit einem Stream. Das Delikate daran ist das erforderliche Casting, wir
verwenden dazu die .class-Klasse für die Customer-Klasse:
{{java|code=
List<Customer> argliste(Object liste[]) {
return Stream.of(liste)
.filter(Customer.class::isInstance)
.map(Customer.class::cast)
.collect(Collectors.toList());
}
}}
Was hierbei nicht offensichtlich ist, ist daß die {{java|arguments}}-Methode von {{java|InvocationOnMock}}
''alle'' Argumente liefert –- nicht nur die vararg-Argumente. Im folgenden Beispiel
{{java|int process(String beschreibung, Customer... customer);}}
liefert {{java|.arguments()[0]}} das Argument für den String-Parameter und erst ab {{java|.arguments()[1]}} kommen die vararg-Argumente.
Die obige Methode {{java|argliste}} funktioniert auch in diesem Falle unmittelbar, weil der nicht-variable Teil der ParameterListe
keine {{java|Customer}}-Objekte enthält. Das String-Argument wird einfach herausgefiltert.
Anders sieht es in diesem Beispiel aus:
{{java|code=int process(Customer referenz, String beschreibung, Customer... customer);}}
Offensichtlich soll das erste Customer-Objekt anders behandelt werden als die der vararg-Liste. Aber auch das geht
mit Streams ganz einfach. Wir müssen ja nur die ersten beiden Argumente bei der Verarbeitung überspringen; das
geht mit der {{java|.skip()}}-Methode:
{{java|code=
List<Customer> argliste(Object liste[]) {
return Stream.of(liste)
.skip(2)
.filter(Customer.class::isInstance)
.map(Customer.class::cast)
.collect(Collectors.toList());
}
}}
Und wenn wir die Methode noch öfter brauchen, können wir den start-Index (beginnend bei 0) und das verwendete
{{java|Class}}-Objekt noch parametrisieren:
{{java|code=
<T> List<T> argliste(Object liste[], int startIndex, Class<T> klasse) {
return Stream.of(liste)
.skip(startIndex)
.filter(klasse::isInstance)
.map(klasse::cast)
.collect(Collectors.toList());
}
}}
Diese letzte Variante können wir nun für das Mocking jeder Varag-Methode für jeden Varag-Typ verwenden.

== Abstrakte Klassen mocken ==
Der gemeine Mockito-Mock ersetzt alle Methoden der gemockten Klasse durch leere Mock-Aufrufe die –
defaultmäßig – gar nichts tun. Das kann man verhindern durch Angabe eines zusätzlichen Parameters:
{{java|code=MeineKlasse meinMock = mock(MeineKlasse.class, Mockito.CALLS_REAL_METHODS);}}

Wird jetzt eine Methode des Mocks aufgerufen, ruft dieser die originale Methode der Klasse {{java|MeineKlasse}} auf.
Anschließend kann man einzelne Methoden mocken und so einen partiellen Mock zu erzeugen.
Bei abstrakten Klassen tritt der Mock in's leere, sobald eine abstrakte Methode aufgerufen wird, weil es für diese
naturgemäß keine "echte" Methode giebt, die aufgerufen werden könnte. Um eine abstrakte Klasse so zu mocken,
daß genau die abstrakten Methoden gemockt werden, muß man also jede abstrakte Methode durch eine mock-Methode ersetzen – wie öde...
Mit der folgenden Klasse kann man das – Reflection sei dank – vollautomatisch erledigen lassen:
{{java|code=
import java.lang.reflect.Modifier;
...
public class MockerForAbstractMethods implements Answer<Object> {
@Override
public Object answer(InvocationOnMock invocation) throws Throwable {
if (Modifier.isAbstract(invocation.getMethod().getModifiers())) {
return Mockito.RETURNS_DEFAULTS.answer(invocation);
}
return Mockito.CALLS_REAL_METHODS.answer(invocation);
}
}
}}
Diese Klasse legt man an geeigneter Stelle ab, irgendwo im test-Ordner des Projekts. Die Anwendung im Unit-Tests
sieht dann so aus:
{{java|code=MeineKlasse meinMock = mock(MeineKlasse.class, new MockerForAbstractMethods());}}

Das Objekt prüft bei jedem Aufruf ob da eine abstrakte Methode aufgerufen wird und ersetzt den Aufruf durch einen
Mock-Aufruf. Ist die Methode nicht abstrakt, wird die "echte" Methode aufgerufen. Um das ganze in der Anwendung
etwas gefälliger zu machen, kann man die Instanz statisch erzeugen und eine Konstante dafür definieren:
{{java|code=public static final Answer<Object> MOCK_ABSTRACT_METHODS = new MockerForAbstractMethod();}}
Die Konstante kann man statisch importieren und dann schreiben:
{{java|code=MeineKlasse meinMock = mock(MeineKlasse.class, MOCK_ABSTRACT_METHODS);}}

Java 17: Records

2023-10-21T19:00:45Z

Ullrich: /* Komplexe Zahlen */

[[Category:Java]]
== Records ==
Der {{java|record}} ist eine neue Java-Komponente die auf einer Ebene liegt mit Klassen und Interfaces.
Man kann ihn beschreiben als eine nicht ableitbare Klasse unveränderlicher (immutable) Objekte.

Das schöne am {{java|record}} ist, daß er eine ganze Reihe von default-Implementierungen bietet,
ohne daß man den ganzen boiler plate code dazu tippen muß.
Die Deklaration erfolgt nicht mit dem Keyword {{java|class}}, sondern mit dem [[Keywords|context keyword]] {{java|record}}.

Hier ist eine ganz einfache Deklaration:
{{java|code=
public record Kilometer(double dist) {};
}}
Was bietet uns der record {{java|Kilometer}}?

* Ein {{java|Kilometer}}-Objekt hat ein einziges Feld {{java|dist}} from Typ {{java|double}}
* Objekte werden erzeugt über {{java|new Kilometer(42.195)}}
* Auf den Wert wird zugegriffen über den Getter {{java|dist()}}
* Die Methode {{java|toString()}} liefert etwas wie "Kilometer [dist=42.195]"
* Die Methoden {{java|equals}} und {{java|hashCode}} werden -- gemäß Kontrakt implementiert

All' das erzeugt der Compiler automatisch.
Natürlich ist die Erzeugungung von records mit beliebig vielen Feldern möglich,
weiter unten ist eine Beispiel mit zwei Feldern geschrieben.

Was kann man nun mit dem {{java|record}} anstellen?

Neben der offensichtlichen Möglichkeit, damit Data-Container ohne großen Overhead zu generieren,
Kann man damit auch eigene Datentypen definieren. Denn ein {{java|record}} kann -- wie jede andere Klasse auch --
statische und nicht-statische Methoden enthalten. Das Einzige was nicht erlaubt ist, ist die Definition von nicht-statischen Feldern.
Mit anderen Worten:
{{quote|Der Status eines record-Objektes wird durch die initiale Befüllung der implizit definierten Felder bestimmt und ändert sich niemals.}}

=== Nur syntaktischer Zucker? ===
Records lassen uns also eine ganze Menge Code sparen, aber strenggenommen können wir damit nicht mehr machen
als mit klassischen Klassen bereits möglich war. Lohnt sich die Erweiterung dann überhaupt

Tatsächlich sind Records zunächst Java-Klassen, allerdings haben sie ein eigenes Flag
das sie für die JVM von normalen Klassen unterscheidbar macht. Sie werden von der JVM anders behandelt, sind effizienter
und können beim Optimieren der JVM noch besser gemacht werden.

=== Komplexe Zahlen ===
Ein ganz hübsches Beispiel ist die Definition [https://de.wikipedia.org/wiki/Komplexe_Zahl komplexer Zahlen].
Die Deklaration sieht zunächst so aus:
{{java | code=
public record Complex(double real, double img) {
}
}}
Der reale Anteil wird mit {{java|real}} bezeichnet, der imaginäre -- wir sind tippfaul -- mit {{java|img}}.
Sie werden mit den Gettern {{java|real()}} und {{java|img()}} angefragt. Der Compiler erzeugt uns einen Konstruktor
mit zwei {{java|double}}-Werten die der Reihenfolge der Deklaration entsprechen:
{{java|code=
public Complex(double real, double img) {
this.real = real;
this.img = img;
}
}}
Jetzt können wir Methoden implementieren um mit den Zahlen zu rechnen -- etwa die Addition:
{{java|code=
public Complex plus(Complex b) {
return new Complex(this.real + b.real, this.img + b.img);
}
}}
Da record-Objekte nicht verändert werden können, wird bei der Addition jedesmal ein neues Objekt erzeugt.
Das ist typisch für immutable objects und entspricht auch der Implementierung von Klassen wie {{java|LocalDate}}.

Die Additions-Methode lternativ könnte man auch statisch definieren:
{{java|code=
public static Complex plus(Complex a, Complex b) {
return new Complex(a.real + b.real, a.img + b.img);
}
}}
Will man keine extra-Methode für die Ausgabe implementieren, kann man für eine hübschere Ausgabe die {{java|toString}}-Methode überschreiben:
{{java|code=
@Override
public String toString() {
return real + " + " + img + "i";
}
}}

Warum ist das cool? Mit herkömmlichen Klassen ist das schon seit Java 1.1 möglich?

# Der Code wird sehr übersichtlich, weil Java uns eine ganze Menge abnimmt
# Die Objekte sind immutable, ohne daß dafür irgendwelche Maßnahmen erforderlich wären
# Die Java-VM kann die Verarbeitung der records in diesem Sinne optimieren

Den kompletten Code [https://github.com/mletkin/java17/blob/main/src/main/java/org/mletkin/java17/rec/Complex.java giebt's hier].

=== Integrierte Validierung ===
Um eine eMail-Adresse zu speichern verwenden die meisten Entwickler den Java-Typ {{java|String}}.
Das ist grundsätzlich verkehrt, wenn man die die Zeichenkette "balfasel" betrachtet, denn das ist definitiv keine keine gültige eMail-Adresse.

Weil ein String immer gegene einen beliebigen anderen String ausgetauscht werden kann, muß der String vor jeder Verwednung
daraufhin geprüft werden ob er tatsächlich eine gültige eMail-Adresse enthält. Stellen wir uns eine Anwendung vor die ganz am Anfang
eine eMail-Adresse beschafft und dann durch viele Schichten durchreicht bevor sie denn endlich irgendwann verwendet wird.
Wenn sich dann tatsächlich herausstellt, daß die eMail-Adresse korrupt ist, was macht man dann mit dem Fehler?

Der objektorientierte Weg ist -- auch hier -- den String in einer eigenen Klasse zu kapseln.
Dazu hat keine Entwickler lust. Niemand mag den ganzen Code schreiben, niemand mag die mögliche Performance-Einbuße in kauf nehmen.

Java 17 diesen Ausreden mit dem {{java|record}} ein Ende.

Folgende einfache Impementierung verdeutlicht die Idee
{{java|code=
public record EmailAdress(String adr) {
public EmailAdress(String adr) {
if (!(adr == null && adr.contains("@")));
throw new RuntimeException("not an eMail address: " + adr);
}
this.adr = adr;
}
}
}}
Genau wie der default-Konstruktor kann auch der für den {{java|record}} vom Compiler automatisch erzeugte Konstruktur
durch einen Selbstgeschriebenen ersetzt werden. Im obigen Beispiel wird das {{java|record}}-Objekt nur dann erzeugt,
wenn der als eMail-Adresse angebotene String eine Affenschaukel enthält.

Der Beispiel-Code ist auf [https://github.com/mletkin/java17/tree/main/src/main/java/org/mletkin/java17/rec GitHub] zu finden.

Vorlage:Java

2023-10-21T18:59:13Z

Ullrich: Änderung 173 von Ullrich (Diskussion) rückgängig gemacht.

{{#if: {{{code|}}} | {{#tag:pre|{{{code}}}}} | <code>{{{1}}}</code>}}

Vorlage:Java

2023-10-21T18:56:35Z

Ullrich:

{{#if: {{{code|}}} | {{#tag:syntaxhighlight|{{{code}}}|lang=java}} | <code>{{{1}}}</code>}}

Java 17: Records

2023-10-21T18:39:02Z

Ullrich: /* Integrierte Validierung */

Java 17: Records

2023-10-21T18:37:44Z

Ullrich:

[[Category:Java]]
== Records ==
Der {{java|record}} ist eine neue Java-Komponente die auf einer Ebene liegt mit Klassen und Interfaces.
Man kann ihn beschreiben als eine nicht ableitbare Klasse unveränderlicher (immutable) Objekte.

Das schöne am {{java|record}} ist, daß er eine ganze Reihe von default-Implementierungen bietet,
ohne daß man den ganzen boiler plate code dazu tippen muß.
Die Deklaration erfolgt nicht mit dem Keyword {{java|class}}, sondern mit dem [[Keywords|context keyword]] {{java|record}}.

Hier ist eine ganz einfache Deklaration:
{{java|code=
public record Kilometer(double dist) {};
}}
Was bietet uns der record {{java|Kilometer}}?

* Ein {{java|Kilometer}}-Objekt hat ein einziges Feld {{java|dist}} from Typ {{java|double}}
* Objekte werden erzeugt über {{java|new Kilometer(42.195)}}
* Auf den Wert wird zugegriffen über den Getter {{java|dist()}}
* Die Methode {{java|toString()}} liefert etwas wie "Kilometer [dist=42.195]"
* Die Methoden {{java|equals}} und {{java|hashCode}} werden -- gemäß Kontrakt implementiert

All' das erzeugt der Compiler automatisch.
Natürlich ist die Erzeugungung von records mit beliebig vielen Feldern möglich,
weiter unten ist eine Beispiel mit zwei Feldern geschrieben.

Was kann man nun mit dem {{java|record}} anstellen?

Neben der offensichtlichen Möglichkeit, damit Data-Container ohne großen Overhead zu generieren,
Kann man damit auch eigene Datentypen definieren. Denn ein {{java|record}} kann -- wie jede andere Klasse auch --
statische und nicht-statische Methoden enthalten. Das Einzige was nicht erlaubt ist, ist die Definition von nicht-statischen Feldern.
Mit anderen Worten:
{{quote|Der Status eines record-Objektes wird durch die initiale Befüllung der implizit definierten Felder bestimmt und ändert sich niemals.}}

=== Nur syntaktischer Zucker? ===
Records lassen uns also eine ganze Menge Code sparen, aber strenggenommen können wir damit nicht mehr machen
als mit klassischen Klassen bereits möglich war. Lohnt sich die Erweiterung dann überhaupt

Tatsächlich sind Records zunächst Java-Klassen, allerdings haben sie ein eigenes Flag
das sie für die JVM von normalen Klassen unterscheidbar macht. Sie werden von der JVM anders behandelt, sind effizienter
und können beim Optimieren der JVM noch besser gemacht werden.

=== Komplexe Zahlen ===
Ein ganz hübsches Beispiel ist die Definition [https://de.wikipedia.org/wiki/Komplexe_Zahl komplexer Zahlen].
Die Deklaration sieht zunächst so aus:
{{java | code=
public record Complex(double real, double img) {
}
}}
Der reale Anteil wird mit {{java|real}} bezeichnet, der imaginäre -- wir sind tippfaul -- mit {{java|img}}.
Sie werden mit den Gettern {{java|real()}} und {{java|img()}} angefragt. Der Compiler erzeugt uns einen Konstruktor
mit zwei {{java|double}}-Werten die der Reihenfolge der Deklaration entsprechen:
{{java|code=
public Complex(double real, double img) {
this.real = real;
this.img = img;
}
}}
Jetzt können wir Methoden implementieren um mit den Zahlen zu rechnen -- etwa die Addition:
{{java|code=
public Complex plus(Complex b) {
return new Complex(this.real + b.real, this.img + b.img);
}
}}
Da record-Objekte nicht verändert werden können, wird bei der Addition jedesmal ein neues Objekt erzeugt.
Das ist typisch für immutable objects und entspricht auch der Implementierung von Klassen wie {{java|LocalDate}}.

Die Additions-Methode lternativ könnte man auch statisch definieren:
{{java|code=
public static Complex plus(Complex a, Complex b) {
return new Complex(a.real + b.real, a.img + b.img);
}
}}
Will man keine extra-Methode für die Ausgabe implementieren, kann man für eine hübschere Ausgabe die {{java|toString}}-Methode überschreiben:
{{java|code=
@Override
public String toString() {
return real + " + " + img + "i";
}
}}

Warum ist das cool? Mit herkömmlichen Klassen ist das schon seit Java 1.1 möglich?

# Der Code wird sehr übersichtlich, weil Java uns eine ganze Menge abnimmt
# Die Objekte sind immutable, ohne daß dafür irgendwelche Maßnahmen erforderlich wären
# Die Java-VM kann die Verarbeitung der records in diesem Sinne optimieren

Den kompletten Code [https://github.com/mletkin/java17/blob/main/src/main/java/org/mletkin/java17/rec/Complex.java giebt's hier].

=== Integrierte Validierung ===
Um eine eMail-Adresse zu speichern verwenden die meisten Entwickler den Java-Typ {{java|String}}.
Das ist grundsätzlich verkehrt, wenn man die die Zeichenkette "balfasel" betrachtet, denn das ist definitiv keine keine gültige eMail-Adresse.

Weil ein String immer gegene einen beliebigen anderen String ausgetauscht werden kann, muß der String vor jeder Verwednung
daraufhin geprüft werden ob er tatsächlich eine gültige eMail-Adresse enthält. Stellen wir uns eine Anwendung vor die ganz am Anfang
eine eMail-Adresse beschafft und dann durch viele Schichten durchreicht bevor sie denn endlich irgendwann verwendet wird.
Wenn sich dann tatsächlich herausstellt, daß die eMail-Adresse korrupt ist, was macht man dann mit dem Fehler?

Der objektorientierte Weg ist -- auch hier -- den String in einer eigenen Klasse zu kapseln.
Dazu hat keine Entwickler lust. Niemand mag den ganzen Code schreiben, niemand mag die mögliche Performance-Einbuße in kauf nehmen.

Java 17 diesen Ausreden mit dem {{java|record}} ein Ende.

Folgende einfache Impementierung verdeutlicht die Idee
{{java|code=
public record EmailAdress(String adr) {
public EmailAdress(String adr) {
if (adr == null || !adr.contains("@"));
throw new RuntimeException("not an eMail address: " + adr);
}
this.adr = adr;
}
}
}}
Genau wie der default-Konstruktor kann auch der für den {{java|record}} vom Compiler automatisch erzeugte Konstruktur
durch einen Selbstgeschriebenen ersetzt werden. Im obigen Beispiel wird das {{java|record}}-Objekt nur dann erzeugt,
wenn der als eMail-Adresse angebotene String eine Affenschaukel enthält.

Der Beispiel-Code ist auf [https://github.com/mletkin/java17/tree/main/src/main/java/org/mletkin/java17/rec GitHub] zu finden.

Java 17: Records

2023-10-21T18:34:41Z

Ullrich: Ullrich verschob die Seite Java 17:Records nach Java 17: Records, ohne dabei eine Weiterleitung anzulegen

[[Category:Java]]
== Records ==
Der {{java|record}} ist eine neue Java-Komponente die auf einer Ebene liegt mit Klassen und Interfaces.
Man kann ihn beschreiben als eine nicht ableitbare Klasse unveränderlicher (immutable) Objekte.

Das schöne am {{java|record}} ist, daß er eine ganze Reihe von default-Implementierungen bietet,
ohne daß man den ganzen boiler plate code dazu tippen muß.
Die Deklaration erfolgt nicht mit dem Keyword {{java|class}}, sondern mit dem [[Keywords|context keyword]] {{java|record}}.

Hier ist eine ganz einfache Deklaration:
{{java|code=
public record Kilometer(double dist) {};
}}
Was bietet uns der record {{java|Kilometer}}?

* Ein {{java|Kilometer}}-Objekt hat ein einziges Feld {{java|dist}} from Typ {{java|double}}
* Objekte werden erzeugt über {{java|new Kilometer(42.195)}}
* Auf den Wert wird zugegriffen über den Getter {{java|dist()}}
* Die Methode {{java|toString()}} liefert etwas wie "Kilometer [dist=42.195]"
* Die Methoden {{java|equals}} und {{java|hashCode}} werden -- gemäß Kontrakt implementiert

All' das erzeugt der Compiler automatisch.
Natürlich ist die Erzeugungung von records mit beliebig vielen Feldern möglich,
weiter unten ist eine Beispiel mit zwei Feldern geschrieben.

Was kann man nun mit dem {{java|record}} anstellen?

Neben der offensichtlichen Möglichkeit, damit Data-Container ohne großen Overhead zu generieren,
Kann man damit auch eigene Datentypen definieren. Denn ein {{java|record}} kann -- wie jede andere Klasse auch --
statische und nicht-statische Methoden enthalten. Das Einzige was nicht erlaubt ist, ist die Definition von nicht-statischen Feldern.
Mit anderen Worten:
Der Status eines record-Objektes wird durch die initiale Befüllung der implizit definierten Felder bestimmt und ändert sich niemals.

=== Nur syntaktischer Zucker? ===
Records lassen uns also eine ganze Menge Code sparen, aber strenggenommen können wir damit nicht mehr machen
als mit klassischen Klassen bereits möglich war. Lohnt sich die Erweiterung dann überhaupt

Tatsächlich sind Records zunächst Java-Klassen, allerdings haben sie ein eigenes Flag
das sie für die JVM von normalen Klassen unterscheidbar macht. Sie werden von der JVM anders behandelt, sind effizienter
und können beim Optimieren der JVM noch besser gemacht werden.

=== Komplexe Zahlen ===
Ein ganz hübsches Beispiel ist die Definition [https://de.wikipedia.org/wiki/Komplexe_Zahl komplexer Zahlen].
Die Deklaration sieht zunächst so aus:
{{java | code=
public record Complex(double real, double img) {
}
}}
Der reale Anteil wird mit {{java|real}} bezeichnet, der imaginäre -- wir sind tippfaul -- mit {{java|img}}.
Sie werden mit den Gettern {{java|real()}} und {{java|img()}} angefragt. Der Compiler erzeugt uns einen Konstruktor
mit zwei {{java|double}}-Werten die der Reihenfolge der Deklaration entsprechen:
{{java|code=
public Complex(double real, double img) {
this.real = real;
this.img = img;
}
}}
Jetzt können wir Methoden implementieren um mit den Zahlen zu rechnen -- etwa die Addition:
{{java|code=
public Complex plus(Complex b) {
return new Complex(this.real + b.real, this.img + b.img);
}
}}
Da record-Objekte nicht verändert werden können, wird bei der Addition jedesmal ein neues Objekt erzeugt.
Das ist typisch für immutable objects und entspricht auch der Implementierung von Klassen wie {{java|LocalDate}}.

Die Additions-Methode lternativ könnte man auch statisch definieren:
{{java|code=
public static Complex plus(Complex a, Complex b) {
return new Complex(a.real + b.real, a.img + b.img);
}
}}
Will man keine extra-Methode für die Ausgabe implementieren, kann man für eine hübschere Ausgabe die {{java|toString}}-Methode überschreiben:
{{java|code=
@Override
public String toString() {
return real + " + " + img + "i";
}
}}

Warum ist das cool? Mit herkömmlichen Klassen ist das schon seit Java 1.1 möglich?

# Der Code wird sehr übersichtlich, weil Java uns eine ganze Menge abnimmt
# Die Objekte sind immutable, ohne daß dafür irgendwelche Maßnahmen erforderlich wären
# Die Java-VM kann die Verarbeitung der records in diesem Sinne optimieren

Den kompletten Code [https://github.com/mletkin/java17/blob/main/src/main/java/org/mletkin/java17/rec/Complex.java giebt's hier].

=== Integrierte Validierung ===
Um eine eMail-Adresse zu speichern verwenden die meisten Entwickler den Java-Typ {{java|String}}.
Das ist grundsätzlich verkehrt, wenn man die die Zeichenkette "balfasel" betrachtet, denn das ist definitiv keine keine gültige eMail-Adresse.

Weil ein String immer gegene einen beliebigen anderen String ausgetauscht werden kann, muß der String vor jeder Verwednung
daraufhin geprüft werden ob er tatsächlich eine gültige eMail-Adresse enthält. Stellen wir uns eine Anwendung vor die ganz am Anfang
eine eMail-Adresse beschafft und dann durch viele Schichten durchreicht bevor sie denn endlich irgendwann verwendet wird.
Wenn sich dann tatsächlich herausstellt, daß die eMail-Adresse korrupt ist, was macht man dann mit dem Fehler?

Der objektorientierte Weg ist -- auch hier -- den String in einer eigenen Klasse zu kapseln.
Dazu hat keine Entwickler lust. Niemand mag den ganzen Code schreiben, niemand mag die mögliche Performance-Einbuße in kauf nehmen.

Java 17 diesen Ausreden mit dem {{java|record}} ein Ende.

Folgende einfache Impementierung verdeutlicht die Idee
{{java|code=
public record EmailAdress(String adr) {
public EmailAdress(String adr) {
if (adr == null || !adr.contains("@"));
throw new RuntimeException("not an eMail address: " + adr);
}
this.adr = adr;
}
}
}}
Genau wie der default-Konstruktor kann auch der für den {{java|record}} vom Compiler automatisch erzeugte Konstruktur
durch einen Selbstgeschriebenen ersetzt werden. Im obigen Beispiel wird das {{java|record}}-Objekt nur dann erzeugt,
wenn der als eMail-Adresse angebotene String eine Affenschaukel enthält.

Der Beispiel-Code ist auf [https://github.com/mletkin/java17/tree/main/src/main/java/org/mletkin/java17/rec GitHub] zu finden.

Neue Java Features

2023-10-21T18:33:45Z

Ullrich: Die Seite wurde neu angelegt: „Category:Java == Java 17 == Die neuen Sprach-Features sind separat auf folgenen Seiten beschrieben *Java 17: Text Block Mehrzeilige String-Literale *Java 17: instanceof Erweiterung des {{java|instanceof}}-Operators *Java 17: Switch Erweiterung der {{java|switch}}-Kontrollstruktur *Java 17: Sealed Classes Die Ableitbarkeit von Klassen steuern *Java 17: Records Definition unveränderlicher Daten-Objekte Der Beispiel-Code ist auf [h…“

[[Category:Java]]
== Java 17 ==
Die neuen Sprach-Features sind separat auf folgenen Seiten beschrieben
*[[Java 17: Text Block]] Mehrzeilige String-Literale
*[[Java 17: instanceof]] Erweiterung des {{java|instanceof}}-Operators
*[[Java 17: Switch]] Erweiterung der {{java|switch}}-Kontrollstruktur
*[[Java 17: Sealed Classes]] Die Ableitbarkeit von Klassen steuern
*[[Java 17: Records]] Definition unveränderlicher Daten-Objekte

Der Beispiel-Code ist auf [https://github.com/mletkin/java17/tree/main GitHub] verfügbar

Nicht beschrieben werden die erweiterung der JDK-Bibliotheken, der Tools und der JVM.

Vollumfänglich werden alle Änderungen in den [https://www.oracle.com/java/technologies/javase/17-relnote-issues.html Release Notes] beschrieben

Alle Details zur Sprache findet sich in der [https://docs.oracle.com/javase/specs/jls/se17/html/ Java-Spezifikation]

Java 17: Records

2023-10-21T18:32:18Z

Ullrich: Die Seite wurde neu angelegt: „Category:Java == Records == Der {{java|record}} ist eine neue Java-Komponente die auf einer Ebene liegt mit Klassen und Interfaces. Man kann ihn beschreiben als eine nicht ableitbare Klasse unveränderlicher (immutable) Objekte. Das schöne am {{java|record}} ist, daß er eine ganze Reihe von default-Implementierungen bietet, ohne daß man den ganzen boiler plate code dazu tippen muß. Die Deklaration erfolgt nicht mit dem Keyword {{java|class}}, son…“

[[Category:Java]]
== Records ==
Der {{java|record}} ist eine neue Java-Komponente die auf einer Ebene liegt mit Klassen und Interfaces.
Man kann ihn beschreiben als eine nicht ableitbare Klasse unveränderlicher (immutable) Objekte.

Das schöne am {{java|record}} ist, daß er eine ganze Reihe von default-Implementierungen bietet,
ohne daß man den ganzen boiler plate code dazu tippen muß.
Die Deklaration erfolgt nicht mit dem Keyword {{java|class}}, sondern mit dem [[Keywords|context keyword]] {{java|record}}.

Hier ist eine ganz einfache Deklaration:
{{java|code=
public record Kilometer(double dist) {};
}}
Was bietet uns der record {{java|Kilometer}}?

* Ein {{java|Kilometer}}-Objekt hat ein einziges Feld {{java|dist}} from Typ {{java|double}}
* Objekte werden erzeugt über {{java|new Kilometer(42.195)}}
* Auf den Wert wird zugegriffen über den Getter {{java|dist()}}
* Die Methode {{java|toString()}} liefert etwas wie "Kilometer [dist=42.195]"
* Die Methoden {{java|equals}} und {{java|hashCode}} werden -- gemäß Kontrakt implementiert

All' das erzeugt der Compiler automatisch.
Natürlich ist die Erzeugungung von records mit beliebig vielen Feldern möglich,
weiter unten ist eine Beispiel mit zwei Feldern geschrieben.

Was kann man nun mit dem {{java|record}} anstellen?

Neben der offensichtlichen Möglichkeit, damit Data-Container ohne großen Overhead zu generieren,
Kann man damit auch eigene Datentypen definieren. Denn ein {{java|record}} kann -- wie jede andere Klasse auch --
statische und nicht-statische Methoden enthalten. Das Einzige was nicht erlaubt ist, ist die Definition von nicht-statischen Feldern.
Mit anderen Worten:
Der Status eines record-Objektes wird durch die initiale Befüllung der implizit definierten Felder bestimmt und ändert sich niemals.

=== Nur syntaktischer Zucker? ===
Records lassen uns also eine ganze Menge Code sparen, aber strenggenommen können wir damit nicht mehr machen
als mit klassischen Klassen bereits möglich war. Lohnt sich die Erweiterung dann überhaupt

Tatsächlich sind Records zunächst Java-Klassen, allerdings haben sie ein eigenes Flag
das sie für die JVM von normalen Klassen unterscheidbar macht. Sie werden von der JVM anders behandelt, sind effizienter
und können beim Optimieren der JVM noch besser gemacht werden.

=== Komplexe Zahlen ===
Ein ganz hübsches Beispiel ist die Definition [https://de.wikipedia.org/wiki/Komplexe_Zahl komplexer Zahlen].
Die Deklaration sieht zunächst so aus:
{{java | code=
public record Complex(double real, double img) {
}
}}
Der reale Anteil wird mit {{java|real}} bezeichnet, der imaginäre -- wir sind tippfaul -- mit {{java|img}}.
Sie werden mit den Gettern {{java|real()}} und {{java|img()}} angefragt. Der Compiler erzeugt uns einen Konstruktor
mit zwei {{java|double}}-Werten die der Reihenfolge der Deklaration entsprechen:
{{java|code=
public Complex(double real, double img) {
this.real = real;
this.img = img;
}
}}
Jetzt können wir Methoden implementieren um mit den Zahlen zu rechnen -- etwa die Addition:
{{java|code=
public Complex plus(Complex b) {
return new Complex(this.real + b.real, this.img + b.img);
}
}}
Da record-Objekte nicht verändert werden können, wird bei der Addition jedesmal ein neues Objekt erzeugt.
Das ist typisch für immutable objects und entspricht auch der Implementierung von Klassen wie {{java|LocalDate}}.

Die Additions-Methode lternativ könnte man auch statisch definieren:
{{java|code=
public static Complex plus(Complex a, Complex b) {
return new Complex(a.real + b.real, a.img + b.img);
}
}}
Will man keine extra-Methode für die Ausgabe implementieren, kann man für eine hübschere Ausgabe die {{java|toString}}-Methode überschreiben:
{{java|code=
@Override
public String toString() {
return real + " + " + img + "i";
}
}}

Warum ist das cool? Mit herkömmlichen Klassen ist das schon seit Java 1.1 möglich?

# Der Code wird sehr übersichtlich, weil Java uns eine ganze Menge abnimmt
# Die Objekte sind immutable, ohne daß dafür irgendwelche Maßnahmen erforderlich wären
# Die Java-VM kann die Verarbeitung der records in diesem Sinne optimieren

Den kompletten Code [https://github.com/mletkin/java17/blob/main/src/main/java/org/mletkin/java17/rec/Complex.java giebt's hier].

=== Integrierte Validierung ===
Um eine eMail-Adresse zu speichern verwenden die meisten Entwickler den Java-Typ {{java|String}}.
Das ist grundsätzlich verkehrt, wenn man die die Zeichenkette "balfasel" betrachtet, denn das ist definitiv keine keine gültige eMail-Adresse.

Weil ein String immer gegene einen beliebigen anderen String ausgetauscht werden kann, muß der String vor jeder Verwednung
daraufhin geprüft werden ob er tatsächlich eine gültige eMail-Adresse enthält. Stellen wir uns eine Anwendung vor die ganz am Anfang
eine eMail-Adresse beschafft und dann durch viele Schichten durchreicht bevor sie denn endlich irgendwann verwendet wird.
Wenn sich dann tatsächlich herausstellt, daß die eMail-Adresse korrupt ist, was macht man dann mit dem Fehler?

Der objektorientierte Weg ist -- auch hier -- den String in einer eigenen Klasse zu kapseln.
Dazu hat keine Entwickler lust. Niemand mag den ganzen Code schreiben, niemand mag die mögliche Performance-Einbuße in kauf nehmen.

Java 17 diesen Ausreden mit dem {{java|record}} ein Ende.

Folgende einfache Impementierung verdeutlicht die Idee
{{java|code=
public record EmailAdress(String adr) {
public EmailAdress(String adr) {
if (adr == null || !adr.contains("@"));
throw new RuntimeException("not an eMail address: " + adr);
}
this.adr = adr;
}
}
}}
Genau wie der default-Konstruktor kann auch der für den {{java|record}} vom Compiler automatisch erzeugte Konstruktur
durch einen Selbstgeschriebenen ersetzt werden. Im obigen Beispiel wird das {{java|record}}-Objekt nur dann erzeugt,
wenn der als eMail-Adresse angebotene String eine Affenschaukel enthält.

Der Beispiel-Code ist auf [https://github.com/mletkin/java17/tree/main/src/main/java/org/mletkin/java17/rec GitHub] zu finden.

Java 17: Switch

2023-10-21T18:31:15Z

Ullrich: Die Seite wurde neu angelegt: „Um die Erwartungen vorab zu dämpfen: Auch Java 17 erlaubt nur die aufzählbaren Daten-Type sowie String, aber keine anderne Objekt-Typen. Auch führt der Aufruf mit {{java|null}} weiterhin unweigerlich zu einer Null-Pointer-Exception. Betrachten wir die klassische Anwendung der {{java|switch}}-Kontrollstruktur: {{java|code= public void oldStyleOhneBreak(Animal animal) { switch (animal) { case SPIDER: System.out.println("8 legs"); ca…“

Um die Erwartungen vorab zu dämpfen:
Auch Java 17 erlaubt nur die aufzählbaren Daten-Type sowie String, aber keine anderne Objekt-Typen.
Auch führt der Aufruf mit {{java|null}} weiterhin unweigerlich zu einer Null-Pointer-Exception.

Betrachten wir die klassische Anwendung der {{java|switch}}-Kontrollstruktur:
{{java|code=
public void oldStyleOhneBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
case ANT, BEE:
System.out.println("6 legs");
default:
System.out.println("strange animal");
}
}
}}
Der Aufruf von {{java|oldStyleOhneBreak(Animal.ANT)}} liefert:
6 legs
strange animal
Wegen des "fall-through"-Verhaltens (was man berechtigterweise mit "Durchfall" übersetzen kann) werden
alle nachfolgenden Fälle durchlaufen, sobald der erste Match auftritt. Um das zu verhindern, muß man nach
jeder {{java|case}}-Anweisung ein {{java|break}} einfügen:
{{java|code=
public void oldStyleWithBreak(Animal animal) {
switch (animal) {
case SPIDER:
System.out.println("8 legs");
break;
case ANT, BEE:
System.out.println("6 legs");
break;
default:
System.out.println("strange animal");
}
}
}}
Das ist viel Code, unübersichtlich, fehleranfällig -- und kontrovers.
Java 17 bietet nun eine Alternative, bei der der {{java|:}} in der Case-Anweisung durch {{java|->}}.
Es muß aber ausdrücklich darauf hingeweisen werden, daß es sich hier um '''keinen''' {{lambda}}-Ausdruck handelt.
Das Ergebnis der ersten Fassung sieht nun so aus:
{{java|code=
public void newStyle(Animal animal) {
switch (animal) {
case SPIDER -> System.out.println("8 legs");
case ANT, BEE -> System.out.println("6 legs");
default -> System.out.println("strange animal");
}
}
}}
Da für jeden Fall hier nur eine Zeile verwendet wird, ist der gesamte Ausdruck kompakter.
Das könnte man durchaus auch mit dem klassischen {{java|case}}-Konstrukt hinkriegen.

Überraschender ist aber das Ergebnis, wenn man {{java|newStyle(Animal.ANT)}} ausführt:
6 legs
Das {{java|break}} wird nicht mehr benötigt, der neue Stil hat keine Durchfall-Symptome mehr!

Nach dem {{java|->}} darf eine beliebige Anweisung kommen.
Anstelle einer ''einzelnen'' Anweisung ist also auch ein beliebig großer Code-Block erlaubt.

Da wir in jedem der Fälle die gleiche Aktion ausführen, könnten wir uns auch den Ausgabe-Text liefern lassen
und ihn im Anschluß ausgeben. Genau dafür bietet das neue switch eine Möglichkeit:
{{java|code=
public void newStyleWithReturnValue(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
default -> "strange animal";
};
System.out.println(legs);
}
}}
Man kann sich vorstellen, daß switch ''immer'' einen Rückgabe-Typ hat, der allerdings in den vorangehenden Beispielen
{{java|void}} war und daher nicht gespeichert werden konnte. Java prüft in jedem Fall den typ und meldet Verstöße die durch
Inkompatibilität entstehen.

Was machen wir nun, wenn nach dem {{java|->}} kein Ausdruck vom gewünschten Typ kommt, sondern ein ganzer Code-Block?
Hier hilft das {{java|yield}}. Es kommt am Ende des Code-Blocks und giebt den Wert zurück:
{{java|code=
public void newStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER -> "8 legs";
case ANT, BEE -> "6 legs";
case CENTIPEDE -> {
System.err.println("lost count");
yield "many legs";
}
default -> "strange animal";
};
System.out.println(legs);
}
}}

{{java|yield}} ist -- entgegen der ersten Vermutung -- ''kein'' keyword, sondern ein "reservierter Identifier".
So ist die Anweisung
{{java|code=
int yield = 5;
}}
duirchaus erlaubt. Es erübrigt sich, darauf hinzuweisen diese Verwendung zu vermeiden.

Freundlicherweise darf man das {{java|yield}} auch mit dem {{java|switch}} im alten Stil verwenden.
Da dabei das {{java|switch}} unmittelbar verlassen wird, spart man sich dabei das {{break}}:
{{java|code=
public void oldStyleWithYield(Animal animal) {
String legs = switch (animal) {
case SPIDER:
yield "8 legs";
case ANT, BEE:
yield "6 legs";
default:
yield "strange animal";
};
System.out.println(legs);
}
}}

== Fazit ==

Das gemeine {{java|switch}} wird durch die Verwendung von {{java|->}} kompakter und veständlicher.
Folgt man allerdings der Regel möglichst kleine Methoden zu schreiben, wird man praktisch jedes {{java|witch}}
in eine eigene Methode auslagern. Die Rückgabe-Notation bietet dann keine nennenswerten Gewinn mehr.

Nichstdestotrotz hilft das Feature dabei, legacy-Code zu optimieren und darüber zu refactorn.
Dazu schreibt man das {{java|switch}} erst auf die Rückgabe-Notation um und lagert sie dann in eine eigene Methode aus.

Java 17: Sealed Classes

2023-10-21T14:52:03Z

Ullrich: Die Seite wurde neu angelegt: „Category:Java __TOC__ Um die Ableitbarkeit von Klassen zu steuern bietet Java bis Versuion 16 nur eine einzige Möglichkeit, den Modifier {{java|final}}. Ist eine Klasse als {{java|final}} markiert, ist es unmöglich eine weitere Klasse von ihr abzuleiten. Ist die nicht {{java|final}}, kann jeder der Zugriff auf die Klasse hat von ihr beliebige Klassen ableiten. Das folgt dem Gedanken, daß die Klassen-Hierarchie nichts anderes ist als ein Erweiterun…“

[[Category:Java]]
__TOC__
Um die Ableitbarkeit von Klassen zu steuern bietet Java bis Versuion 16 nur eine einzige Möglichkeit, den Modifier {{java|final}}.
Ist eine Klasse als {{java|final}} markiert, ist es unmöglich eine weitere Klasse von ihr abzuleiten.
Ist die nicht {{java|final}}, kann jeder der Zugriff auf die Klasse hat von ihr beliebige Klassen ableiten.

Das folgt dem Gedanken, daß die Klassen-Hierarchie nichts anderes ist als ein Erweiterungs-Konzept.
Möchte man Klassen so modellieren, daß dabei eine abgegrenzten DSL entsteht, eine Abstraktion über die die
Elemente einer bestimmten Domäne der Verarbeitung zugänglich gemacht wird, benötigt man eine feinere Steuerung.
Denn dann möchte man die Ableitung innerhalb der Anwendung einschränken und ggf. nach außen hin ganz unterbinden.

Das Konzept der {{Java|sealed classes}} läßt uns Teile der Klassen-Hierarchie unserer Anwendung vollständig gegen Vererbung abschotten,
wärend Teile der Hierarchie der Vererbung offen bleiben.

== sealed classes ==

Betrachten wir die Klasse {{Java|Shape}} von der nur zwei Klassen abgeleitet werden können sollen:
{{Java|code=
public sealed class Shape permits Quadrangle, Ellipse { ... }
}}
Das [[Keywords|context keyword]] {{Java|sealed}} verschließt die Klasse gegen direkte, nicht vorgesehene Vererbung,
wärend hinter dem [[Keywords|context keyword]] {{Java|permits}} alle Klassen aufgezählt werden die von der Klasse ableiten dürfen.

Was verhält es sich nun mit den beiden abgeleiteten Klassen? Java verlangt, daß für jede Klasse die von
einer {{Java|sealed}} Klasse abgeleitet wird festgelegt wird, wie von ihr abgeleitet werden kann:

:'''final''' von der Klasse ist überhaupt keine Ableitung mehr möglich
:'''non-sealed''' von der Klasse können wieder beliebige weitere Klassen abgeleitet werden
:'''sealed''' wie bei der Super-Klasse werden alle ableitenden Klassen angegeben.

== sealed interfaces ==
Analog zu Klassen können auch Interfaces abgeschottet werden. Hier bieten sich nun zwei Möglichkeiten der
Erweiterung: Zum Einen können von einem Interface neue Interfaces abgeleitet werden,
zum Anderen können Klassen das Interface implementieren. Es entstehen also zwei Varianten der Versiegelung.

Bei der Ableitung verhalten sich die Dinge genauso wie oben für Klassen beschrieben:
Ist das Interface {{java|sealed}}, müssen bei der Definition ''alle'' abgeleiteten Interfaces angegeben werden:
{{Java|code=
public sealed interface Length permits Convex, NonConvex { ... }
}}
Alle abgeleiteten Interfaces verhalten sich wieder wie Klassen, sie müssen entweder {{Java|sealed}} oder {{Java|non-sealed}} sein.
Interfaces können -- weil das absurd wäre -- niemals {{Java|final}} sein.

Implementiert eine Klasse ein {{Java|sealed}} Interface, kommt es in den gleichen Zustand als wäre es von einer {{Java|sealed}} Klasse abgeleitet.
Es muß entweder als {{Java|sealed}}, {{Java|non-sealed}} oder {{Java|final}} markiert sein.

== enums ==
Da das klassische {{java|enum}} implizit -- zumindest fast immer -- {{java|final}} ist, kann es nicht {{java|sealed}} sein.
Da es aber interfaces implementieren kann, kann es auch {{java|sealed}} interfaces implementieren. Da das enum implizit {{java|final}} ist,
braucht es aber nicht weiter markiert zu werden.

In a nutshell: Ein {{java|enum}} kann ein {{java|sealed}} interface implementieren, als wäre es ein normales Interface.

Was sollte im vorangehenden Absatz aber der Einschub "fast immer"?

Betrachten wir dieses kleine -- zugegebenermaßen etwas unsinnige -- enum:
{{Java|code=
public enum Foo {
BLA,
FASEL {
public int wert = 5;
}
}
}}

Es soll nur eines verdeutlichen:

Das enum {{java|Foo}} ist implizit {{java|sealed}} und die einzige Klasse die davon ableitet
ist die namenlose Klasse die den Typ des Objekts {{java|FASEL}} darstellt; diese namenlose Klasse ist imlizit {{java|final}}.

Vereinfacht ausgedrückt:

enums die sealed Interfaces implementieren sind implizit final, Objekte des enums können aber finale Sub-Klassen des enums bilden.

== Mocking ==
Da sealed classes keine Ableitung erlauben, stellt sich die Frage ob man sie mocken kann.
Mit Mockito ist das möglich ab Version 5.0.0, Version 4 kompiliert zwar, wirft bei der Ausführung aber eine Exception.
Gleiches gilt für den Spy, der ebenfalls ab Version 5.0.0 erzeugt werden kann.

An dieser Stelle sei der Vollständigkeit halber darauf hingewiesen,
daß Mockito auch final Klassen mocken und spyen kann -- aber auch erst mit Version 5.0.0

== Fazit ==
Sealed Klasses und Interfaces sind für Java ein Konzept, das das Paradigma nicht gerade ändert, aber doch in eine ungewohnte Richtung biegt.
Formal werden dadurch -- eigentlich unerwünschte -- zyklische Abhängigkeit zwischen Super- und Sub-Klasse geschaffen, weil plötzlich die
Superklasse ihre Subklasses kennt. Inhaltlich aber macht die Superklasse ja davon gar keine Verwendung, es ist in Wirklichkeit eine Compiler-Anweisung.

Man muß die (teil)ge-sealte Hierarchie als ein Ganzes sehen, das einen Teil einer fachlichen Domäne abbildet.
Weil die Domäne als geschlossen betrachtet wird, läßt sie auch keine unkontrollierte Erweiterung zu.
Verwendet man diese Hierarchie nur, hat man keine Wahl und muß sie nehmen wie sie ist.
Arbeitet man an der Hierarchie, weist einen die Versiegelung darauf hin, daß eine Erweiterung vom Konzept an dieser Stelle nicht vorgesehen ist.
Eine Veränderung bedarf zunächst der fachlichen Klärung und die Versiegelung schützt uns davor, voreilige Änderungen durchzuführen.

Wenn eine Programmiersprache Möglichkeiten der Einschränkung schafft, ist das keine Behinderung des Coders.
Es ist die Möglichkeit, Consraints der Domäne explizit zu machen -- und das ist ein wertvolles Hilfsmittel.

Java 17: Text Block

2023-10-21T14:21:48Z

Ullrich: Die Seite wurde neu angelegt: „Category:java Der Text-Block ist vorgesehen für Fälle, in denen ein String-Literal definiert werden soll das mehrere Zeilen -- getrennt durch den System-Zeilen-Trenner -- enthalten soll. Gezeigt wird hier die einfachste Anwendung. Wer tiefer in's Detail gehen mag, sei auf die JavaSpec und das Internet verwiesen. In Java Version <= 16 sieht das in der Regel so aus: {{Java|code= void oldStyle() { String text = "{\n" + // " \"name\": \"Alf…“

[[Category:java]]
Der Text-Block ist vorgesehen für Fälle, in denen ein String-Literal definiert werden soll
das mehrere Zeilen -- getrennt durch den System-Zeilen-Trenner -- enthalten soll.

Gezeigt wird hier die einfachste Anwendung. Wer tiefer in's Detail gehen mag, sei auf die
JavaSpec und das Internet verwiesen.

In Java Version <= 16 sieht das in der Regel so aus:
{{Java|code=
void oldStyle() {
String text = "{\n" + //
" \"name\": \"Alfred Döblin\",\n" + //
" \"alter\": 79,\n" + //
" \"ort\": \"Berlin Alexanderplatz\"\n" + //
"}";
System.out.println(text);
}
}}
Um den Formatter davon abzuhalten die Zeilen zusammenzutackern, werden die Enden mit {{java|//}}-Kommentaren geschützt.
Der Mix aus Anführungszeichen und Backslashes trägt nicht unwesentlich zur Unlesbarkeit bei...

So sieht das nun mit einem Text-Block aus -- das Ergebnis ist identisch:
{{Java|code=
void newStyleNoIndentation() {
String text = """
{
name: Alfred Döblin,
alter: 79,
ort: Berlin Alexanderplatz
}
""";
System.out.println(text);
}
}}
Der Text-Block beginnt mit dreifachen Anführungszeichen und endet auch so.
Innerhalb des Text-Block ist die Verwendung von Anführungszeichen ''ohne'' Backslash davor möglich.

In der ersten Variante war es notwendig, die Zeilen durch das vorangehende Anführungszeichen in jeder Zeile
vor weiterer Einrückung zu schützen. Beim Text-Block ist das nicht erforderlich, der vorangehende Leerraum
wird bei der Ausgabe verschluckt -- warum?

Betrachten wir die Ausgabe dieser Methode:
{{Java|code=
void newStyleNoIndentation() {
String text = """
{
name: Alfred Döblin,
alter: 79,
ort: Berlin Alexanderplatz
}
""";
System.out.println(text);
}
}}
Jede Zeile der Ausgabe ist nun um zwei Leerzeichen nach rechts eingerückt.
Java bestimmt das anhand der negativen Einrückung der abschließenden Triple-Gänsefüße.
Je weiter wir den Abschuß nach links schieben, umso weiter schiebt sich die Ausgabe nach rechts.

Java 17: instanceof

2023-10-21T14:19:40Z

Ullrich: Die Seite wurde neu angelegt: „category:Java Die Diskussion ob {{java|instanceof}} gut oder schlecht, ob Downcasting un-objektorientiert ist oder nicht, soll ein anderesmal geführt werden, hier soll es nur darum gehen, was Java 17 neues für den umstrittensten aller Java-Operatoren bringt. {{java|instanceof}} wird meist zusammen mit einem Downcast verwendet um zu prüfen, ob dieser überhaupt möglich ist. zur Erinnerung: Downcasting heißt, ein Objekt auf eine Subclass der Klas…“

[[category:Java]]
Die Diskussion ob {{java|instanceof}} gut oder schlecht, ob Downcasting un-objektorientiert ist oder nicht,
soll ein anderesmal geführt werden, hier soll es nur darum gehen, was Java 17 neues für den umstrittensten aller
Java-Operatoren bringt.

{{java|instanceof}} wird meist zusammen mit einem Downcast verwendet um zu prüfen, ob dieser überhaupt möglich ist.
zur Erinnerung: Downcasting heißt, ein Objekt auf eine Subclass der Klasse zu casten unter der man es erhalten hat.
Am einfachsten sieht man das an einem Beispiel:
{{java|code=
void foo(Object obj) {
if (obj instanceof Integer) {
Integer zahl = (Integer)obj;
system.out.println("Wert:" + zahl.intValue());
}
}
}}
Ohne den Downcast könnte man nicht auf die Methode {{java|intValue}} zugreifen und ohne die Prüfung mit
{{java| instanceof}} liefe man gefahr eine {{java|ClassCastException}} zu werfen.

Java 17 erlaubt uns nun, die Prüfung und den Cast zusammenzufassen und dabei die Variable anzugeben:
{{java|code=
void foo(Object obj) {
if (obj instanceof Integer zahl) {
system.out.println("Wert:" + zahl.intValue());
}
}
}}
Nicht viel, spart nur eine Zeile -- aber immerhin eine Zeile weniger.

Dieser etwas merkwürdige Scope (Bereich der Sichtbarkeit) der Variable ist uns seit Java 7 vom try...with resources her vertraut:
er erstreckt sich aus den runden Klammern der if-Bedingung hinaus über den nachfolgenden Block.

Etwas bizarr wird's allerdings hier:
{{java|code=
void foo(Object obj) {
if (! obj instanceof Integer zahl) {
throw new RuntimeException();
}
system.out.println("Wert:" + zahl.intValue());
}
}}
Der Compiler erkennt, daß das Casting im if-Block keinen Sinn ergiebt und verzichtet auf die
Erzeugung der lokalen Variable. Dafür merkt er, daß das Cast ''nach'' dem if-Block möglich ist
und stellt sie dort auch zur Verfügung. Ob dieses Feature wirklich sinnvolle Anwendungen hat sei mal dahingestellt,
an das Konstrukt an sich muß man sich aber erstmal gewöhnen. Ohne IDE hat man da schlechte Karten den Überblick zu wahren.

In der Java-Spec ist da auch von "Type Pattern Matching" die Rede. Ein Hinweis darauf, daß es sich hier nur um die Spitze eines
neuen Konzept-Eisbergs handelt. in Java 21 sieht man denn auch, wie das pattern matching das switch-Konstrukt so richtig aufzumischen vermag.

Bis dahin nehmen wir aber auf jeden Fall die Ein-Zeilen-Ersparnis gerne mit.

Keywords

2023-10-21T14:11:56Z

Ullrich:

[[Category:Java]]
__TOC__
== Was ist ein Keyword? ==
Unter einem Keyword vesteht man in einer Programmiersprache eine Zeichenfolge, die nur mit ganz bestimmter Bedeutung eingesetzt werden darf.
So darf das {{java|if}} ausschließlich verwendet werden um ein Konstrukt zur bedingten Ausführung einzuleiten; nicht aber als Bezeichner,
auch nicht als Teil eines package-Namens.

== Java Keywords ==
Mit Java 5 kam {{java|enum}} als 50tes Keyword hinzu:
abstract continue for new switch
assert default if package synchronized
boolean do goto private this
break double implements protected throw
byte else import public throws
case enum instanceof return transient
catch extends int short try
char final interface static void
class finally long strictfp volatile
const float native super while
In Java 9 kam mit dem einzelnen Underscore {{java|_}} das 51te und bislang letzte Keyword hinzu.

Der Grund für die sparsame Einführung neuer Keywords liegt an den unvermeidlichen Kompilier-Fehlern die beim Update entstehen,
wenn das -- bis dahin erlaubte -- Keyword bona fide verwendet wurde. Das ist durchaus problematisch, da die gestörte Abwärts-Komaptibilität
zu erhöhtem Aufwand und zu Verzögerungen beim Update führt.

Da aber eine strukturelle Spracherweiterung nur möglich ist, wenn neue Konstrukte eindeutig identifzierbar sind,
wurde ein alternativer Weg gefunden der die Abwärts-Kompatibilität nicht gefährdet.

== Contextual Keywords ==
Die Sequenz {{java|var}} wurde in Java 11 eingeführt um Varaiblen deklarieren zu können, deren Typ der Compiler aus dem Kontext bestimmt.
So definiert etwa der Ausdruck
{{java|code=
var x = "fünf";
}}
eine Variable mit dem Bezeichner {{java|x}} und dem Typ {{java|String}}.

Im Gegensazu zu den Keywords kann {{java|var}} aber weiterhin als Bezeichner genutzt werden. Zumindest der Compiler hat nichts gegen diese Deklaration:
{{java|code=
class Var {
static int var = 5;
{
var var = Var.var;
}
}
}}
Einzige Einschränkung ist, daß {{java|var}} nicht als Typ-Identifier erlaubt ist, was aber nicht geschieht wenn sich der Coder an die "Sun"-Code-Convention hält.

Mit Java 9 wurden die Sequenzen
open module requires transitive exports
opens to uses provides with
im Rahmen von Project "Jigsaw" eingeführt, das neue Java-Modul-Konzept. Die Spec bezeichnet sie als ''Restricted Keywords''.

Erst mit Java 17 wurde in der Java-Spec dafür der Begriff ''Contextual Keyword'' geprägt. Java 17 führten die folgenden sequenzen ein:
permits sealed non-sealed record yield
Mit Ausnahme von {{java|non-sealed}} sind alle Contextual Keywords als Bezeichner -- etwa für Variablen -- verwendbar.

== Ungenutzte Keywords ==
In der Liste der echten Keywords fallen einige auf, die in der normalen Programmierung nicht auftauchen:

'''const''' und '''goto''' wurden in der ersten Java-Spezifikation definiert, aber niemals mit einer Semantik versehen.
Sie können nicht verwendet werden und würden auch nichts tun wenn man es könnte.

'''_''' (der Underscore) wurde präventiv eingeführt, hat auch in Java 21 noch keine Bedeutung erhalten.
Er wird vermutlich im Zusammenhang mit dem type pattern matching einmal Bedeutung erhalten.

== Nicht-Keywords ==
Obwohl man das vermuten könnte, sind die Sequenzen {{java|true}}, {{java|false}} und {{java|null}} ''keine'' Keywords -- auch keine Kontext-Keywords.
Tatsächlich handelt sich bei allen drei um Literale, also Sequenzen die Konstanten definieren.

Dadurch verhalten sich die drei ähnlich wie Keywords, sie können nicht als Bezeichner verwendet werden, auch nicht als Teil eines Package-Bezeichners.

Keywords

2023-10-19T19:10:28Z

Ullrich:

[[Category:Java]]
Unter einem Keyword vesteht man eine Zeichenfolge, die in Java nur mit ganz bestimmter Bedeutung eingesetzt werden darf.
So darf das {{java|if}} ausschließlich verwendet werden um ein Konstrukt zur Bedingten Ausführung einzuleiten.
Nicht aber als bezeichner, auch nicht als Teil eines package-Namens.

Mit Java 5 kam {{java|enum}} als 50tes keyword hinzu:
abstract continue for new switch
assert default if package synchronized
boolean do goto private this
break double implements protected throw
byte else import public throws
case enum instanceof return transient
catch extends int short try
char final interface static void
class finally long strictfp volatile
const float native super while
Java 9 brachte mit dem einzelnen Underscore {{java|_}} das 51te und bislang letzte keyword hinzu.

Der Grund für die sparsame Einführung neuer keywords liegt an der unvermeidlichen Kompilier-Fehlern die beim Update entstehen,
wenn das -- bis dahin erlaubte -- keyword bona fide verwendet wurde.

Da aber eine Spracherweiterung nur möglich ist, wenn neue Konstrukte eindeutig identifzierbar sind, wurde ein alternativer Weg gefunden.

Die Sequenz {{java|var}} wurde in Java 11 eingeführt um Varaiblen deklarieren zu können, deren Typ der Compiler aus dem Kontext bestimmt.
So definiert der Ausdruck
{{java|code=
var x = "fünf";
}}
die Variable ''x'' mit dem Typ ''String''.

{{java|var}} kann aber weiterhin als Bezeichner genutzt werden. Zumindest der Compiler hat nichts gegen diese Deklaration:
{{java|code=
class Var {
static int var = 5;
{
var var = Var.var;
}
}
}}
Als Typ-Identifier hingegen ist "var" nicht erlaubt.

Mit Java 17 wurde in der Java-Spec ein neuer Begriff geprägt: das Contextual Keyword. Die Spec listet 16 solcher Sequenzen auf:
exports opens requires uses
module permits sealed var
non-sealed provides to with
open record transitive yield
Mit Ausnahme von {{java|non-sealed}} sind die contextual keywords als Bezeichner -- etwa für Varaiblen oder Klassen -- verwendbar.

Die Sequenzen {{java|true}}, {{java|false}} und {{java|null}} sind im übrigen ''keine'' keywords -- auch keine Kontext-Keywords --
sondern Literale, also Bezeichner für Konstanten.