Intro: Versionskontrolle in der Softwareentwicklung

Typische Probleme bei SW-Entwicklung

• Was hat wer wann (und wo) geändert? Und warum?
• Ich brauche den Stand von gestern/letzter Woche/...
• Ich will schnell mal eine neue Idee ausprobieren ...
• Ich arbeite an mehreren Rechnern (Synchronisation)
• Wir müssen gemeinsam an der gleichen Codebasis arbeiten.
• Wir arbeiten am Release v42, aber Kunde braucht schnell einen Fix für v40

Folgen SW-Entwicklung ohne Versionsverwaltung

• Filesystem müllt voll mit manuell versionierten Dateien/Sicherungen ala file_20120507_version2_cagi.txt
• Ordner/Projekte müssen dupliziert werden für neue Ideen
• Code müllt voll mit auskommentierten Zeilen ("Könnte ja noch gebraucht werden")
• Unklar, wann welche Änderung von wem warum eingeführt wurde
• Unbeabsichtigtes Überschreiben mit älteren Versionen beim Upload in gemeinsamen Filesharing-Bereich

Prinzip Versionsverwaltung

Varianten: Zentrale Versionsverwaltung (Beispiel SVN)

Es gibt ein zentrales Repository (typischerweise auf einem Server), von dem die Developer einen bestimmten Versionsstand "auschecken" (sich lokal kopieren) und in welches sie Änderungen wieder zurück "pushen".

Zur Abfrage der Historie und zum Veröffentlichen von Änderungen benötigt man entsprechend immer eine Verbindung zum Server.

Varianten: Verteilte Versionsverwaltung (Beispiel Git)

In diesem Szenario hat jeder Developer nicht nur die Workingcopy, sondern auch noch eine Kopie des Repositories. Zusätzlich kann es einen oder mehrere Server geben, auf denen dann nur das Repository vorgehalten wird, d.h. dort gibt es normalerweise keine Workingcopy. Damit kann unabhängig voneinander gearbeitet werden.

Allerdings besteht nun die Herausforderung, die geänderten Repositories miteinander abzugleichen. Das kann zwischen dem lokalen Rechner und dem Server passieren, aber auch zwischen zwei "normalen" Rechnern (also zwischen den Developern).

Hinweis: GitHub ain't no Git! Git ist eine Technologie zur Versionsverwaltung. Es gibt verschiedene Implementierungen und Plugins für IDEs und Editoren. GitHub ist dagegen ein Dienstleister, wo man Git-Repositories ablegen kann und auf diese mit Git (von der Konsole oder aus der IDE) zugreifen kann. Darüber hinaus bietet der Service aber zusätzliche Features an, beispielsweise ein Issue-Management oder sogenannte Pull-Requests. Dies hat aber zunächst mit Git nichts zu tun. Weitere populäre Anbieter sind beispielsweise Bitbucket oder Gitlab oder Gitea, wobei einige auch selbst gehostet werden können.

Versionsverwaltung mit Git: Typische Arbeitsschritte

1. Repository anlegen (oder clonen)

2. Dateien neu erstellen (und löschen, umbenennen, verschieben)

3. Änderungen einpflegen ("committen")

4. Änderungen und Logs betrachten

5. Änderungen rückgängig machen

6. Projektstand markieren ("taggen")

7. Entwicklungszweige anlegen ("branchen")

8. Entwicklungszweige zusammenführen ("mergen")

9. Änderungen verteilen (verteiltes Arbeiten, Workflows)

(Globale) Konfiguration

Minimum:

• git config --global user.name <name>
• git config --global user.email <email>

Diese Konfiguration muss man nur einmal machen.

Wenn man den Schalter --global weglässt, gelten die Einstellungen nur für das aktuelle Projekt/Repo.

Zumindest Namen und EMail-Adresse muss man setzen, da Git diese Information beim Anlegen der Commits speichert (== benötigt!).

Aliase:

• git config --global alias.ci commit
• git config --global alias.co checkout
• git config --global alias.br branch
• git config --global alias.st status
• git config --global alias.ll 'log --all --graph --decorate --oneline'

Zusätzlich kann man weitere Einstellungen vornehmen, etwa auf bunte Ausgabe umschalten: git config --global color.ui auto oder Abkürzungen (Aliase) für Befehle definieren: git config --global alias.ll 'log --all --oneline --graph --decorate' ...

Git (und auch GitHub) hat kürzlich den Namen des Default-Branches von master auf main geändert. Dies kann man in Git ebenfalls selbst einstellen: git config --global init.defaultBranch <name>.

Anschauen kann man sich die Einstellungen in der Textdatei ~/.gitconfig oder per Befehl git config --global -l.

Neues Repo anlegen

• git init

  => Erzeugt neues Repository im akt. Verzeichnis

• git clone <url>

  => Erzeugt (verlinkte) Kopie des Repos unter <url>

Wrap-Up

• Git: Versionsmanagement mit dezentralen Repositories
• Anlegen eines lokalen Repos mit git init
• Clonen eines existierenden Repos mit git clone <url>

Basics der Versionsverwaltung mit Git (lokale Repos)

Versionsverwaltung mit Git: Typische Arbeitsschritte

1. Repository anlegen (oder clonen)

2. Dateien neu erstellen (und löschen, umbenennen, verschieben)

3. Änderungen einpflegen ("committen")

4. Änderungen und Logs betrachten

5. Änderungen rückgängig machen

6. Projektstand markieren ("taggen")

7. Entwicklungszweige anlegen ("branchen")

8. Entwicklungszweige zusammenführen ("mergen")

9. Änderungen verteilen (verteiltes Arbeiten, Workflows)

Dateien unter Versionskontrolle stellen

1. git add . (oder git add <file>)

   => Stellt alle Dateien (bzw. die Datei <file>) im aktuellen Verzeichnis unter Versionskontrolle

2. git commit

   => Fügt die Dateien dem Repository hinzu

Abfrage mit git status

Änderungen einpflegen

• Abfrage mit: git status
• "Staging" von modifizierten Dateien: git add <file>
• Committen der Änderungen im Stage: git commit

Anmerkung: Alternativ auch mit git commit -m "Kommentar", um das Öffnen des Editors zu vermeiden ... geht einfach schneller ;)

Das "staging area" stellt eine Art Zwischenebene zwischen Working Copy und Repository dar: Die Änderungen sind temporär "gesichert", aber noch nicht endgültig im Repository eingepflegt ("committed").

Man kann den Stage dazu nutzen, um Änderungen an einzelnen Dateien zu sammeln und diese dann (in einem Commit) gemeinsam einzuchecken.

Man kann den Stage in der Wirkung umgehen, indem man alle in der Working Copy vorliegenden Änderungen per git commit -a -m "Kommentar" eincheckt. Der Schalter "-a" nimmt alle vorliegenden Änderungen an bereits versionierten Dateien, fügt diese dem Stage hinzu und führt dann den Commit durch. Das ist das von SVN bekannte Verhalten. Achtung: Nicht versionierte Dateien bleiben dabei außen vor!

Letzten Commit ergänzen

• git commit --amend -m "Eigentlich wollte ich das so sagen"

  Wenn keine Änderungen im Stage sind, wird so die letzte Commit-Message geändert.

• git add <file>; git commit --amend

  Damit können vergessene Änderungen an der Datei <file> zusätzlich im letzten Commit aufgezeichnet werden.

  In beiden Fällen ändert sich die Commit-ID!

Weitere Datei-Operationen: hinzufügen, umbenennen, löschen

• Neue (unversionierte) Dateien und Änderungen an versionierten Dateien zum Staging hinzufügen: git add <file>
• Löschen von Dateien (Repo+Workingcopy): git rm <file>
• Löschen von Dateien (nur Repo): git rm --cached <file>
• Verschieben/Umbenennen: git mv <fileAlt> <fileNeu>

Aus Sicht von Git sind zunächst alle Dateien "untracked", d.h. stehen nicht unter Versionskontrolle.

Mit git add <file> (und git commit) werden Dateien in den Index (den Staging-Bereich, d.h. nach dem Commit letztlich in das Repository) aufgenommen. Danach stehen sie unter "Beobachtung" (Versionskontrolle). So lange, wie eine Datei identisch zur Version im Repository ist, gilt sie als unverändert ("unmodified"). Eine Änderung führt entsprechend zum Zustand "modified", und ein git add <file> speichert die Änderungen im Stage. Ein Commit überführt die im Stage vorgemerkte Änderung in das Repo, d.h. die Datei gilt wieder als "unmodified".

Wenn eine Datei nicht weiter versioniert werden soll, kann sie aus dem Repo entfernt werden. Dies kann mit git rm <file> geschehen, wobei die Datei auch aus der Workingcopy gelöscht wird. Wenn die Datei erhalten bleiben soll, aber nicht versioniert werden soll (also als "untracked" markiert werden soll), dann muss sie mit git rm --cached <file> aus der Versionskontrolle gelöscht werden. Achtung: Die Datei ist dann nur ab dem aktuellen Commit gelöscht, d.h. frühere Revisionen enthalten die Datei noch!

Wenn eine Datei umbenannt werden soll, geht das mit git mv <fileAlt> <fileNeu>. Letztlich ist dies nur eine Abkürzung für die Folge git rm --cached <fileAlt>, manuelles Umbenennen der Datei in der Workingcopy und git add <fileNeu>.

Commits betrachten

• Liste aller Commits: git log

  • git log -<n> oder git log --since="3 days ago" Meldungen eingrenzen ...
  • git log --stat Statistik ...
  • git log --author="pattern" Commits eines Autors
  • git log <file> Änderungen einer Datei

• Inhalt eines Commits: git show

Änderungen und Logs betrachten

• git diff [<file>]

  Änderungen zwischen Workingcopy und letztem Commit (ohne Stage)

  Das "staging area" wird beim Diff von Git behandelt, als wären die dort hinzugefügten Änderungen bereits eingecheckt (genauer: als letzter Commit im aktuellen Branch im Repo vorhanden). D.h. wenn Änderungen in einer Datei mittels git add <datei> dem Stage hinzugefügt wurden, zeigt git diff <datei> keine Änderungen an!

• git diff commitA commitB

  Änderungen zwischen Commits

• Blame: git blame <file>

  Wer hat was wann gemacht?

Dateien ignorieren: .gitignore

• Nicht alle Dateien gehören ins Repo:
  • generierte Dateien: .class
  • temporäre Dateien
• Datei .gitignore anlegen und committen
  • Wirkt auch für Unterordner
  • Inhalt: Reguläre Ausdrücke für zu ignorierende Dateien und Ordner

    # Compiled source #
    *.class
    *.o
    *.so

    # Packages #
    *.zip

    # All directories and files in a directory #
    bin/**/*

Zeitmaschine

• Änderungen in Workingcopy rückgängig machen

  • Änderungen nicht in Stage: git checkout <file> oder git restore <file>
  • Änderungen in Stage: git reset HEAD <file> oder git restore --staged <file>

  => Hinweise von git status beachten!

• Datei aus altem Stand holen:

  • git checkout <commit> <file>, oder
  • git restore --source <commit> <file>

• Commit verwerfen, Geschichte neu: git revert <commit>

Hinweis: In den neueren Versionen von Git ist der Befehl git restore hinzugekommen, mit dem Änderungen rückgängig gemacht werden können. Der bisherige Befehl git checkout steht immer noch zur Verfügung und bietet über git restore hinaus weitere Anwendungsmöglichkeiten.

• Stempel (Tag) vergeben: git tag <tagname> <commit>
• Tags anzeigen: git tag und git show <tagname>

Wann und wie committen?

Typische Regeln:

• Kleinere "Häppchen" einchecken: ein Feature oder Task (das nennt man auch atomic commit: das kleinste Set an Änderungen, die gemeinsam Sinn machen und die ggf. gemeinsam zurückgesetzt werden können)
• Logisch zusammenhängende Änderungen gemeinsam einchecken
• Projekt muss nach Commit compilierbar sein
• Projekt sollte nach Commit lauffähig sein

Ein Commit sollte in sich geschlossen sein, d.h. die kleinste Menge an Änderungen enthalten, die gemeinsam einen Sinn ergeben und die (bei Bedarf) gemeinsam zurückgesetzt oder verschoben werden können. Das nennt man auch atomic commit.

Wenn Sie versuchen, die Änderungen in Ihrem Commit zu beschreiben (siehe nächste Folie "Commit-Messages"), dann werden Sie einen atomic commit mit einem kurzen Satz (natürlich im Imperativ!) beschreiben können. Wenn Sie mehr Text brauchen, haben Sie wahrscheinlich keinen atomic commit mehr vor sich.

Lesen Sie dazu auch How atomic Git commits dramatically increased my productivity - and will increase yours too.

Schreiben von Commit-Messages: WARUM?!

Schauen Sie sich einmal einen Screenshot eines git log --oneline 61e48f0..e2c8076 im Dungeon-CampusMinden/Dungeon an:

Nun stellen Sie sich vor, Sie sind auf der Suche nach Informationen, suchen einen bestimmten Commit oder wollen eine bestimmte Änderung finden ...

Wenn man das genauer analysiert, dann stören bestimmte Dinge:

• Mischung aus Deutsch und Englisch
• "Vor-sich-hin-Murmeln": "Layer system 5"
• Teileweise werden Tags genutzt wie [BUG], aber nicht durchgängig
• Mischung zwischen verschiedenen Formen: "Repo umbenennen", "Benenne Repo um", "Repo umbenannt"
• Unterschiedliche Groß- und Kleinschreibung
• Sehr unterschiedlich lange Zeilen/Kommentare

Das Beachten einheitlicher Regeln ist enorm wichtig!

Leider sagt sich das so leicht - in der Praxis macht man es dann doch schnell wieder unsauber. Dennoch, auch im Dungeon-Repo gibt es einen positiven Trend (git log --oneline 8039d6c..7f49e89):

Typische Regeln und Konventionen tauchen überall auf, beispielsweise in [Chacon2014] oder bei Tim Pope (siehe nächstes Beispiel) oder bei "How to Write a Git Commit Message".

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary.  Wrap it to about
72 characters or so.  In some contexts, the first line is treated
as the subject of an email and the rest of the text as the body.
The blank line separating the summary from the body is critical
(unless you omit the body entirely); tools like rebase can get
confused if you run the two together.

Further paragraphs come after blank lines.

 - Bullet points are okay, too
 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

Quelle: "A Note About Git Commit Messages" by Tim Pope on tbaggery.com

Denken Sie sich die Commit-Message als E-Mail an einen zukünftigen Entwickler, der das in fünf Jahren liest!

Vom Aufbau her hat eine E-Mail auch eine Summary und dann den eigentlichen Inhalt ... Erklären Sie das "WARUM" der Änderung! (Das "WER", "WAS", "WANN" wird bereits automatisch von Git aufgezeichnet ...)

Wrap-Up

• Änderungen einpflegen zweistufig (add, commit)
• Status der Workingcopy mit status ansehen
• Logmeldungen mit log ansehen
• Änderungen auf einem File mit diff bzw. blame ansehen
• Projektstand markieren mit tag
• Ignorieren von Dateien/Ordnern: Datei .gitignore

Git Branches: Features unabhängig entwickeln und mit Git verwalten

Neues Feature entwickeln/ausprobieren

A---B---C  master

• Bisher nur lineare Entwicklung: Commits bauen aufeinander auf (lineare Folge von Commits)
• master ist der (Default-) Hauptentwicklungszweig
  • Pointer auf letzten Commit
  • Default-Name: "master" (muss aber nicht so sein bzw. kann geändert werden)

Anmerkung: Git und auch Github haben den Namen für den Default-Branch von master auf maingeändert. Der Name an sich ist aber für Git bedeutungslos und kann mittels git config --global init.defaultBranch <name> geändert werden. In Github hat der Default-Branch eine gewisse Bedeutung, beispielsweise ist der Default-Branch das automatische Ziel beim Anlegen von Pull-Requests. In Github kann man den Default-Namen global in den User-Einstellungen (Abschnitt "Repositories") und für jedes einzelne Repository in den Repo-Einstellungen (Abschnitt "Branches") ändern.

Entwicklung des neuen Features soll stabilen master-Branch nicht beeinflussen => Eigenen Entwicklungszweig für die Entwicklung des Features anlegen:

1. Neuen Branch erstellen: git branch wuppie
2. Neuen Branch auschecken: git checkout wuppie oder git switch wuppie

Alternativ: git checkout -b wuppie oder git switch -c wuppie (neuer Branch und auschecken in einem Schritt)

A---B---C  master, wuppie

Startpunkt: prinzipiell beliebig (jeder Commit in der Historie möglich).

Die gezeigten Beispiel zweigen den neuen Branch direkt vom aktuell ausgecheckten Commit/Branch ab. Also aufpassen, was gerade in der Workingcopy los ist!

Alternativ nutzen Sie die Langform: git branch wuppie master (mit master als Startpunkt; hier kann jeder beliebige Branch, Tag oder Commit genutzt werden).

Nach Anlegen des neuen Branches zeigen beide Pointer auf den selben Commit.

Anmerkung: In neueren Git-Versionen wurde der Befehl "switch" eingeführt, mit dem Sie in der Workingcopy auf einen anderen Branch wechseln können. Der bisherige Befehl "checkout" funktioniert aber weiterhin.

Arbeiten im Entwicklungszweig ...

          D  wuppie
         /
A---B---C  master

• Entwicklung des neuen Features erfolgt im eigenen Branch: beeinflusst den stabilen master-Branch nicht
• Wenn in der Workingcopy der Feature-Branch ausgecheckt ist, gehen die Commits in den Feature-Branch; der master bleibt auf dem alten Stand
• Wenn der master ausgecheckt wäre, würden die Änderungen in den master gehen, d.h. der master würde sich ab Commit C parallel zu wuppie entwickeln

Problem: Fehler im ausgelieferten Produkt

          D  wuppie
         /
A---B---C  master

Fix für master nötig:

1. git checkout master
2. git checkout -b fix
3. Änderungen in fix vornehmen ...

Das führt zu dieser Situation:

          D  wuppie
         /
A---B---C  master
         \
          E  fix

git checkout <branchname> holt den aktuellen Stand des jeweiligen Branches in die Workingcopy. (Das geht in neueren Git-Versionen auch mit git switch <branchname>.)

Man kann weitere Branches anlegen, d.h. hier im Beispiel ein neuer Feature-Branch fix, der auf dem master basiert. Analog könnte man auch Branches auf der Basis von wuppie anlegen ...

Fix ist stabil: Integration in master

          D  wuppie
         /
A---B---C  master
         \
          E  fix

1. git checkout master
2. git merge fix => fast forward von master
3. git branch -d fix

Der letzte Schritt entfernt den Branch fix.

          D  wuppie
         /
A---B---C---E  master

• Allgemein: git merge <branchname> führt die Änderungen im angegebenen Branch <branchname> in den aktuell in der Workingcopy ausgecheckten Branch ein. Daraus resultiert für den aktuell ausgecheckten Branch ein neuer Commit, der Branch <branchname> bleibt dagegen auf seinem bisherigen Stand.

  Beispiel:

  • Die Workingcopy ist auf A
  • git merge B führt A und B zusammen: B wird in A gemergt
  • Wichtig: Der Merge-Commit (sofern nötig) findet hierbei in A statt!

  In der Abbildung ist A der master und B der fix.

• Nach dem Merge existieren beide Branches weiter (sofern sie nicht explizit gelöscht werden)

• Hier im Beispiel findet ein sogenannter "Fast forward" statt.

  "Fast forward" ist ein günstiger Spezialfall beim Merge: Beide Branches liegen in einer direkten Kette, d.h. der Zielbranch kann einfach "weitergeschaltet" werden. Ein Merge-Commit ist in diesem Fall nicht notwendig und wird auch nicht angelegt.

Feature weiter entwickeln ...

          D---F  wuppie
         /
A---B---C---E  master

1. git switch wuppie
2. Weitere Änderungen im Branch wuppie ...

git switch <branchname> holt den aktuellen Stand des jeweiligen Branches in die Workingcopy. Man kann also jederzeit in der Workingcopy die Branches wechseln und entsprechend weiterarbeiten.

Hinweis: Während der neue git switch-Befehl nur Branches umschalten kann, funktioniert git checkout sowohl mit Branchnamen und Dateinamen - damit kann man also auch eine andere Version einer Datei in der Workingcopy "auschecken". Falls gleiche Branch- und Dateinamen existieren, muss man für das Auschecken einer Datei noch "--" nutzen: git checkout -- <dateiname>.

Feature ist stabil: Integration in master

          D---F  wuppie                            D---F  wuppie
         /                     =>                 /     \
A---B---C---E  master                    A---B---C---E---G  master

1. git checkout master
2. git merge wuppie => Kein fast forward möglich: Git sucht nach gemeinsamen Vorgänger

Hier im Beispiel ist der Standardfall beim Mergen dargestellt: Die beiden Branches liegen nicht in einer direkten Kette von Commits, d.h. hier wurde parallel weitergearbeitet.

Git sucht in diesem Fall nach dem gemeinsamen Vorgänger beider Branches und führt die jeweiligen Änderungen (Differenzen) seit diesem Vorgänger in einem Merge-Commit zusammen.

Im master entsteht ein neuer Commit, da kein fast forward beim Zusammenführen der Branches möglich!

Anmerkung: git checkout wuppie; git merge master würde den master in den wuppie mergen, d.h. der Merge-Commit wäre dann in wuppie.

Beachten Sie dabei die "Merge-Richtung":

• Die Workingcopy ist auf A
• git merge B führt A und B zusammen: B wird in A gemergt
• Wichtig: Der Merge-Commit (sofern nötig) findet hierbei in A statt!

In der Abbildung ist A der master und B der wuppie.

Achtung: Richtung beachten! git checkout A; git merge B führt beide Branches zusammen, genauer: führt die Änderungen von B in A ein, d.h. der entsprechende Merge-Commit ist in A!

Konflikte beim Mergen

(Parallele) Änderungen an selber Stelle => Merge-Konflikte

$ git merge wuppie
Auto-merging hero.java
CONFLICT (content): Merge conflict in hero.java
Automatic merge failed; fix conflicts and then commit the result.

Git fügt Konflikt-Marker in die Datei ein:

<<<<<<< HEAD:hero.java
public void getActiveAnimation() {
    return null;
=======
public Animation getActiveAnimation() {
    return this.idleAnimation;
>>>>>>> wuppie:hero.java

• Der Teil mit HEAD ist aus dem aktuellen Branch in der Workingcopy
• Der Teil aus dem zu mergenden Branch ist unter wuppie notiert
• Das ======= trennt beide Bereiche

Merge-Konflikte auflösen

Manuelles Editieren nötig (Auflösung des Konflikts):

1. Entfernen der Marker
2. Hinzufügen der Datei zum Index
3. Analog für restliche Dateien mit Konflikt
4. Commit zum Abschließen des Merge-Vorgangs

Alternativ: Nutzung graphischer Oberflächen mittels git mergetool

Rebasen: Verschieben von Branches

          D---F  wuppie                            D---F  wuppie
         /                     =>                 /     \
A---B---C---E  master                    A---B---C---E---G  master

Bisher haben wir Branches durch Mergen zusammengeführt. Dabei entsteht in der Regel ein extra Merge-Commit (im Beispiel G), außer es handelt sich um ein fast forward. Außerdem erkennt man in der Historie sehr gut, dass hier in einem separaten Branch gearbeitet wurde, der irgendwann in den master gemergt wurde.

Leider wird dieses Vorgehen in großen Projekten recht schnell sehr unübersichtlich. Außerdem werden Merges in der Regeln nur von besonders berechtigten Personen (Manager) durchgeführt, die im Falle von Merge-Konflikten diese dann selbst auflösen müssten (ohne aber die fachliche Befähigung zu haben). Hier greift man dann häufig zur Alternative Rebase. Dabei wird der Ursprung eines Branches auf einen bestimmten Commit verschoben. Im Anschluss ist dann ein Merge mit fast forward, also ohne die typischen rautenförmigen Ketten in der Historie und ohne extra Merge-Commit möglich. Dies kann aber auch als Nachteil gesehen werden, da man in der Historie den früheren Branch nicht mehr erkennt! Ein weiterer schwerwiegender Nachteil ist, dass alle Commits im verschobenen Branch umgeschrieben werden und damit neue Commit-IDs bekommen. Das verursacht bei der Zusammenarbeit in Projekten massive Probleme! Als Vorteil gilt, dass man mögliche Merge-Konflikte bereits beim Rebasen auflösen muss, d.h. hier muss derjenige, der den Merge "beantragt", durch einen vorherigen Rebase den konfliktfreien Merge sicherstellen. Mehr dazu in “Branching-Strategien” und “Workflows”.

git rebase master wuppie

              D'---F'  wuppie
             /
A---B---C---E  master

Nach dem Rebase von wuppie auf master sieht es so aus, als ob der Branch wuppie eben erst vom master abgezweigt wurde. Damit ist dann ein fast forward Merge von wuppie in den master möglich, d.h. es gibt keine Raute und auch keinen extra Merge-Commit (hier nicht gezeigt).

Man beachte aber die Änderung der Commit-IDs von wuppie: Aus D wird D'! (Datum, Ersteller und Message bleiben aber erhalten.)

Don't lose your HEAD

• Branches sind wie Zeiger auf letzten Stand (Commit) eines Zweiges

• HEAD: Spezieller Pointer

  • Zeigt auf den aktuellen Branch der Workingcopy

• Früheren Commit auschecken (ohne Branch): "headless state"

  • Workingcopy ist auf früherem Commit

  • Kein Branch => Änderungen gehen verloren!

    Eventuelle Änderungen würden ganz normal als Commits auf dem HEAD-Branch aufgezeichnet. Sobald man aber einen anderen Branch auscheckt, wird der HEAD auf diesen anderen Branch gesetzt, so dass die eben gemachten Commits "in der Luft hängen". Sofern man die SHA's kennt, kommt man noch auf die Commits zurück. Allerdings laufen von Zeit zu Zeit interne Aufräum-Aktionen, so dass die Chance gut steht, dass die "kopflosen" Commits irgendwann tatsächlich verschwinden.

Wrap-Up

• Anlegen von Branches mit git branch
• Umschalten der Workingcopy auf anderen Branch: git checkout oder git switch
• Mergen von Branches und Auflösen von Konflikten: git merge
• Verschieben von Branches mit git rebase

Branching-Strategien mit Git

Nutzung von Git in Projekten: Verteiltes Git (und Workflows)

Git ermöglicht ein einfaches und schnelles Branchen. Dies kann man mit entsprechenden Branching-Strategien sinnvoll für die SW-Entwicklung einsetzen.

Im Folgenden sollen also die Frage betrachtet werden: Wie setze ich Branches sinnvoll ein?

Umgang mit Branches: Themen-Branches

                I---J---K  wuppieV1
               /
          D---F  wuppie
         /
A---B---C---E  master
             \
              G---H  test

Branchen ist in Git sehr einfach und schnell. Deshalb wird (gerade auch im Vergleich mit SVN) gern und viel gebrancht.

Ein häufiges anzutreffendes Modell ist dabei die Nutzung von Themen-Branches: Man hat einen Hauptzweig (master). Wann immer eine neue Idee oder ein Baustein unabhängig entwickelt werden soll/kann, wird ein entsprechender Themen-Branch aufgemacht. Dabei handelt es sich normalerweise um kleine Einheiten!

Themenbranches haben in der Regel eine kurze Lebensdauer: Wenn die Entwicklung abgeschlossen ist, wird die Idee bzw. der Baustein in den Hauptzweig integriert und der Themenbranch gelöscht.

• Vorteil: Die Entwicklung im Themenbranch ist in sich gekapselt und stört nicht die Entwicklung in anderen Branches (und diese stören umgekehrt nicht die Entwicklung im Themenbranch).

• Nachteil:

  • Mangelnder Überblick durch viele Branches
  • Ursprung der Themenbranches muss überlegt gewählt werden, d.h. alle dort benötigten Features müssen zu dem Zeitpunkt im Hauptzweig vorhanden sein

Umgang mit Branches: Langlaufende Branches

A---B---D  master
     \
      C---E---I  develop
           \
            F---G---H  topic

Häufig findet man in (größeren) Projekten Branches, die über die gesamte Lebensdauer des Projekts existieren, sogenannte "langlaufende Branches".

Normalerweise gibt es einen Branch, in dem stets der stabile Stand des Projekts enthalten ist. Dies ist häufig der master. In diesem Branch gibt es nur sehr wenige Commits: normalerweise nur Merges aus dem develop-Branch (etwa bei Fertigstellung einer Release-Version) und ggf. Fehlerbehebungen.

Die aktive Entwicklung findet in einem separaten Branch statt: develop. Hier nutzt man zusätzlich Themen-Branches für die Entwicklung einzelner Features, die nach Fertigstellung in den develop gemergt werden.

Kleinere Projekte kommen meist mit den zwei langlaufenden Branches in der obigen Darstellung aus. Bei größeren Projekten finden sich häufig noch etliche weitere langlaufende Branches, beispielsweise "Proposed Updates" etc. beim Linux-Kernel.

• Vorteile:
  • Mehr Struktur im Projekt durch in ihrer Semantik wohldefinierte Branches
  • Durch weniger Commits pro Branch lässt sich die Historie leichter verfolgen (u.a. auch aus bestimmter Rollen-Perspektive: Entwickler, Manager, ...)
• Nachteile: Bestimmte "ausgezeichnete" Branches; zusätzliche Regeln zum Umgang mit diesen beachten

Komplexe Branching-Strategie: Git-Flow

A---B---------------------G---J1  master
     \                   / \ /
      \                 /   X  fix
       \               /     \
        C-------------F----I--J2  develop
         \           / \  /
          \         /   H1  featureB
           \       /
            D1----D2  featureA
             \
              E1---E2---E3---E4---E5  featureC

Das Git-Flow-Modell von Vincent Driessen (nvie.com/posts/a-successful-git-branching-model) zeigt einen in der Praxis überaus bewährten Umgang mit Branches. Lesen Sie an der angegebenen Stelle nach, besser kann man die Nutzung dieses eleganten Modells eigentlich nicht erklären :-)

Git-Flow: Hauptzweige master und develop

A---B-------E---------------J  master
     \     /               /
      C---D---F---G---H---I---K  develop

Bei Git-Flow gibt es zwei langlaufende Branches: Den master, der immer den stabilen Stand enthält und in den nie ein direkter Commit gemacht wird, sowie den develop, wo letztlich (ggf. über Themenbranches) die eigentliche Entwicklung stattfindet.

Änderungen werden zunächst im develop erstellt und getestet. Wenn die Features stabil sind, erfolgt ein Merge von develop in den master. Hier kann noch der Umweg über einen release-Branch genommen werden: Als "Feature-Freeze" wird vom develop ein release-Branch abgezweigt. Darin wird das Release dann aufpoliert, d.h. es erfolgen nur noch kleinere Korrekturen und Änderungen, aber keine echte Entwicklungsarbeit mehr. Nach Fertigstellung wird der release dann sowohl in den master als auch develop gemergt.

Git-Flow: Weitere Branches als Themen-Branches

A---B---------------------I-------------K  master
     \                   /             /
      C------------F----H-------------J---L  develop
       \          / \  /             /
        \        /   G1  featureB   /
         \      /                  /
          D1---D2  featureA       /
           \                     /
            E1---E2---E3---E4---E5  featureC

Für die Entwicklung eigenständiger Features bietet es sich auch im Git-Flow an, vom develop entsprechende Themenbranches abzuzweigen und darin jeweils isoliert die Features zu entwickeln. Wenn diese Arbeiten eine gewisse Reife haben, werden die Featurebranches in den develop integriert.

Git-Flow: Merging-Detail

---C--------E  develop
    \      /                 git merge --no-ff
     D1---D2  featureA

vs.

---C---D1---D2  develop      git merge

Wenn beim Mergen ein "fast forward" möglich ist, würde Git beim Mergen eines (Feature-) Branches in den develop (oder allgemein in einen anderen Branch) keinen separaten Commit erzeugen (Situation rechts in der Abbildung).

Damit erscheint der develop-Branch wie eine lineare Folge von Commits. In manchen Projekten wird dies bevorzugt, weil die Historie sehr übersichtlich aussieht.

Allerdings verliert man die Information, dass hier ein Feature entwickelt wurde und wann es in den develop integriert wurde (linke Seite in obiger Abbildung). Häufig wird deshalb ein extra Merge-Commit mit git merge --no-ff <branch> (extra Schalter "--no-ff") erzwungen, obwohl ein "fast forward" möglich wäre.

Anmerkung: Man kann natürlich auch über Konventionen in den Commit-Kommentaren eine gewisse Übersichtlichkeit erzwingen. Beispielsweise könnte man vereinbaren, dass alle Commit-Kommentare zu einem Feature "A" mit "feature a:" starten müssen.

Git-Flow: Umgang mit Fehlerbehebung

A---B---D--------F1  master
     \   \      /
      \   E1---E2  fix
       \        \
        C1-------F2  develop

Wenn im stabilen Branch (also dem master) ein Problem bekannt wird, darf man es nicht einfach im master fixen. Stattdessen wird ein extra Branch vom master abgezweigt, in dem der Fix entwickelt wird. Nach Fertigstellung wird dieser Branch sowohl in den master als auch den develop gemergt, damit auch im Entwicklungszweig der Fehler behoben ist.

Dadurch entspricht jeder Commit im master einem Release.

Vereinfachte Braching-Strategie: GitHub Flow

A---B---C----D-----------E  master
     \   \  /           /
      \   ta1  topicA  /
       \              /
        tb1---tb2---tb3  topicB

Github verfolgt eine deutlich vereinfachte Strategie: "GitHub Flow" (vgl. "GitHub Flow" (S. Chacon) bzw. "GitHub flow" (GitHub, Inc.)).

Hier ist der stabile Stand ebenfalls immer im master. Features werden ebenso wie im Git-Flow-Modell in eigenen Feature-Branches entwickelt.

Allerdings zweigen Feature-Branches immer direkt vom master ab und werden nach dem Test auch immer dort wieder direkt integriert (es gibt also keine weiteren langlaufenden Branches wie develop oder release).

In der obigen Abbildung ist zu sehen, dass für die Entwicklung eines Features ein entsprechender Themenbranch vom master abgezweigt wird. Darin erfolgt dann die Entwicklung des Features, d.h. mehrere Commits. Das Mergen des Features in den master erfolgt dann aber nicht lokal, sondern mit einem "Pull-Request" auf dem Server: Sobald man im Feature-Branch einen "diskussionswürdigen" Stand hat, wird ein Pull-Request (PR) über die Weboberfläche aufgemacht (streng genommen gehört dies in die Kategorie “Zusammenarbeit” bzw. “Workflows”; außerdem gehört ein PR nicht zu Git selbst, sondern zum Tooling von Github). In einem PR können andere Entwickler den Code kommentieren und ergänzen. Jeder weitere Commit auf dem Themenbranch wird ebenfalls Bestandteil des Pull-Requests. Parallel laufen ggf. automatisierte Tests etc. und durch das Akzeptieren des PR in der Weboberfläche erfolgt schließlich der Merge des Feature-Branches in den master.

Diskussion: Git-Flow vs. GitHub Flow

In der Praxis zeigt sich, dass das Git-Flow-Modell besonders gut geeignet ist, wenn man tatsächlich so etwas wie "Releases" hat, die zudem nicht zu häufig auftreten.

Das GitHub-Flow-Vorgehen bietet sich an, wenn man entweder keine Releases hat oder diese sehr häufig erfolgen (typisch bei agiler Vorgehensweise). Zudem vermeidet man so, dass die Feature-Branches zu lange laufen, womit normalerweise die Wahrscheinlichkeit von Merge-Konflikten stark steigt. Achtung: Da die Feature-Branches direkt in den master, also den stabilen Produktionscode gemergt werden, ist es hier besonders wichtig, vor dem Merge entsprechende Tests durchzuführen und den Merge erst zu machen, wenn alle Tests "grün" sind.

Hier ein paar Einstiegsseiten für die Diskussion, die teilweise sehr erbittert (und mit ideologischen Zügen) geführt wird (erinnert an die Diskussionen, welche Linux-Distribution die bessere sei):

• Git-Flow-Modell von Vincent Driessen
• Kurzer Überblick über das GitHub-Flow-Modell
• Diskussion des GitHub-Flow-Modells (Github)
• Luca Mezzalira: "Git-Flow vs Github Flow"
• Scott Schacon, Autor des Pro-Git-Buchs
• Noch eine (längere) Betrachtung (Robin Daugherty)

Wrap-Up

• Einsatz von Themenbranches für die Entwicklung
• Unterschiedliche Modelle:
  • Git-Flow: umfangreiches Konzept, gut für Entwicklung mit festen Releases
  • GitHub Flow: deutlich schlankeres Konzept, passend für kontinuierliche Entwicklung ohne echte Releases

Arbeiten mit Git Remotes (dezentrale Repos)

Nutzung von Git in Projekten: Verteiltes Git (und Workflows)

Git ermöglicht eine einfaches Zusammenarbeit in verteilten Teams. Nachdem wir die verschiedenen Branching-Strategien betrachtet haben, soll im Folgenden die Frage betrachtet werden: Wie arbeite ich sinnvoll über Git mit anderen Kollegen und Teams zusammen? Welche Modelle haben sich etabliert?

Clonen kann sich lohnen ...

https://github.com/Programmiermethoden-CampusMinden/PM-Lecture

---C---D---E  master

=> git clone https://github.com/Programmiermethoden-CampusMinden/PM-Lecture

./PM-Lecture/  (lokaler Rechner)

---C---D---E  master
           ^origin/master

Git-Repository mit der URL <URL-Repo> in lokalen Ordner <directory> auschecken:

• git clone <URL-Repo> [<directory>]
• Workingcopy ist automatisch über den Namen origin mit dem remote Repo auf dem Server verbunden
• Lokaler Branch master ist mit dem remote Branch origin/master verbunden ("Tracking Branch", s.u.), der den Stand des master-Branches auf dem Server spiegelt

Für die URL sind verschiedene Protokolle möglich, beispielsweise:

• "file://" für über das Dateisystem erreichbare Repositories (ohne Server)
• "https://" für Repo auf einem Server: Authentifikation mit Username und Passwort (!)
• "git@" für Repo auf einem Server: Authentifikation mit SSH-Key (diese Variante wird im Praktikum im Zusammenspiel mit dem Gitlab-Server im SW-Labor verwendet)

Eigener und entfernter master entwickeln sich weiter ...

https://github.com/Programmiermethoden-CampusMinden/PM-Lecture

---C---D---E---F---G  master

./PM-Lecture/  (lokaler Rechner)

---C---D---E---H  master
           ^origin/master

Nach dem Auschecken liegen (in diesem Beispiel) drei master-Branches vor:

1. Der master auf dem Server,
2. der lokale master, und
3. die lokale Referenz auf den master-Branch auf dem Server: origin/master.

Der lokale master ist ein normaler Branch und kann durch Commits verändert werden.

Der master auf dem Server kann sich ebenfalls ändern, beispielsweise weil jemand anderes seine lokalen Änderungen mit dem Server abgeglichen hat (git push, s.u.).

Der Branch origin/master lässt sich nicht direkt verändern! Das ist lediglich eine lokale Referenz auf den master-Branch auf dem Server und zeigt an, welchen Stand man bei der letzten Synchronisierung hatte. D.h. erst mit dem nächsten Abgleich wird sich dieser Branch ändern (sofern sich der entsprechende Branch auf dem Server verändert hat).

Anmerkung: Dies gilt analog für alle anderen Branches. Allerdings wird nur der origin/master beim Clonen automatisch als lokaler Branch ausgecheckt.

Zur Abbildung: Während man lokal arbeitet (Commit H auf dem lokalen master), kann es passieren, dass sich auch das remote Repo ändert. Im Beispiel wurden dort die beiden Commits F und G angelegt (durch git push, s.u.).

Wichtig: Da in der Zwischenzeit das lokale Repo nicht mit dem Server abgeglichen wurde, zeigt der remote Branch origin/master immer noch auf den Commit E!

Änderungen im Remote holen und Branches zusammenführen

https://github.com/Programmiermethoden-CampusMinden/PM-Lecture

---C---D---E---F---G  master

=> git fetch origin

./PM-Lecture/  (lokaler Rechner)

---C---D---E---H  master
            \
             F---G  origin/master

Änderungen auf dem Server mit dem eigenen Repo abgleichen

Mit git fetch origin alle Änderungen holen

• Alle remote Branches werden aktualisiert und entsprechen den jeweiligen Branches auf dem Server: Im Beispiel zeigt jetzt origin/master ebenso wie der master auf dem Server auf den Commit G.
• Neue Branches auf dem Server werden ebenfalls "geholt", d.h. sie liegen nach dem Fetch als entsprechende remote Branches vor
• Auf dem Server gelöschte Branches werden nicht automatisch lokal gelöscht; dies kann man mit git fetch --prune origin automatisch erreichen

Wichtig: Es werden nur die remote Branches aktualisiert, nicht die lokalen Branches!

master-Branch nach "git fetch origin" zusammenführen

1. Mit git checkout master Workingcopy auf eigenen master umstellen
2. Mit git merge origin/master Änderungen am origin/master in eigenen master mergen
3. Mit git push origin master eigene Änderungen ins remote Repo pushen

https://github.com/Programmiermethoden-CampusMinden/PM-Lecture

---C---D---E---H---I  master
            \     /
             F---G

./PM-Lecture/  (lokaler Rechner)

---C---D---E---H---I  master
            \     /^origin/master
             F---G

Anmerkung: Schritt (2) kann man auch per git pull origin master erledigen ... Ein pull fasst fetch und merge zusammen (s.u.).

Anmerkung Statt dem merge in Schritt (2) kann man auch den lokalen master auf den aktualisierten origin/master rebasen und vermeidet damit die "Raute". Der pull kann mit der Option "--rebase" auf "rebase" umgestellt werden (per Default wird bei pull ein "merge" ausgeführt).

Auf dem Server ist nur ein fast forward merge möglich

Sie können Ihre Änderungen in Ihrem lokalen master auch direkt in das remote Repo pushen, solange auf dem Server ein fast forward merge möglich ist.

Wenn aber (wie in der Abbildung) der lokale und der remote master divergieren, müssen Sie den Merge wie beschrieben lokal durchführen (fetch/merge oder pull) und das Ergebnis wieder in das remote Repo pushen (dann ist ja wieder ein fast forward merge möglich, es sei denn, jemand hat den remote master in der Zwischenzeit weiter geschoben - dann muss die Aktualisierung erneut durchgeführt werden).

Branches und Remotes

• Eigenen (neuen) lokalen Branch ins remote Repo schicken

  • git push <remote> <branch>

• Neuer Branch im remote Repo

  • git fetch <remote> holt (auch) alle neuen Branches
  • Lokale Änderungen an remote Branches nicht möglich! => Remote Branch in lokalen Branch mergen (oder auschecken)

Zusammenfassung: Arbeiten mit Remotes

1. Änderungen vom Server holen: git fetch <remote> => Holt alle Änderungen vom Repo <remote> ins eigene Repo (Workingcopy bleibt unangetastet!)

2. Aktuellen lokalen Branch auffrischen: git merge <remote>/<branch> (oder alternativ git pull <remote> <branch>)

3. Eigene Änderungen hochladen: git push <remote> <branch>

Anmerkung: push geht nur, wenn

1. Ziel ein "bare"-Repository ist, und
2. keine Konflikte entstehen

=> im remote Repo nur "fast forward"-Merge möglich

=> bei Konflikten erst fetch und merge, danach push

Anmerkung: Ein "bare"-Repository enthält keine Workingcopy, sondern nur das Repo an sich. Die ist bei Repos, die Sie auf einem Server wie Gitlab oder Github anlegen, automatisch der Fall. Sie können aber auch lokal ein solches "bare"-Repo anlegen, indem Sie beim Initialisieren den Schalter --bare mitgeben: git init --bare ...

Beispiel

git fetch origin           # alle Änderungen vom Server holen
git checkout master        # auf lokalen Master umschalten
git merge origin/master    # lokalen Master aktualisieren

... # Herumspielen am lokalen Master

git push origin master     # lokalen Master auf Server schicken

Vereinfachung: Tracking Branches

• Tracking Branch: lokaler Branch, der remote Branch "verfolgt"

  • Beispiel: lokaler master-Branch folgt origin/master per Default

• Vereinfachung im Workflow:

  • git pull entspricht
    1. git fetch <remote> plus
    2. git merge <remote>/<branch>
  • git push entspricht git push <remote> <branch>

Vorsicht: pull und push beziehen sich nur auf ausgecheckten Tracking Branch

Einrichten von Tracking Branches

• git clone: lokaler master trackt automatisch origin/master

• Remote Branch als Tracking Branch einrichten:

  1. Änderungen aus remote Repo holen: git fetch <remote>
  2. Tracking Branch anlegen: git checkout -t <remote>/<branch> (=> Option -t richtet den remote Branch als Tracking Branch ein)

• Lokalen neuen Branch ins remote Repo schicken und als Tracking Branch einrichten:

  1. Lokalen Branch erzeugen: git checkout -b <branch>
  2. Lokalen Branch ins Repo schicken: git push -u <remote> <branch> (=> Option -u richtet den lokalen Branch als Tracking Branch ein)

Hinzufügen eines (weiteren) Remote Repository

Sie können einem Repo beliebig viele Remotes hinzufügen:

git remote add <name> <url>

Beispiel: git remote add andi git@github.com:andi/repo.git

• Remote origin wird bei clone automatisch angelegt
• Ansehen der Remotes mit git remote -v
• fetch, push und pull jeweils über den vergebenen Namen

Beispiel: git fetch andi oder git push origin master

Wrap-Up

• Synchronisierung des lokalen Repos mit anderen Repos

  • Repo kopieren: git clone <url>
  • Interner Name fürs fremde Repo: origin
  • Änderungen vom fremden Repo holen: git fetch <remote>
  • Änderungen in lokalen Branch einpflegen: git merge <remote>/<branch>
  • Eigene Änderungen ins fremde Repo schieben: git push <remote> <branch>

• Tracking Branches (Konzept, Anwendung)

  • Remote Branches können lokal nicht verändert werden:
    • In lokale Branches mergen, oder
    • Tracking Branches anlegen => einfaches pull und push nutzen
  • Tracking Branches sind lokale Branches, die remote Branches verfolgen ("tracken")

Zusammenarbeit: Git-Workflows und Merge-/Pull-Requests

Nutzung von Git in Projekten: Verteiltes Git (und Workflows)

Git ermöglicht ein einfaches und schnelles Branchen. Dies kann man mit entsprechenden Branching-Strategien sinnvoll für die SW-Entwicklung einsetzen.

Auf der anderen Seite ermöglicht Git ein sehr einfaches verteiltes Arbeiten. Auch hier ergeben sich verschiedene Workflows, wie man mit anderen Entwicklern an einem Projekt arbeiten will/kann.

Im Folgenden sollen also die Frage betrachtet werden: Wie gestalte ich die Zusammenarbeit? Antwort: Workflows mit Git ...

Zusammenarbeit: Zentraler Workflow mit Git (analog zu SVN)

In kleinen Projektgruppen wie beispielsweise Ihrer Arbeitsgruppe wird häufig ein einfacher zentralisierter Workflow bei der Versionsverwaltung genutzt. Im Mittelpunkt steht dabei ein zentrales Repository, auf dem alle Teammitglieder gleichberechtigt und direkt pushen dürfen.

• Vorteile:

  • Einfachstes denkbares Modell
  • Ein gemeinsames Repo (wie bei SVN)
  • Alle haben Schreibzugriff auf ein gemeinsames Repo

• Nachteile:

  • Definition und Umsetzung von Rollen mit bestimmten Rechten ("Manager", "Entwickler", "Gast-Entwickler", ...) schwierig bis unmöglich (das ist kein Git-Thema, sondern hängt von der Unterstützung durch den Anbieter des Servers ab)
  • Jeder darf überall pushen: Enge und direkte Abstimmung nötig
  • Modell funktioniert meist nur in sehr kleinen Teams (2..3 Personen)

Zusammenarbeit: Einfacher verteilter Workflow mit Git

In großen und/oder öffentlichen Projekten wird üblicherweise ein Workflow eingesetzt, der auf den Möglichkeiten von verteilten Git-Repositories basiert.

Dabei wird zwischen verschiedenen Rollen ("Integrationsmanager", "Entwickler") unterschieden.

Sie finden dieses Vorgehen beispielsweise beim Linux-Kernel und auch häufig bei Projekten auf Github.

• Es existiert ein geschütztes ("blessed") Master-Repo

  • Stellt die Referenz für das Projekt dar
  • Push-Zugriff nur für ausgewählte Personen ("Integrationsmanager")

• Entwickler

  • Forken das Master-Repo auf dem Server und klonen ihren Fork lokal
  • Arbeiten auf lokalem Klon: Unabhängige Entwicklung eines Features
  • Pushen ihren Stand in ihren Fork (ihr eigenes öffentliches Repo): Veröffentlichung des Beitrags zum Projekt (sobald fertig bzw. diskutierbar)
  • Lösen Pull- bzw. Merge-Request gegen das Master-Repo aus: Beitrag soll geprüft und ins Projekt aufgenommen werden (Merge ins Master-Repo durch den Integrationsmanager)

• Integrationsmanager

  • Prüft die Änderungen im Pull- bzw. Merge-Request und fordert ggf. Nacharbeiten an bzw. lehnt Integration ab (technische oder politische Gründe)
  • Führt Merge der Entwickler-Zweige mit den Hauptzweigen durch Akzeptieren der Pull- bzw. Merge-Requests durch: Beitrag der Entwickler ist im Projekt angekommen und ist beim nächsten Pull in deren lokalen Repos vorhanden

Den hier gezeigten Zusammenhang kann man auf weitere Ebenen verteilen, vgl. den im Linux-Kernel gelebten "Dictator and Lieutenants Workflow" (siehe Literatur).

Hinweis: Hier wird nur die Zusammenarbeit im verteilten Team dargestellt. Dazu kommt noch das Arbeiten mit verschiedenen Branches!

Anmerkung: In der Workingcopy wird das eigene (öffentliche) Repo oft als origin und das geschützte ("blessed") Master-Repo als upstream referenziert.

Anmerkungen zum Forken

Sie könnten auch das Original-Repo direkt clonen. Allerdings würden dann die push dort aufschlagen, was in der Regel nicht erwünscht ist (und auch nicht erlaubt ist).

Deshalb forkt man das Original-Repo auf dem Server, d.h. auf dem Server wird eine Kopie des Original-Repos im eigenen Namespace angelegt. Auf diese Kopie hat man dann uneingeschränkten Zugriff.

Anmerkungen zu den Namen für die Remotes: origin und upstream

Üblicherweise checkt man die Kopie lokal aus (d.h. erzeugt einen Clone). In der Workingcopy verweist dann origin auf die Kopie. Um Änderungen am Original-Repo zu erhalten, fügt man dieses unter dem Namen upstream als weiteres Remote-Repo hinzu. Dies ist eine nützliche Konvention.

Um Änderungen aus dem Original-Repo in den eigenen Fork (und die Workingcopy) zu bringen, führt man dann einfach folgendes aus (im Beispiel für den master):

$ git checkout master         # Workingcopy auf master
$ git pull upstream master    # Aktualisiere lokalen master mit master aus Original-Repo
$ git push origin master      # Pushe lokalen master in den Fork

Feature-Branches aktualisieren: Mergen mit master vs. Rebase auf master

Im Netz finden sich häufig Anleitungen, wonach man Änderungen im master mit einem Merge in den Feature-Branch holt, also sinngemäß:

$ git checkout master         # Workingcopy auf master
$ git pull upstream master    # Aktualisiere lokalen master mit master aus Vorgabe-Repo
$ git checkout feature        # Workingcopy auf feature
$ git merge master            # Aktualisiere feature: Merge master in feature
$ git push origin feature     # Push aktuellen feature ins Team-Repo

Das funktioniert rein technisch betrachtet.

Allerdings spielt in den meisten Git-Projekten der master üblicherweise eine besondere Rolle (vgl. Branching-Strategien) und ist üblicherweise stets das Ziel eines Merge, aber nie die Quelle! D.h. per Konvention geht der Fluß von Änderungen stets in den master (und nicht heraus).

Wenn man sich nicht an diese Konvention hält, hat man später möglicherweise Probleme, die Merge-Historie zu verstehen (welche Änderung kam von woher)!

Um die Änderungen im master in einen Feature-Branch zu bekommen, sollte deshalb ein Rebase (des Feature-Branches auf den master) vor einem Merge (des master in den Feature-Branch) bevorzugt werden.

Merk-Regel: Merge niemals nie den master in Feature-Branches!

Achtung: Ein Rebase bei veröffentlichten Branches ist problematisch, da Dritte auf diesem Branch arbeiten könnten und entsprechend auf die Commit-IDs angewiesen sind. Nach einem Rebase stimmen diese Commit-IDs nicht mehr, was normalerweise mindestens zu Verärgerung führt ... Die Dritten müssten ihre Arbeit dann auf den neuen Feature-Branch (d.h. den Feature-Branch nach dessen Rebase) rebasen ... vgl. auch "The Perils of Rebasing" in Abschnitt "3.6 Rebasing" in [Chacon2014].

Mögliches Szenario im Praktikum

Im Praktikum haben Sie das Vorgabe-Repo. Dieses könnten Sie als upstream in Ihre lokale Workingcopy einbinden.

Mit Ihrem Team leben Sie vermutlich einen zentralen Workflow, d.h. Sie binden Ihr gemeinsames Repo als origin in Ihre lokale Workingcopy ein.

Dann müssen Sie den lokalen master aus beiden Remotes aktualisieren. Zusätzlich wollen Sie Ihren aktuellen Themenbranch auf den aktuellen master rebasen.

$ git checkout master         # Workingcopy auf master
$ git pull upstream master    # Aktualisiere lokalen master mit master aus Vorgabe-Repo
$ git pull origin master      # Aktualisiere lokalen master mit master aus Team-Repo
$ git push origin master      # Pushe lokalen master in das Team-Repo zurück
$ git rebase master feature   # Rebase feature auf den aktuellen lokalen master
$ git push -f origin feature  # Push aktuellen feature ins Team-Repo ("-f" wg. geänderter IDs durch rebase)

Anmerkung: Dabei können in Ihrem master die unschönen "Rauten" entstehen. Wenn Sie das vermeiden wollen, tauschen Sie den zweiten und den dritten Schritt und führen den Pull gegen den Upstream-master als pull --rebase durch. Dann müssen Sie Ihren lokalen master allerdings auch force-pushen in Ihr Team-Repo und die anderen Team-Mitglieder sollten darüber informiert werden, dass sich der master auf inkompatible Weise geändert hat ...

Kommunikation: Merge- bzw. Pull-Requests

Mergen kann man auf der Konsole (oder in der IDE) und anschließend die (neuen) Branches auf den Server pushen.

Die verschiedenen Git-Server erlauben ebenfalls ein GUI-gestütztes Mergen von Branches: "Merge-Requests" (MR, Gitlab) bzw. "Pull-Requests" (PR, Github). Das hat gegenüber dem lokalen Mergen wichtige Vorteile: Andere Entwickler sehen den beabsichtigten Merge (frühzeitig) und können direkt den Code kommentieren und die vorgeschlagenen Änderungen diskutieren, aber auch allgemeine Kommentare abgeben.

Falls möglich, sollte man einen MR/PR immer dem Entwickler zuweisen, der sich weiter um diesen MR/PR kümmern wird (also zunächst ist man das erstmal selbst). Zusätzlich kann man einen Reviewer bestimmen, d.h. wer soll sich den Code ansehen.

Hier ein Screenshot der Änderungsansicht unseres Gitlab-Servers (SW-Labor):

Nachfolgend für den selben MR aus der letzten Abbildung noch die reine Diskussionsansicht:

Best Practices bei Merge-/Pull-Requests

1. MR/PR so zeitig wie möglich aufmachen
   • Am besten sofort, wenn ein neuer Branch auf den Server gepusht wird!
   • Ggf. mit dem Präfix "WIP" im Titel gegen unbeabsichtigtes vorzeitiges Mergen sperren ... (bei GitHub als "Draft"-PR öffnen)
2. Auswahl Start- und Ziel-Branch (und ggf. Ziel-Repo)
   • Es gibt verschiedene Stellen, um einen MR/PR zu erstellen. Manchmal kann man nur noch den Ziel-Branch einstellen, manchmal beides.
   • Bitte auch darauf achten, welches Ziel-Repo eingestellt ist! Bei Forks wird hier immer das Original-Repo voreingestellt!
   • Den Ziel-Branch kann man ggf. auch nachträglich durch Editieren des MR/PR anpassen (Start-Branch und Ziel-Repo leider nicht, also beim Erstellen aufpassen!).
3. Titel (Summary): Das ist das, was man in der Übersicht sieht!
   • Per Default wird die letzte Commit-Message eingesetzt.
   • Analog zur Commit-Message: Bitte hier unbedingt einen sinnvollen Titel einsetzen: Was macht der MR/PR (kurz)?
4. Beschreibung: Was passiert, wenn man diesen MR/PR akzeptiert (ausführlicher)?
   • Analog zur Commit-Message sollte hier bei Bedarf die Summary ausformuliert werden und beschreiben, was der MR/PR ändert.
5. Assignee: Wer soll sich drum kümmern?
   • Ein MR/PR sollte immer jemanden zugewiesen sein, d.h. nicht "unassigned" sein. Ansonsten ist nicht klar, wer den Request durchführen/akzeptieren soll.
   • Außerdem taucht ein nicht zugewiesener MR/PR nicht in der Übersicht "meiner" MR/PR auf, d.h. diese MR/PR haben die Tendenz, vergessen zu werden!
6. Diskussion am (und neben) dem Code
   • Nur die vorgeschlagenen Code-Änderungen diskutieren!
   • Weitergehende Diskussionen (etwa über Konzepte o.ä.) besser in separaten Issues erledigen, da sonst die Anzeige des MR/PR langsam wird (ist beispielsweise ein Problem bei Gitlab).
7. Weitere Commits auf dem zu mergenden Branch gehen automatisch mit in den Request
8. Weitere Entwickler kann man mit "@username" in einem Kommentar auf "CC" setzen und in die Diskussion einbinden

Anmerkung: Bei Gitlab (d.h. auch bei dem Gitlab-Server im SW-Labor) gibt es "Merge-Requests" (MR). Bei Github gibt es "Pull-Requests" (PR) ...

Wrap-Up

• Git-Workflows für die Zusammenarbeit:

  • einfacher zentraler Ansatz für kleine Arbeitsgruppen vs.
  • einfacher verteilter Ansatz mit einem "blessed" Repo (häufig in Open-Source-Projekten zu finden)

• Aktualisieren Ihres Clones und Ihres Forks mit Änderungen aus dem "blessed" Repo

• Unterschied zwischen einem Pull/Merge und einem Pull/Rebase

• Erstellen von Beiträgen zu einem Projekt über Merge-Requests

  • Welche Commits werden Bestandteil eines Merge-Requests (und warum)
  • Diskussion über den Code in Merge-Requests

Git Worktree

Git Worktree - Mehrere Branches parallel auschecken

Szenario

• Sie arbeiten an einem Projekt
• Großes Repo mit vielen Versionen und Branches
• Ungesicherte Änderungen im Featurebranch
• Wichtige Bugfixes an alter Version nötig

Lösungsansätze

• git stash nutzen und Branch wechseln
• Repo erneut in anderem Ordner auschecken

Probleme

1. git stash und git switch

   Funktioniert für die meisten Fälle relativ gut und ist daher die "Lösung to go".

   Aber Sie müssen später aufpassen, dass Sie auch wirklich wieder im richtigen Branch sind, wenn Sie die Änderungen im Stash anwenden (git stash pop)! Und wenn Sie mehrere Einträge in der Stash-Liste haben, kann es recht schnell recht unübersichtlich werden - zu welchem Branch gehören welche Einträge in der Stash-Liste?

   Außerdem kann es gerade in größeren Projekten passieren, dass sich die Konfiguration zwischenzeitlich ändert. Wenn Sie jetzt in der IDE einfach auf einen alten Stand mit einer anderen Konfiguration wechseln, kann es schnell passieren, dass sich die IDE "verschluckt" und Sie dadurch viel Arbeit haben.

2. Nochmal woanders auschecken

   Im Prinzip ist das eine Möglichkeit. Sie können dann den anderen Ordner in Ihrer IDE als neues Projekt öffnen und sofort starten.

   Aber: Sie benötigen noch einmal den Platz auf der Festplatte/SSD/... wie für die ursprüngliche Workingcopy! Das kann bei alten/großen Projekten schnell recht groß werden und Probleme verursachen.

   Außerdem ist die Synchronisierung zwischen den beiden Workingcopies (der ursprünglichen und der neuen) nicht vorhanden bzw. das müssen Sie manuell per git push und git pull (in jeder Kopie des Repos!) erledigen!

Git Worktree kann helfen!

=> Mehrere Branches gleichzeitig auschecken (als neue Ordner im Dateisystem)

How to use Git Worktree

Worktree anlegen

Legt neuen Ordner <path> an und checkt darin <branch> als "linked worktree" aus.

Mit git worktree add ../wuppie foo würden Sie also parallel zum aktuellen Ordner (wo Ihre Workingcopy enthalten ist) einen neuen Ordner wuppie/ anlegen und darin den Branch foo auschecken.

Wenn Sie in den Ordner wuppie wechseln, finden Sie auch eine Datei .git. Darin ist lediglich der Pfad zur Workingcopy vermerkt, damit Git Änderungen auch in die eigentliche Workingcopy spiegeln kann. Dies ist der sogenannte "linked worktree".

Im Vergleich dazu finden Sie in der eigentlichen Workingcopy einen Ordner .git, der üblicherweise die gesamte Historie etc. enthält und entsprechend groß werden kann.

Den Befehl git worktree add gibt es in verschiedenen Versionen. In der Kurzform git worktree add <path> würde ein neuer Branch angelegt und ausgecheckt, der der letzten Komponente von <path> entspricht ...

Warnung: Nicht in selben Ordner oder in Unterordner auschecken!

Die neuen Worktrees sollten immer außerhalb der Workingcopy liegen! Sie können Git sehr schnell sehr gründlich durcheinanderbringen, wenn Sie einen Worktree im selben Ordner oder in einem Unterordner anlegen.

git worktree sollte nach Möglichkeit nicht zusammen mit Git Submodules eingesetzt werden (unstabiles Verhalten)!

Worktree wechseln

• Worktrees anzeigen: git worktree list
• Worktree wechseln: Ordner wechseln (IDE: neues Projekt)

Die Worktrees sind aus Sicht des Dateisystems einfach Ordner. Die .git-Datei verlinkt für Git den Ordner mit der ursprünglichen Workingcopy.

Um also mit einem Worktree arbeiten zu können, wechseln Sie einfach das Verzeichnis. In einer IDE würden Sie entsprechend ein neues Projekt anlegen. So können Sie gleichzeitig in verschiedenen Branches arbeiten.

Änderungen in einem Worktree werden automatisch in die ursprüngliche Workingcopy gespiegelt. Analog können Sie in einem Worktree auf die aktuelle Historie aus der ursprünglichen Workingcopy zugreifen.

Hinweis: Sie können in den Ordnern zwar Branches wechseln, aber nicht auf einen Branch, der bereits in einem anderen Ordner (Worktree) ausgecheckt ist. Es ist gute Praxis, dass die Ordnernamen dem ausgecheckten Branch (linked Worktree) entsprechen, um Verwirrungen zu vermeiden.

Worktree löschen

Sofern der Worktree "clean" ist, es also keine nicht comitteten Änderungen gibt, können Sie mit git worktree remove <worktree> einen Worktree <worktree> wieder löschen.

Dabei bleibt der Ordner erhalten - Sie können ihn selbst löschen oder später wiederverwenden.

Wrap-Up

Git Worktree: Auschecken von Branches in separate Ordner

• Anlegen: git worktree add <path> <branch>

• Anschauen: git worktree list

• Löschen: git worktree remove <worktree>

• Dokumentation: https://git-scm.com/docs/git-worktree

Lambda-Ausdrücke und funktionale Interfaces

Problem: Sortieren einer Studi-Liste

List<Studi> sl = new ArrayList<>();

// Liste sortieren?
sl.sort(???);  // Parameter: java.util.Comparator<Studi>

public class MyCompare implements Comparator<Studi> {
    @Override  public int compare(Studi o1, Studi o2) {
        return o1.getCredits() - o2.getCredits();
    }
}

// Liste sortieren?
MyCompare mc = new MyCompare();
sl.sort(mc);

Da Comparator<T> ein Interface ist, muss man eine extra Klasse anlegen, die die abstrakte Methode aus dem Interface implementiert und ein Objekt von dieser Klasse erzeugen und dieses dann der sort()-Methode übergeben.

Die Klasse bekommt wie in Java üblich eine eigene Datei und ist damit in der Package-Struktur offen sichtbar und "verstopft" mir damit die Strukturen: Diese Klasse ist doch nur eine Hilfsklasse ... Noch schlimmer: Ich brauche einen Namen für diese Klasse!

Den ersten Punkt könnte man über verschachtelte Klassen lösen: Die Hilfsklasse wird innerhalb der Klasse definiert, die das Objekt benötigt. Für den zweiten Punkt brauchen wir mehr Anlauf ...

Erinnerung: Verschachtelte Klassen ("Nested Classes")

Man kann Klassen innerhalb von Klassen definieren: Verschachtelte Klassen.

• Implizite Referenz auf Instanz der äußeren Klasse, Zugriff auf alle Elemente
• Begriffe:
  • "normale" innere Klassen: "inner classes"
  • statische innere Klassen: "static nested classes"
• Einsatzzweck:
  • Hilfsklassen: Zusätzliche Funktionalität kapseln; Nutzung nur in äußerer Klasse
  • Kapselung von Rückgabewerten

Sichtbarkeit: Wird u.U. von äußerer Klasse "überstimmt"

Innere Klassen ("Inner Classes")

• Objekt der äußeren Klasse muss existieren
• Innere Klasse ist normales Member der äußeren Klasse
• Implizite Referenz auf Instanz äußerer Klasse
• Zugriff auf alle Elemente der äußeren Klasse
• Sonderfall: Definition innerhalb von Methoden ("local classes")
  • Nur innerhalb der Methode sichtbar
  • Kennt zusätzlich final Attribute der Methode

Beispiel:

public class Outer {
    ...
    private class Inner {
        ...
    }

    Outer.Inner inner = new Outer().new Inner();
}

Statische innere Klassen ("Static Nested Classes")

• Keine implizite Referenz auf Objekt
• Nur Zugriff auf Klassenmethoden und -attribute

Beispiel:

class Outer {
    ...
    static class StaticNested {
        ...
    }
}

Outer.StaticNested nested = new Outer.StaticNested();

Lösung: Comparator als anonyme innere Klasse

List<Studi> sl = new ArrayList<>();

// Parametrisierung mit anonymer Klasse
sl.sort(
        new Comparator<Studi>() {
            @Override
            public int compare(Studi o1, Studi o2) {
                return o1.getCredits() - o2.getCredits();
            }
        });  // Semikolon nicht vergessen!!!

=> Instanz einer anonymen inneren Klasse, die das Interface Comparator<Studi> implementiert

• Für spezielle, einmalige Aufgabe: nur eine Instanz möglich
• Kein Name, kein Konstruktor, oft nur eine Methode
• Müssen Interface implementieren oder andere Klasse erweitern
  • Achtung Schreibweise: ohne implements oder extends!
• Konstruktor kann auch Parameter aufweisen
• Zugriff auf alle Attribute der äußeren Klasse plus alle final lokalen Variablen
• Nutzung typischerweise bei GUIs: Event-Handler etc.

Vereinfachung mit Lambda-Ausdruck

List<Studi> sl = new ArrayList<>();

// Parametrisierung mit anonymer Klasse
sl.sort(
        new Comparator<Studi>() {
            @Override
            public int compare(Studi o1, Studi o2) {
                return o1.getCredits() - o2.getCredits();
            }
        });  // Semikolon nicht vergessen!!!


// Parametrisierung mit Lambda-Ausdruck
sl.sort( (Studi o1, Studi o2) -> o1.getCredits() - o2.getCredits() );

Anmerkung: Damit für den Parameter alternativ auch ein Lambda-Ausdruck verwendet werden kann, muss der erwartete Parameter vom Typ her ein "funktionales Interface" (s.u.) sein!

Syntax für Lambdas

(Studi o1, Studi o2)  ->  o1.getCredits() - o2.getCredits()

Ein Lambda-Ausdruck ist eine Funktion ohne Namen und besteht aus drei Teilen:

1. Parameterliste (in runden Klammern),
2. Pfeil
3. Funktionskörper (rechte Seite)

Falls es genau einen Parameter gibt, können die runden Klammern um den Parameter entfallen.

Dabei kann der Funktionskörper aus einem Ausdruck ("expression") bestehen oder einer Menge von Anweisungen ("statements"), die dann in geschweifte Klammern eingeschlossen werden müssen (Block mit Anweisungen).

Der Wert des Ausdrucks ist zugleich der Rückgabewert des Lambda-Ausdrucks.

Varianten:

• (parameters) -> expression

• (parameters) -> { statements; }

Quiz: Welches sind keine gültigen Lambda-Ausdrücke?

1. () -> {}
2. () -> "wuppie"
3. () -> { return "fluppie"; }
4. (Integer i) -> return i + 42;
5. (String s) -> { "foo"; }
6. (String s) -> s.length()
7. (Studi s) -> s.getCredits() > 300
8. (List<Studi> sl) -> sl.isEmpty()
9. (int x, int y) -> { System.out.println("Erg: "); System.out.println(x+y); }
10. () -> new Studi()
11. s -> s.getCps() > 100 && s.getCps() < 300
12. s -> { return s.getCps() > 100 && s.getCps() < 300; }

Definition "Funktionales Interface" ("functional interfaces")

@FunctionalInterface
public interface Wuppie<T> {
    int wuppie(T obj);
    boolean equals(Object obj);
    default int fluppie() { return 42; }
}

Wuppie<T> ist ein funktionales Interface ("functional interface") (seit Java 8)

• Hat genau eine abstrakte Methode
• Hat evtl. weitere Default-Methoden
• Hat evtl. weitere abstrakte Methoden, die public Methoden von java.lang.Object überschreiben

Die Annotation @FunctionalInterface selbst ist nur für den Compiler: Falls das Interface kein funktionales Interface ist, würde er beim Vorhandensein dieser Annotation einen Fehler werfen. Oder anders herum: Allein durch das Annotieren mit @FunctionalInterface wird aus einem Interface noch kein funktionales Interface! Vergleichbar mit @Override ...

Während man für eine anonyme Klasse lediglich ein "normales" Interface (oder eine Klasse) benötigt, braucht man für Lambda-Ausdrücke zwingend ein passendes funktionales Interface!

Anmerkung: Es scheint keine einheitliche deutsche Übersetzung für den Begriff functional interface zu geben. Es wird häufig mit "funktionales Interface", manchmal aber auch mit "Funktionsinterface" übersetzt.

Das in den obigen Beispielen eingesetzte Interface java.util.Comparator<T> ist also ein funktionales Interface: Es hat nur eine eigene abstrakte Methode int compare(T o1, T o2);.

Im Package java.util.function sind einige wichtige funktionale Interfaces bereits vordefiniert, beispielsweise Predicate (Test, ob eine Bedingung erfüllt ist) und Function (verarbeite einen Wert und liefere einen passenden Ergebniswert). Diese kann man auch in eigenen Projekten nutzen!

Quiz: Welches ist kein funktionales Interface?

public interface Wuppie {
    int wuppie(int a);
}

public interface Fluppie extends Wuppie {
    int wuppie(double a);
}

public interface Foo {
}

public interface Bar extends Wuppie {
    default int bar() { return 42; }
}

Lambdas und funktionale Interfaces: Typprüfung

interface java.util.Comparator<T> {
    int compare(T o1, T o2);    // abstrakte Methode
}

// Verwendung ohne weitere Typinferenz
Comparator<Studi> c1 = (Studi o1, Studi o2) -> o1.getCredits() - o2.getCredits();

// Verwendung mit Typinferenz
Comparator<Studi> c2 = (o1, o2) -> o1.getCredits() - o2.getCredits();

Der Compiler prüft in etwa folgende Schritte, wenn er über einen Lambda-Ausdruck stolpert:

1. In welchem Kontext habe ich den Lambda-Ausdruck gesehen?
2. OK, der Zieltyp ist hier Comparator<Studi>.
3. Wie lautet die eine abstrakte Methode im Comparator<T>-Interface?
4. OK, das ist int compare(T o1, T o2);
5. Da T hier an Studi gebunden ist, muss der Lambda-Ausdruck der Methode int compare(Studi o1, Studi o2); entsprechen: 2x Studi als Parameter und als Ergebnis ein int
6. Ergebnis: a) Cool, passt zum Lambda-Ausdruck c1. Fertig. b) D.h. in c2 müssen o1 und o2 vom Typ Studi sein. Cool, passt zum Lambda-Ausdruck c2. Fertig.

Wrap-Up

• Anonyme Klassen: "Wegwerf"-Innere Klassen

  • Müssen Interface implementieren oder Klasse erweitern

• Java8: Lambda-Ausdrücke statt anonymer Klassen (funktionales Interface nötig)

  • Zwei mögliche Formen:
    • Form 1: (parameters) -> expression
    • Form 2: (parameters) -> { statements; }
  • Im jeweiligen Kontext muss ein funktionales Interface verwendet werden, d.h. ein Interface mit genau einer abstrakten Methode
  • Der Lambda-Ausdruck muss von der Signatur her dieser einen abstrakten Methode entsprechen

public interface IFightAI {
    void fight(Entity entity);
}

public class AIComponent extends Component {
    private final IFightAI fightAI;

    fightAI =
                entity1 -> {
                    System.out.println("TIME TO FIGHT!");
                    // todo replace with melee skill
                };
}

Methoden-Referenzen

Beispiel: Sortierung einer Liste

List<Studi> sl = new ArrayList<Studi>();

// Anonyme innere Klasse
Collections.sort(sl, new Comparator<Studi>() {
    @Override public int compare(Studi o1, Studi o2) {
        return Studi.cmpCpsClass(o1, o2);
    }
});


// Lambda-Ausdruck
Collections.sort(sl, (o1, o2) -> Studi.cmpCpsClass(o1, o2));

// Methoden-Referenz
Collections.sort(sl, Studi::cmpCpsClass);

Anmerkung

Für das obige Beispiel wird davon ausgegangen, dass in der Klasse Studi eine statische Methode cmpCpsClass() existiert:

public static int cmpCpsClass(Studi s1, Studi s2) {
    return s1.getCps() - s2.getCps();
}

Wenn man im Lambda-Ausdruck nur Methoden der eigenen Klasse aufruft, kann man das auch direkt per Methoden-Referenz abkürzen!

• Erinnerung: Comparator<T> ist ein funktionales Interface
• Instanzen können wie üblich durch Ableiten bzw. anonyme Klassen erzeugt werden
• Alternativ kann seit Java8 auch ein passender Lambda-Ausdruck verwendet werden
• Ab Java8: Referenzen auf passende Methoden (Signatur!) können ein funktionales Interface "implementieren"
  • Die statische Methode static int cmpCpsClass(Studi s1, Studi s2) hat die selbe Signatur wie int compare(Studi s1, Studi s2) aus Comparator<Studi>
  • Kann deshalb wie eine Instanz von Comparator<Studi> genutzt werden
  • Name der Methode spielt dabei keine Rolle

Überblick: Arten von Methoden-Referenzen

1. Referenz auf eine statische Methode

   • Form: ClassName::staticMethodName
   • Wirkung: Aufruf mit (args) -> ClassName.staticMethodName(args)

2. Referenz auf Instanz-Methode eines bestimmten Objekts

   • Form: objectref::instanceMethodName
   • Wirkung: Aufruf mit (args) -> objectref.instanceMethodName(args)

3. Referenz auf Instanz-Methode eines bestimmten Typs

   • Form: ClassName::instanceMethodName
   • Wirkung: Aufruf mit (arg0, rest) -> arg0.instanceMethodName(rest) (arg0 ist vom Typ ClassName)

Anmerkung: Analog zur Referenz auf eine statische Methode gibt es noch die Form der Referenz auf einen Konstruktor: ClassName::new. Für Referenzen auf Konstruktoren mit mehr als 2 Parametern muss ein eigenes passendes funktionales Interface mit entsprechend vielen Parametern definiert werden ...

Methoden-Referenz 1: Referenz auf statische Methode

public class Studi {
    public static int cmpCpsClass(Studi s1, Studi s2) {
        return s1.getCredits() - s2.getCredits();
    }

    public static void main(String... args) {
        List<Studi> sl = new ArrayList<Studi>();

        // Referenz auf statische Methode
        Collections.sort(sl, Studi::cmpCpsClass);

        // Entsprechender Lambda-Ausdruck
        Collections.sort(sl, (o1, o2) -> Studi.cmpCpsClass(o1, o2));
    }
}

Collections.sort() erwartet in diesem Szenario als zweiten Parameter eine Instanz von Comparator<Studi> mit einer Methode int compare(Studi o1, Studi o2).

Die übergebene Referenz auf die statische Methode cmpCpsClass der Klasse Studi hat die selbe Signatur und wird deshalb von Collections.sort() genauso genutzt wie die eigentlich erwartete Methode Comparator<Studi>#compare(Studi o1, Studi o2), d.h. statt compare(o1, o2) wird nun für jeden Vergleich Studi.cmpCpsClass(o1, o2) aufgerufen.

Methoden-Referenz 2: Referenz auf Instanz-Methode (Objekt)

public class Studi {
    public int cmpCpsInstance(Studi s1, Studi s2) {
        return s1.getCredits() - s2.getCredits();
    }

    public static void main(String... args) {
        List<Studi> sl = new ArrayList<Studi>();
        Studi holger = new Studi("Holger", 42);

        // Referenz auf Instanz-Methode eines Objekts
        Collections.sort(sl, holger::cmpCpsInstance);

        // Entsprechender Lambda-Ausdruck
        Collections.sort(sl, (o1, o2) -> holger.cmpCpsInstance(o1, o2));
    }
}

Collections.sort() erwartet in diesem Szenario als zweites Argument wieder eine Instanz von Comparator<Studi> mit einer Methode int compare(Studi o1, Studi o2).

Die übergebene Referenz auf die Instanz-Methode cmpCpsInstance des Objekts holger hat die selbe Signatur und wird entsprechend von Collections.sort() genauso genutzt wie die eigentlich erwartete Methode Comparator<Studi>#compare(Studi o1, Studi o2), d.h. statt compare(o1, o2) wird nun für jeden Vergleich holger.cmpCpsInstance(o1, o2) aufgerufen.

Methoden-Referenz 3: Referenz auf Instanz-Methode (Typ)

public class Studi {
    public int cmpCpsInstance(Studi studi) {
        return this.getCredits() - studi.getCredits();
    }

    public static void main(String... args) {
        List<Studi> sl = new ArrayList<Studi>();

        // Referenz auf Instanz-Methode eines Typs
        Collections.sort(sl, Studi::cmpCpsInstance);

        // Entsprechender Lambda-Ausdruck
        Collections.sort(sl, (o1, o2) -> o1.cmpCpsInstance(o2));
    }
}

Collections.sort() erwartet in diesem Szenario als zweites Argument wieder eine Instanz von Comparator<Studi> mit einer Methode int compare(Studi o1, Studi o2).

Die übergebene Referenz auf die Instanz-Methode cmpCpsInstance des Typs Studi hat die Signatur int cmpCpsInstance(Studi studi) und wird von Collections.sort() so genutzt: Statt compare(o1, o2) wird nun für jeden Vergleich o1.cmpCpsInstance(o2) aufgerufen.

Ausblick: Threads

Erinnerung an bzw. Vorgriff auf “Threads: Intro”:

public interface Runnable {
    void run();
}

Damit lassen sich Threads auf verschiedene Arten erzeugen:

public class ThreadStarter {
    public static void wuppie() { System.out.println("wuppie(): wuppie"); }
}


Thread t1 = new Thread(new Runnable() {
    public void run() {
        System.out.println("t1: wuppie");
    }
});

Thread t2 = new Thread(() -> System.out.println("t2: wuppie"));

Thread t3 = new Thread(ThreadStarter::wuppie);

Ausblick: Datenstrukturen als Streams

Erinnerung an bzw. Vorgriff auf “Stream-API”:

class X {
    public static boolean gtFour(int x) { return (x > 4) ? true : false; }
}

List<String> words = Arrays.asList("Java8", "Lambdas", "PM",
        "Dungeon", "libGDX", "Hello", "World", "Wuppie");

List<Integer> wordLengths = words.stream()
        .map(String::length)
        .filter(X::gtFour)
        .sorted()
        .collect(toList());

• Collections können als Datenstrom betrachtet werden: stream()
  • Iteration über die Collection, analog zu externer Iteration mit foreach
• Daten aus dem Strom filtern: filter, braucht Prädikat
• Auf alle Daten eine Funktion anwenden: map
• Daten im Strom sortieren: sort (auch mit Comparator)
• Daten wieder einsammeln mit collect

=> Typische Elemente funktionaler Programmierung

=> Verweis auf Wahlfach "Spezielle Methoden der Programmierung"

Wrap-Up

Seit Java8: Methoden-Referenzen statt anonymer Klassen (funktionales Interface nötig)

• Drei mögliche Formen:

  • Form 1: Referenz auf statische Methode: ClassName::staticMethodName (verwendet wie (args) -> ClassName.staticMethodName(args))
  • Form 2: Referenz auf Instanz-Methode eines Objekts: objectref::instanceMethodName (verwendet wie (args) -> objectref.instanceMethodName(args))
  • Form 3: Referenz auf Instanz-Methode eines Typs: ClassName::instanceMethodName (verwendet wie (o1, args) -> o1.instanceMethodName(args))

• Im jeweiligen Kontext muss ein passendes funktionales Interface verwendet werden (d.h. ein Interface mit genau einer abstrakten Methode)

Stream-API

Motivation

Es wurden Studis, Studiengänge und Fachbereiche modelliert (aus Gründen der Übersichtlichkeit einfach als Record-Klassen).

Nun soll pro Fachbereich die Anzahl der Studis ermittelt werden, die bereits 100 ECTS oder mehr haben. Dazu könnte man über alle Studiengänge im Fachbereich iterieren, und in der inneren Schleife über alle Studis im Studiengang. Dann filtert man alle Studis, deren ECTS größer 100 sind und erhöht jeweils den Zähler:

public record Studi(String name, int credits) {}
public record Studiengang(String name, List<Studi> studis) {}
public record Fachbereich(String name, List<Studiengang> studiengaenge) {}

private static long getCountFB(Fachbereich fb) {
    long count = 0;
    for (Studiengang sg : fb.studiengaenge()) {
        for (Studi s : sg.studis()) {
            if (s.credits() > 100) count += 1;
        }
    }
    return count;
}

Dies ist ein Beispiel, welches klassisch in OO-Manier als Iteration über Klassen realisiert ist. (Inhaltlich ist es vermutlich nicht sooo sinnvoll.)

Innere Schleife mit Streams umgeschrieben

private static long getCountSG(Studiengang sg) {
    return sg.studis().stream()
                      .map(Studi::credits)
                      .filter(c -> c > 100)
                      .count();
}

private static long getCountFB2(Fachbereich fb) {
    long count = 0;
    for (Studiengang sg : fb.studiengaenge()) {
        count += getCountSG(sg);
    }
    return count;
}

Erklärung des Beispiels

Im Beispiel wurde die innere Schleife in einen Stream ausgelagert.

Mit der Methode Collection#stream() wird aus der Collection ein neuer Stream erzeugt. Auf diesem wird für jedes Element durch die Methode map() die Methode Studi#credits() angewendet, was aus einem Strom von Studi einen Strom von Integer macht. Mit filter() wird auf jedes Element das Prädikat c -> c > 100 angewendet und alle Elemente aus dem Strom entfernt, die der Bedingung nicht entsprechen. Am Ende wird mit count() gezählt, wie viele Elemente im Strom enthalten sind.

Was ist ein Stream?

Ein "Stream" ist ein Strom (Folge) von Daten oder Objekten. In Java wird die Collections-API für die Speicherung von Daten (Objekten) verwendet. Die Stream-API dient zur Iteration über diese Daten und entsprechend zur Verarbeitung der Daten. In Java speichert ein Stream keine Daten.

Das Konzept kommt aus der funktionalen Programmierung und wurde in Java nachträglich eingebaut (wobei dieser Prozess noch lange nicht abgeschlossen zu sein scheint).

In der funktionalen Programmierung kennt man die Konzepte "map", "filter" und "reduce": Die Funktion "map()" erhält als Parameter eine Funktion und wendet diese auf alle Elemente eines Streams an. Die Funktion "filter()" bekommt ein Prädikat als Parameter und prüft jedes Element im Stream, ob es dem Prädikat genügt (also ob das Prädikat mit dem jeweiligen Element zu true evaluiert - die anderen Objekte werden entfernt). Mit "reduce()" kann man Streams zu einem einzigen Wert zusammenfassen (denken Sie etwa an das Aufsummieren aller Elemente eines Integer-Streams). Zusätzlich kann man in der funktionalen Programmierung ohne Probleme unendliche Ströme darstellen: Die Auswertung erfolgt nur bei Bedarf und auch dann auch nur so weit wie nötig. Dies nennt man auch "lazy evaluation".

Die Streams in Java versuchen, diese Konzepte aus der funktionalen Programmierung in die objektorientierte Programmierung zu übertragen. Ein Stream in Java hat eine Datenquelle, von wo die Daten gezogen werden - ein Stream speichert selbst keine Daten. Es gibt "intermediäre Operationen" auf einem Stream, die die Elemente verarbeiten und das Ergebnis als Stream zurückliefern. Daraus ergibt sich typische Pipeline-artige Verkettung der Operationen. Allerdings werden diese Operationen erst durchgeführt, wenn eine "terminale Operation" den Stream "abschließt". Ein Stream ohne eine terminale Operation macht also tatsächlich nichts.

Die Operationen auf dem Stream sind üblicherweise zustandslos, können aber durchaus auch einen Zustand haben. Dies verhindert üblicherweise die parallele Verarbeitung der Streams. Operationen sollten aber nach Möglichkeit keine Seiteneffekte haben, d.h. keine Daten außerhalb des Streams modifizieren. Operationen dürfen auf keinen Fall die Datenquelle des Streams modifizieren!

Erzeugen von Streams

List<String> l1 = List.of("Hello", "World", "foo", "bar", "wuppie");
Stream<String> s1 = l1.stream();

Stream<String> s2 = Stream.of("Hello", "World", "foo", "bar", "wuppie");

Random random = new Random();
Stream<Integer> s3 = Stream.generate(random::nextInt);

Pattern pattern = Pattern.compile(" ");
Stream<String> s4 = pattern.splitAsStream("Hello world! foo bar wuppie!");

Dies sind möglicherweise die wichtigsten Möglichkeiten, in Java einen Stream zu erzeugen.

Ausgehend von einer Klasse aus der Collection-API kann man die Methode Collection#stream() aufrufen und bekommt einen seriellen Stream.

Alternativ bietet das Interface Stream verschiedene statische Methoden wie Stream.of() an, mit deren Hilfe Streams angelegt werden können. Dies funktioniert auch mit Arrays ...

Und schließlich kann man per Stream.generate() einen Stream anlegen, wobei als Argument ein "Supplier" (Interface java.util.function.Supplier<T>) übergeben werden muss. Dieses Argument wird dann benutzt, um die Daten für den Stream zu generieren.

Wenn man aufmerksam hinschaut, findet man an verschiedensten Stellen die Möglichkeit, die Daten per Stream zu verarbeiten, u.a. bei regulären Ausdrücken.

Man kann per Collection#parallelStream() auch parallele Streams erzeugen, die intern das "Fork&Join-Framework" nutzen. Allerdings sollte man nur dann parallele Streams anlegen, wenn dadurch tatsächlich Vorteile durch die Parallelisierung zu erwarten sind (Overhead!).

Intermediäre Operationen auf Streams

private static void dummy(Studiengang sg) {
    sg.studis().stream()
            .peek(s -> System.out.println("Looking at: " + s.name()))
            .map(Studi::credits)
            .peek(c -> System.out.println("This one has: " + c + " ECTS"))
            .filter(c -> c > 5)
            .peek(c -> System.out.println("Filtered: " + c))
            .sorted()
            .forEach(System.out::println);
}

An diesem (weitestgehend sinnfreien) Beispiel werden einige intermediäre Operationen demonstriert.

Die Methode peek() liefert einen Stream zurück, die aus den Elementen des Eingabestroms bestehen. Auf jedes Element wird die Methode void accept(T) des Consumer<T> angewendet (Argument der Methode), was aber nicht zu einer Änderung der Daten führt. Hinweis: Diese Methode dient vor allem zu Debug-Zwecken! Durch den Seiteneffekt kann die Methode eine schlechtere Laufzeit zur Folge haben oder sogar eine sonst mögliche parallele Verarbeitung verhindern oder durch eine parallele Verarbeitung verwirrende Ergebnisse zeigen!

Die Methode map() liefert ebenfalls einen Stream zurück, der durch die Anwendung der Methode R apply(T) der als Argument übergebenen Function<T,R> auf jedes Element des Eingabestroms entsteht. Damit lassen sich die Elemente des ursprünglichen Streams verändern; für jedes Element gibt es im Ergebnis-Stream ebenfalls ein Element (der Typ ändert sich, aber nicht die Anzahl der Elemente).

Mit der Methode filter() wird ein Stream erzeugt, der alle Objekte des Eingabe-Streams enthält, auf denen die Anwendung der Methode boolean test(T) des Arguments Predicate<T> zu true evaluiert (der Typ und Inhalt der Elemente ändert sich nicht, aber die Anzahl der Elemente).

Mit sorted() wird ein Stream erzeugt, der die Elemente des Eingabe-Streams sortiert (existiert auch mit einem Comparator<T> als Parameter).

Diese Methoden sind alles intermediäre Operationen. Diese arbeiten auf einem Stream und erzeugen einen neuen Stream und werden erst dann ausgeführt, wenn eine terminale Operation den Stream abschließt.

Dabei sind die gezeigten intermediären Methoden bis auf sorted() ohne inneren Zustand. sorted() ist eine Operation mit innerem Zustand (wird für das Sortieren benötigt). Dies kann ordentlich in Speicher und Zeit zuschlagen und u.U. nicht/nur schlecht parallelisierbar sein. Betrachten Sie den fiktiven parallelen Stream stream.parallel().sorted().skip(42): Hier müssen erst alle Elemente sortiert werden, bevor mit skip(42) die ersten 42 Elemente entfernt werden. Dies kann auch nicht mehr parallel durchgeführt werden.

Die Methode forEach() schließlich ist eine terminale Operation, die auf jedes Element des Eingabe-Streams die Methode void accept(T) des übergebenen Consumer<T> anwendet. Diese Methode ist eine terminale Operation, d.h. sie führt zur Auswertung der anderen intermediären Operationen und schließt den Stream ab.

Was tun, wenn eine Methode Streams zurückliefert

Wir konnten vorhin nur die innere Schleife in eine Stream-basierte Verarbeitung umbauen. Das Problem ist: Die äußere Schleife würde einen Stream liefern (Stream von Studiengängen), auf dem wir die map-Funktion anwenden müssten und darin dann für jeden Studiengang einen (inneren) Stream mit den Studis eines Studiengangs verarbeiten müssten.

private static long getCountSG(Studiengang sg) {
    return sg.studis().stream().map(Studi::credits).filter(c -> c > 100).count();
}

private static long getCountFB2(Fachbereich fb) {
    long count = 0;
    for (Studiengang sg : fb.studiengaenge()) {
        count += getCountSG(sg);
    }
    return count;
}

Dafür ist die Methode flatMap() die Lösung. Diese Methode bekommt als Argument ein Objekt vom Typ Function<? super T, ? extends Stream<? extends R>> mit einer Methode Stream<? extends R> apply(T). Die Methode flatMap() verarbeitet den Stream in zwei Schritten:

1. Mappe über alle Elemente des Eingabe-Streams mit der Funktion. Im Beispiel würde also aus einem Stream<Studiengang> jeweils ein Stream<Stream<Studi>>, also alle Studiengang-Objekte werden durch je ein Stream<Studi>-Objekt ersetzt. Wir haben jetzt also einen Stream von Stream<Studi>-Objekten.

2. "Klopfe den Stream wieder flach", d.h. nimm die einzelnen Studi-Objekte aus den Stream<Studi>-Objekten und setze diese stattdessen in den Stream. Das Ergebnis ist dann wie gewünscht ein Stream<Studi> (Stream mit Studi-Objekten).

private static long getCountFB3(Fachbereich fb) {
    return fb.studiengaenge().stream()
            .flatMap(sg -> sg.studis().stream())
            .map(Studi::credits)
            .filter(c -> c > 100)
            .count();
}

Zum direkten Vergleich hier noch einmal der ursprüngliche Code mit zwei verschachtelten Schleifen und entsprechenden Hilfsvariablen:

private static long getCountFB(Fachbereich fb) {
    long count = 0;
    for (Studiengang sg : fb.studiengaenge()) {
        for (Studi s : sg.studis()) {
            if (s.credits() > 100) count += 1;
        }
    }
    return count;
}

Streams abschließen: Terminale Operationen

Stream<String> s = Stream.of("Hello", "World", "foo", "bar", "wuppie");

long count = s.count();
s.forEach(System.out::println);
String first = s.findFirst().get();
Boolean b = s.anyMatch(e -> e.length() > 3);

List<String> s1 = s.collect(Collectors.toList());
List<String> s2 = s.toList();   // ab Java16
Set<String> s3 = s.collect(Collectors.toSet());
List<String> s4 = s.collect(Collectors.toCollection(LinkedList::new));

Streams müssen mit einer terminalen Operation abgeschlossen werden, damit die Verarbeitung tatsächlich angestoßen wird (lazy evaluation).

Es gibt viele verschiedene terminale Operationen. Wir haben bereits count() und forEach() gesehen. In der Sitzung zu “Optionals” werden wir noch findFirst() näher kennenlernen.

Daneben gibt es beispielsweise noch allMatch(), anyMatch() und noneMatch(), die jeweils ein Prädikat testen und einen Boolean zurückliefern (matchen alle, mind. eines oder keines der Objekte im Stream).

Mit min() und max() kann man sich das kleinste und das größte Element des Streams liefern lassen. Beide Methoden benötigen dazu einen Comparator<T> als Parameter.

Mit der Methode collect() kann man eine der drei Methoden aus Collectors über den Stream laufen lassen und eine Collection erzeugen lassen:

1. toList() sammelt die Elemente in ein List-Objekt (bzw. direkt mit stream.toList() (ab Java16))
2. toSet() sammelt die Elemente in ein Set-Objekt
3. toCollection() sammelt die Elemente durch Anwendung der Methode T get() des übergebenen Supplier<T>-Objekts auf

Die ist nur die sprichwörtliche "Spitze des Eisbergs"! Es gibt viele weitere Möglichkeiten, sowohl bei den intermediären als auch den terminalen Operationen. Schauen Sie in die Dokumentation!

Spielregeln

• Operationen dürfen nicht die Stream-Quelle modifizieren

• Operationen können die Werte im Stream ändern (map) oder die Anzahl (filter)

• Keine Streams in Attributen/Variablen speichern oder als Argumente übergeben: Sie könnten bereits "gebraucht" sein!

  => Ein Stream sollte immer sofort nach der Erzeugung benutzt werden

• Operationen auf einem Stream sollten keine Seiteneffekte (Veränderungen von Variablen/Attributen außerhalb des Streams) haben (dies verhindert u.U. die parallele Verarbeitung)

Wrap-Up

Stream<T>: Folge von Objekten vom Typ T, Verarbeitung "lazy" (Gegenstück zu Collection<T>: Dort werden Daten gespeichert, hier werden Daten verarbeitet)

• Neuen Stream anlegen: Collection#stream() oder Stream.of() ...

• Intermediäre Operationen: peek(), map(), flatMap(), filter(), sorted() ...

• Terminale Operationen: count(), forEach(), allMatch(), collect() ...

  • collect(Collectors.toList())
  • collect(Collectors.toSet())
  • collect(Collectors.toCollection()) (mit Supplier<T>)

• Streams speichern keine Daten

• Intermediäre Operationen laufen erst bei Abschluss des Streams los

• Terminale Operation führt zur Verarbeitung und Abschluss des Streams

Schöne Doku: "The Stream API", und auch "Package java.util.stream".

Optional

Motivation

public class LSF {
    private Set<Studi> sl;

    public Studi getBestStudi() {
        if (sl == null) return null;  // Fehler: Es gibt noch keine Sammlung

        Studi best = null;
        for (Studi s : sl) {
            if (best == null) best = s;
            if (best.credits() < s.credits()) best = s;
        }
        return best;
    }
}

public static void main(String... args) {
    LSF lsf = new LSF();

    Studi best = lsf.getBestStudi();
    if (best != null) {
        String name = best.name();
        if (name != null) {
            // mach was mit dem Namen ...
        }
    }
}

Problem: null wird an (zu) vielen Stellen genutzt

• Es gibt keinen Wert ("not found")
• Felder wurden (noch) nicht initialisiert
• Es ist ein Problem oder etwas Unerwartetes aufgetreten

=> Parameter und Rückgabewerte müssen stets auf null geprüft werden (oder Annotationen wie @NotNull eingesetzt werden ...)

Lösung

• Optional<T> für Rückgabewerte, die "kein Wert vorhanden" mit einschließen (statt null bei Abwesenheit von Werten)
• @NotNull/@Nullable für Parameter einsetzen (oder separate Prüfung)
• Exceptions werfen in Fällen, wo ein Problem aufgetreten ist

Anmerkungen

• Verwendung von null auf Attribut-Ebene (Klassen-interne Verwendung) ist okay!
• Optional<T> ist kein Ersatz für null-Checks!
• null ist kein Ersatz für vernünftiges Error-Handling! Das häufig zu beobachtende "Irgendwas Unerwartetes ist passiert, hier ist null" ist ein Anti-Pattern!

Beispiel aus der Praxis im PM-Dungeon

Schauen Sie sich einmal das Review zu den ecs.components.ai.AITools in https://github.com/Dungeon-CampusMinden/Dungeon/pull/128#pullrequestreview-1254025874 an.

Die Methode AITools#calculateNewPath soll in der Umgebung einer als Parameter übergebenen Entität nach einem Feld (Tile) suchen, welches für die Entität betretbar ist und einen Pfad von der Position der Entität zu diesem Feld an den Aufrufer zurückliefern.

Zunächst wird in der Entität nach einer PositionComponent und einer VelocityComponent gesucht. Wenn es (eine) diese(r) Components nicht in der Entität gibt, wird der Wert null an den Aufrufer von AITools#calculateNewPath zurückgeliefert. (Anmerkung: Interessanterweise wird in der Methode nicht mit der VelocityComponent gearbeitet.)

Dann wird in der PositionComponent die Position der Entität im aktuellen Level abgerufen. In einer Schleife werden alle Felder im gegebenen Radius in eine Liste gespeichert. (Anmerkung: Da dies über die float-Werte passiert und nicht über die Feld-Indizes wird ein Tile u.U. recht oft in der Liste abgelegt. Können Sie sich hier einfache Verbesserungen überlegen?)

Da level.getTileAt() offenbar als Antwort auch null zurückliefern kann, werden nun zunächst per tiles.removeIf(Objects::isNull); all diese null-Werte wieder aus der Liste entfernt. Danach erfolgt die Prüfung, ob die verbleibenden Felder betretbar sind und nicht-betretbare Felder werden entfernt.

Aus den verbleibenden (betretbaren) Feldern in der Liste wird nun eines zufällig ausgewählt und per level.findPath() ein Pfad von der Position der Entität zu diesem Feld berechnet und zurückgeliefert. (Anmerkung: Hier wird ein zufälliges Tile in der Liste der umgebenden Felder gewählt, von diesem die Koordinaten bestimmt, und dann noch einmal aus dem Level das dazugehörige Feld geholt - dabei hatte man die Referenz auf das Feld bereits in der Liste. Können Sie sich hier eine einfache Verbesserung überlegen?)

Zusammengefasst:

• Die als Parameter entity übergebene Referenz darf offenbar nicht null sein. Die ersten beiden Statements in der Methode rufen auf dieser Referenz Methoden auf, was bei einer null-Referenz zu einer NullPointer-Exception führen würde. Hier wäre null ein Fehlerzustand.
• entity.getComponent() kann offenbar null zurückliefern, wenn die gesuchte Component nicht vorhanden ist. Hier wird null als "kein Wert vorhanden" genutzt, was dann nachfolgende null-Checks notwendig macht.
• Wenn es die gewünschten Components nicht gibt, wird dem Aufrufer der Methode null zurückgeliefert. Hier ist nicht ganz klar, ob das einfach nur "kein Wert vorhanden" ist oder eigentlich ein Fehlerzustand?
• level.getTileAt() kann offenbar null zurückliefern, wenn kein Feld an der Position vorhanden ist. Hier wird null wieder als "kein Wert vorhanden" genutzt, was dann nachfolgende null-Checks notwendig macht (Entfernen aller null-Referenzen aus der Liste).
• level.findPath() kann auch wieder null zurückliefern, wenn kein Pfad berechnet werden konnte. Hier ist wieder nicht ganz klar, ob das einfach nur "kein Wert vorhanden" ist oder eigentlich ein Fehlerzustand? Man könnte beispielsweise in diesem Fall ein anderes Feld probieren?

Der Aufrufer bekommt also eine NullPointer-Exception, wenn der übergebene Parameter entity nicht vorhanden ist oder den Wert null, wenn in der Methode etwas schief lief oder schlicht kein Pfad berechnet werden konnte oder tatsächlich einen Pfad. Damit wird der Aufrufer gezwungen, den Rückgabewert vor der Verwendung zu untersuchen.

Allein in dieser einen kurzen Methode macht null so viele extra Prüfungen notwendig und den Code dadurch schwerer lesbar und fehleranfälliger! null wird als (unvollständige) Initialisierung und als Rückgabewert und für den Fehlerfall genutzt, zusätzlich ist die Semantik von null nicht immer klar. (Anmerkung: Der Gebrauch von null hat nicht wirklich etwas mit "der Natur eines ECS" zu tun. Die Methode wurde mittlerweile komplett überarbeitet und ist in der hier gezeigten Form glücklicherweise nicht mehr zu finden.)

Entsprechend hat sich in diesem Review die nachfolgende Diskussion ergeben:

Erzeugen von Optional-Objekten

Konstruktor ist private ...

• "Kein Wert": Optional.empty()

• Verpacken eines non-null Elements: Optional.of() (NullPointerException wenn Argument null!)

• Verpacken eines "unsicheren"/beliebigen Elements: Optional.ofNullable()

  • Liefert verpacktes Element, oder
  • Optional.empty(), falls Element null war

Es sollte in der Praxis eigentlich nur wenige Fälle geben, wo ein Aufruf von Optional.of() sinnvoll ist. Ebenso ist Optional.empty() nur selten sinnvoll.

Stattdessen sollte stets Optional.ofNullable() verwendet werden.

null kann nicht nicht in Optional<T> verpackt werden! (Das wäre dann eben Optional.empty().)

LSF liefert jetzt Optional zurück

public class LSF {
    private Set<Studi> sl;

    public Optional<Studi> getBestStudi() throws NullPointerException {
        // Fehler: Es gibt noch keine Sammlung
        if (sl == null) throw new NullPointerException("There ain't any collection");

        Studi best = null;
        for (Studi s : sl) {
            if (best == null) best = s;
            if (best.credits() < s.credits()) best = s;
        }

        // Entweder Optional.empty() (wenn best==null) oder Optional.of(best) sonst
        return Optional.ofNullable(best);
    }
}

Das Beispiel soll verdeutlichen, dass man im Fehlerfall nicht einfach null oder Optional.empty() zurückliefern soll, sondern eine passende Exception werfen soll.

Wenn die Liste aber leer ist, stellt dies keinen Fehler dar! Es handelt sich um den Fall "kein Wert vorhanden". In diesem Fall wird statt null nun ein Optional.empty() zurückgeliefert, also ein Objekt, auf dem der Aufrufer die üblichen Methoden aufrufen kann.

Zugriff auf Optional-Objekte

In der funktionalen Programmierung gibt es schon lange das Konzept von Optional, in Haskell ist dies beispielsweise die Monade Maybe. Allerdings ist die Einbettung in die Sprache von vornherein mit berücksichtigt worden, insbesondere kann man hier sehr gut mit Pattern Matching in der Funktionsdefinition auf den verpackten Inhalt reagieren.

In Java gibt es die Methode Optional#isEmpty(), die einen Boolean zurückliefert und prüft, ob es sich um ein leeres Optional handelt oder ob hier ein Wert "verpackt" ist.

Für den direkten Zugriff auf die Werte gibt es die Methoden Optional#orElseThrow() und Optional#orElse(). Damit kann man auf den verpackten Wert zugreifen, oder es wird eine Exception geworfen bzw. ein Ersatzwert geliefert.

Zusätzlich gibt es Optional#isPresent(), die als Parameter ein java.util.function.Consumer erwartet, also ein funktionales Interface mit einer Methode void accept(T), die das Objekt verarbeitet.

Studi best;

// Testen und dann verwenden
if (!lsf.getBestStudi().isEmpty()) {
    best = lsf.getBestStudi().get();
    // mach was mit dem Studi ...
}

// Arbeite mit Consumer
lsf.getBestStudi().ifPresent(studi -> {
    // mach was mit dem Studi ...
});

// Studi oder Alternative (wenn Optional.empty())
best = lsf.getBestStudi().orElse(anne);

// Studi oder NoSuchElementException (wenn Optional.empty())
best = lsf.getBestStudi().orElseThrow();

Es gibt noch eine Methode get(), die so verhält wie orElseThrow(). Da man diese Methode vom Namen her schnell mit einem Getter verwechselt, ist sie mittlerweile deprecated.

Anmerkung: Da getBestStudi() eine NullPointerException werfen kann, sollte der Aufruf möglicherweise in ein try/catch verpackt werden. Dito für orElseThrow().

Einsatz mit Stream-API

public class LSF {
    ...
    public Optional<Studi> getBestStudi() throws NullPointerException {
        if (sl == null) throw new NullPointerException("There ain't any collection");
        return sl.stream()
                 .sorted((s1, s2) -> s2.credits() - s1.credits())
                 .findFirst();
    }
}


public static void main(String... args) {
    ...
    String name = lsf.getBestStudi()
                     .map(Studi::name)
                     .orElseThrow();
}

Im Beispiel wird in getBestStudi() die Sammlung als Stream betrachtet, über die Methode sorted() und den Lamda-Ausdruck für den Comparator sortiert ("falsch" herum: absteigend in den Credits der Studis in der Sammlung), und findFirst() ist die terminale Operation auf dem Stream, die ein Optional<Studi> zurückliefert: entweder den Studi mit den meisten Credits (verpackt in Optional<Studi>) oder Optional.empty(), wenn es überhaupt keine Studis in der Sammlung gab.

In main() wird dieses Optional<Studi> mit den Stream-Methoden von Optional<T> bearbeitet, zunächst mit Optional#map(). Man braucht nicht selbst prüfen, ob das von getBestStudi() erhaltene Objekt leer ist oder nicht, da dies von Optional#map() erledigt wird: Es wendet die Methodenreferenz auf den verpackten Wert an (sofern dieser vorhanden ist) und liefert damit den Namen des Studis als Optional<String> verpackt zurück. Wenn es keinen Wert, also nur Optional.empty() von getBestStudi() gab, dann ist der Rückgabewert von Optional#map() ein Optional.empty(). Wenn der Name, also der Rückgabewert von Studi::name, null war, dann wird ebenfalls ein Optional.empty() zurückgeliefert. Dadurch wirft orElseThrow() dann eine NoSuchElementException. Man kann also direkt mit dem String name weiterarbeiten ohne extra null-Prüfung - allerdings will man noch ein Exception-Handling einbauen (dies fehlt im obigen Beispiel aus Gründen der Übersicht) ...

Weitere Optionals

Für die drei primitiven Datentypen int, long und double gibt es passende Wrapper-Klassen von Optional<T>: OptionalInt, OptionalLong und OptionalDouble.

Diese verhalten sich analog zu Optional<T>, haben aber keine Methode ofNullable(), da dies hier keinen Sinn ergeben würde: Die drei primitiven Datentypen repräsentieren Werte - diese können nicht null sein.

Regeln für Optional

1. Nutze Optional nur als Rückgabe für "kein Wert vorhanden"

   Optional ist nicht als Ersatz für eine null-Prüfung o.ä. gedacht, sondern als Repräsentation, um auch ein "kein Wert vorhanden" zurückliefern zu können.

2. Nutze nie null für eine Optional-Variable oder einen Optional-Rückgabewert

   Wenn man ein Optional als Rückgabe bekommt, sollte das niemals selbst eine null-Referenz sein. Das macht das gesamte Konzept kaputt!

   Nutzen Sie stattdessen Optional.empty().

3. Nutze Optional.ofNullable() zum Erzeugen eines Optional

   Diese Methode verhält sich "freundlich" und erzeugt automatisch ein Optional.empty(), wenn das Argument null ist. Es gibt also keinen Grund, dies mit einer Fallunterscheidung selbst erledigen zu wollen.

   Bevorzugen Sie Optional.ofNullable() vor einer manuellen Fallunterscheidung und dem entsprechenden Einsatz von Optional.of() und Optional.empty().

4. Erzeuge keine Optional als Ersatz für die Prüfung auf null

   Wenn Sie auf null prüfen müssen, müssen Sie auf null prüfen. Der ersatzweise Einsatz von Optional macht es nur komplexer - prüfen müssen Sie hinterher ja immer noch.

5. Nutze Optional nicht in Attributen, Methoden-Parametern und Sammlungen

   Nutzen Sie Optional vor allem für Rückgabewerte.

   Attribute sollten immer direkt einen Wert haben oder null, analog Parameter von Methoden o.ä. ... Hier hilft Optional nicht, Sie müssten ja trotzdem eine null-Prüfung machen, nur eben dann über den Optional, wodurch dies komplexer und schlechter lesbar wird.

   Aus einem ähnlichen Grund sollten Sie auch in Sammlungen keine Optional speichern!

6. Vermeide den direkten Zugriff (ifPresent(), orElseThrow() ...)

   Der direkte Zugriff auf ein Optional entspricht dem Prüfen auf null und dann dem Auspacken. Dies ist nicht nur Overhead, sondern auch schlechter lesbar.

   Vermeiden Sie den direkten Zugriff und nutzen Sie Optional mit den Stream-Methoden. So ist dies von den Designern gedacht.

Interessante Links

• "Using Optionals"
• "What You Might Not Know About Optional"
• "Experienced Developers Use These 7 Java Optional Tips to Remove Code Clutter"
• "Code Smells: Null"
• "Class Optional"

Wrap-Up

Optional als Rückgabe für "kein Wert vorhanden"

• Optional.ofNullable(): Erzeugen eines Optional

  • Entweder Objekt "verpackt" (Argument != null)
  • Oder Optional.empty() (Argument == null)

• Prüfen mit isEmpty() und ifPresent()

• Direkter Zugriff mit ifPresent(), orElse() und orElseThrow()

• Stream-API: map(), filter(), flatMap(), ...

• Attribute, Parameter und Sammlungen: nicht Optional nutzen

• Kein Ersatz für null-Prüfung!

Schöne Doku: "Using Optionals".

String format(final String text, String replacement) {
    if (text.isEmpty()) {
        return "";
    }

    final String trimmed = text.trim();
    final String withSpacesReplaced = trimmed.replaceAll(" +", replacement);

    return replacement + withSpacesReplaced + replacement;
}

Record-Klassen

public record StudiR(String name, int credits) {}

Motivation; Klasse Studi

public class Studi {
    private final String name;
    private final int credits;

    public Studi(String name, int credits) {
        this.name = name;
        this.credits = credits;
    }

    public String getName() {
        return name;
    }

    public int getCredits() {
        return credits;
    }
}

Klasse Studi als Record

public record StudiR(String name, int credits) {}

• Immutable Klasse mit Feldern String name und int credits => "(String name, int credits)" werden "Komponenten" des Records genannt

• Standardkonstruktor setzt diese Felder ("Kanonischer Konstruktor")

• Getter für beide Felder:

  public String name() { return this.name; }
  public int credits() { return this.credits; }

Record-Klassen wurden in Java14 eingeführt und werden immer wieder in neuen Releases erweitert/ergänzt.

Der kanonische Konstruktor hat das Aussehen wie die Record-Deklaration, im Beispiel also public StudiR(String name, int credits). Dabei werden die Komponenten über eine Kopie der Werte initialisiert.

Für die Komponenten werden automatisch private Attribute mit dem selben Namen angelegt.

Für die Komponenten werden automatisch Getter angelegt. Achtung: Die Namen entsprechen denen der Komponenten, es fehlt also der übliche "get"-Präfix!

Eigenschaften und Einschränkungen von Record-Klassen

• Records erweitern implizit die Klasse java.lang.Record: Keine andere Klassen mehr erweiterbar! (Interfaces kein Problem)

• Record-Klassen sind implizit final

• Keine weiteren (Instanz-) Attribute definierbar (nur die Komponenten)

• Keine Setter definierbar für die Komponenten: Attribute sind final

• Statische Attribute mit Initialisierung erlaubt

Records: Prüfungen im Konstruktor

Der Konstruktor ist erweiterbar:

public record StudiS(String name, int credits) {
    public StudiS(String name, int credits) {
        if (name == null) { throw new IllegalArgumentException("Name cannot be null!"); }
        else { this.name = name; }

        if (credits < 0) { this.credits = 0; }
        else { this.credits = credits; }
    }
}

In dieser Form muss man die Attribute selbst setzen.

Alternativ kann man die "kompakte" Form nutzen:

public record StudiT(String name, int credits) {
    public StudiT {
        if (name == null) { throw new IllegalArgumentException("Name cannot be null!"); }

        if (credits < 0) { credits = 0; }
    }
}

In der kompakten Form kann man nur die Werte der Parameter des Konstruktors ändern. Das Setzen der Attribute ergänzt der Compiler nach dem eigenen Code.

Es sind weitere Konstruktoren definierbar, diese müssen den kanonischen Konstruktor aufrufen:

public StudiT() {
    this("", 42);
}

Getter und Methoden

Getter werden vom Compiler automatisch generiert. Dabei entsprechen die Methoden-Namen den Namen der Attribute:

public record StudiR(String name, int credits) {}

public static void main(String... args) {
    StudiR r = new StudiR("Sabine", 75);

    int x = r.credits();
    String y = r.name();
}

Getter überschreibbar und man kann weitere Methoden definieren:

public record StudiT(String name, int credits) {
    public int credits() { return credits + 42; }
    public void wuppie() { System.out.println("WUPPIE"); }
}

Die Komponenten/Attribute sind aber final und können nicht über Methoden geändert werden!

Beispiel aus den Challenges

In den Challenges zum Thema Optional gibt es die Klasse Katze in den Vorgaben.

Die Katze wurde zunächst "klassisch" modelliert: Es gibt drei Eigenschaften name, gewichtund lieblingsBox. Ein Konstruktor setzt diese Felder und es gibt drei Getter für die einzelnen Eigenschaften. Das braucht 18 Zeilen Code (ohne Kommentare Leerzeilen). Zudem erzeugt der Boilerplate-Code relativ viel "visual noise", so dass der eigentliche Kern der Klasse schwerer zu erkennen ist.

In einem Refactoring wurde diese Klasse durch eine äquivalente Record-Klasse ersetzt, die nur noch 2 Zeilen Code (je nach Code-Style auch nur 1 Zeile) benötigt. Gleichzeitig wurde die Les- und Wartbarkeit deutlich verbessert.

Wrap-Up

• Records sind immutable Klassen:
  • final Attribute (entsprechend den Komponenten)
  • Kanonischer Konstruktor
  • Automatische Getter (Namen wie Komponenten)
• Konstruktoren und Methoden können ergänzt/überschrieben werden
• Keine Vererbung von Klassen möglich (kein extends)

Schöne Doku: "Using Record to Model Immutable Data".

Interfaces: Default-Methoden

Problem: Etablierte API (Interfaces) erweitern

interface Klausur {
    void anmelden(Studi s);
    void abmelden(Studi s);
}

=> Nachträglich noch void schreiben(Studi s); ergänzen?

Wenn ein Interface nachträglich erweitert wird, müssen alle Kunden (also alle Klassen, die das Interface implementieren) auf die neuen Signaturen angepasst werden. Dies kann viel Aufwand verursachen und API-Änderungen damit unmöglich machen.

Default-Methoden: Interfaces mit Implementierung

Seit Java8 können Interfaces auch Methoden implementieren. Es gibt zwei Varianten: Default-Methoden und statische Methoden.

interface Klausur {
    void anmelden(Studi s);
    void abmelden(Studi s);

    default void schreiben(Studi s) {
        ...     // Default-Implementierung
    }

    default void wuppie() {
        throw new java.lang.UnsupportedOperationException();
    }
}

Methoden können in Interfaces seit Java8 implementiert werden. Für Default-Methoden muss das Schlüsselwort default vor die Signatur gesetzt werden. Klassen, die das Interface implementieren, können diese Default-Implementierung erben oder selbst neu implementieren (überschreiben). Alternativ kann die Klasse eine Default-Methode neu deklarieren und wird damit zur abstrakten Klasse.

Dies ähnelt abstrakten Klassen. Allerdings kann in abstrakten Klassen neben dem Verhalten (implementierten Methoden) auch Zustand über die Attribute gespeichert werden.

Problem: Mehrfachvererbung

Drei Regeln zum Auflösen bei Konflikten:

1. Klassen gewinnen: Methoden aus Klasse oder Superklasse haben höhere Priorität als Default-Methoden
2. Sub-Interfaces gewinnen: Methode aus am meisten spezialisiertem Interface mit Default-Methode wird gewählt Beispiel: Wenn B extends A dann ist B spezialisierter als A
3. Sonst: Klasse muss Methode explizit auswählen: Methode überschreiben und gewünschte (geerbte) Variante aufrufen: X.super.m(...) (X ist das gewünschte Interface)

Auf den folgenden Folien wird dies anhand kleiner Beispiele verdeutlicht.

Auflösung Mehrfachvererbung: 1. Klassen gewinnen

interface A {
    default String hello() { return "A"; }
}
class C {
    public String hello() { return "C"; }
}
class E extends C implements A {}


/** Mehrfachvererbung: 1. Klassen gewinnen */
public class DefaultTest1 {
    public static void main(String... args) {
        String e = new E().hello();
    }
}

Die Klasse E erbt sowohl von Klasse C als auch vom Interface A die Methode hello() (Mehrfachvererbung). In diesem Fall "gewinnt" die Implementierung aus Klasse C.

1. Regel: Klassen gewinnen immer. Deklarationen einer Methode in einer Klasse oder einer Oberklasse haben Vorrang von allen Default-Methoden.

Auflösung Mehrfachvererbung: 2. Sub-Interfaces gewinnen

interface A {
    default String hello() { return "A"; }
}
interface B extends A {
    @Override default String hello() { return "B"; }
}
class D implements A, B {}


/** Mehrfachvererbung: 2. Sub-Interfaces gewinnen */
public class DefaultTest2 {
    public static void main(String... args) {
        String e = new D().hello();
    }
}

Die Klasse D erbt sowohl vom Interface A als auch vom Interface B die Methode hello() (Mehrfachvererbung). In diesem Fall "gewinnt" die Implementierung aus Klasse B: Interface B ist spezialisierter als A.

2. Regel: Falls Regel 1 nicht zutrifft, gewinnt die Default-Methode, die am meisten spezialisiert ist.

Auflösung Mehrfachvererbung: 3. Methode explizit auswählen

interface A {
    default String hello() { return "A"; }
}
interface B {
    default String hello() { return "B"; }
}
class D implements A, B {
    @Override public String hello() { return A.super.hello(); }
}


/** Mehrfachvererbung: 3. Methode explizit auswählen */
public class DefaultTest3 {
    public static void main(String... args) {
        String e = new D().hello();
    }
}

Die Klasse D erbt sowohl vom Interface A als auch vom Interface B die Methode hello() (Mehrfachvererbung). In diesem Fall muss zur Auflösung die Methode in D neu implementiert werden und die gewünschte geerbte Methode explizit aufgerufen werden. (Wenn dies unterlassen wird, führt das selbst bei Nicht-Nutzung der Methode hello() zu einem Compiler-Fehler!)

Achtung: Der Aufruf der Default-Methode aus Interface A erfolgt mit A.super.hello(); (nicht einfach durch A.hello();)!

3. Regel: Falls weder Regel 1 noch 2 zutreffen bzw. die Auflösung noch uneindeutig ist, muss man manuell durch die explizite Angabe der gewünschten Methode auflösen.

Quiz: Was kommt hier raus?

interface A {
    default String hello() { return "A"; }
}
interface B extends A {
    @Override default String hello() { return "B"; }
}
class C implements B {
    @Override public String hello() { return "C"; }
}
class D extends C implements A, B {}


/** Quiz Mehrfachvererbung */
public class DefaultTest {
    public static void main(String... args) {
        String e = new D().hello(); // ???
    }
}

Die Klasse D erbt sowohl von Klasse C als auch von den Interfaces A und B die Methode hello() (Mehrfachvererbung). In diesem Fall "gewinnt" die Implementierung aus Klasse C: Klassen gewinnen immer (Regel 1).

Statische Methoden in Interfaces

public interface Collection<E> extends Iterable<E> {
    boolean add(E e);
    ...
}
public class Collections {
    private Collections() { }
    public static <T> boolean addAll(Collection<? super T> c, T... elements) {...}
    ...
}

Typisches Pattern in Java: Interface plus Utility-Klasse (Companion-Klasse) mit statischen Hilfsmethoden zum einfacheren Umgang mit Instanzen des Interfaces (mit Objekten, deren Klasse das Interface implementiert). Beispiel: Collections ist eine Hilfs-Klasse zum Umgang mit Collection-Objekten.

Seit Java8 können in Interfaces neben Default-Methoden auch statische Methoden implementiert werden.

Die Hilfsmethoden können jetzt ins Interface wandern => Utility-Klassen werden obsolet ... Aus Kompatibilitätsgründen würde man die bisherige Companion-Klasse weiterhin anbieten, wobei die Implementierungen auf die statischen Methoden im Interface verweisen (SKIZZE, nicht real!):

public interface CollectionX<E> extends Iterable<E> {
    boolean add(E e);
    static <T> boolean addAll(CollectionX<? super T> c, T... elements) { ... }
    ...
}
public class CollectionsX {
    public static <T> boolean addAll(CollectionX<? super T> c, T... elements) {
        return CollectionX.addAll(c, elements);  // Verweis auf Interface
    }
    ...
}

Interfaces vs. Abstrakte Klassen

• Abstrakte Klassen: Schnittstelle und Verhalten und Zustand

• Interfaces:

  • vor Java 8 nur Schnittstelle
  • ab Java 8 Schnittstelle und Verhalten

  Unterschied zu abstrakten Klassen: Kein Zustand, d.h. keine Attribute

• Design:

  • Interfaces sind beinahe wie abstrakte Klassen, nur ohne Zustand
  • Klassen können nur von einer (abstrakten) Klasse erben, aber viele Interfaces implementieren

Wrap-Up

Seit Java8: Interfaces mit Implementierung: Default-Methoden

• Methoden mit dem Schlüsselwort default können Implementierung im Interface haben
• Die Implementierung wird vererbt und kann bei Bedarf überschrieben werden
• Auflösung von Mehrfachvererbung:
  • Regel 1: Klassen gewinnen
  • Regel 2: Sub-Interfaces gewinnen
  • Regel 3: Methode explizit auswählen
• Unterschied zu abstrakten Klassen: Kein Zustand

Javadoc

Dokumentation mit Javadoc

/**
 * Beschreibung Beschreibung (Summary).
 *
 * <p>Hier kommt dann ein laengerer Text, der die Dinge
 * bei Bedarf etwas ausfuehrlicher erklaert.
 */
public void wuppie() {}

Javadoc-Kommentare sind (aus Java-Sicht) normale Block-Kommentare, wobei der Beginn mit /** eingeleitet wird. Dieser Beginn ist für das Tool javadoc (Bestandteil des JDK, genau wie java und javac) das Signal, dass hier ein Kommentar anfängt, den das Tool in eine HTML-Dokumentation übersetzen soll.

Typischerweise wird am Anfang jeder Kommentarzeile ein * eingefügt; dieser wird von Javadoc ignoriert.

Sie können neben normalem Text und speziellen Annotationen auch HTML-Elemente wie <p> und <code> oder <ul> nutzen.

Mit javadoc *.java können Sie in der Konsole aus den Java-Dateien die Dokumentation generieren lassen. Oder Sie geben das in Ihrer IDE in Auftrag ... (die dann diesen Aufruf gern für Sie tätigt).

Standard-Aufbau

/**
 * Beschreibung Beschreibung (Summary).
 *
 * <p> Hier kommt dann ein laengerer Text, der die Dinge
 * bei Bedarf etwas ausfuehrlicher erklaert.
 *
 * @param   date  Tag, Wert zw. 1 .. 31
 * @return  Anzahl der Sekunden seit 1.1.1970
 * @throws  NumberFormatException
 * @deprecated As of JDK version 1.1
 */
public int setDate(int date) {
    setField(Calendar.DATE, date);
}

• Erste Zeile bei Methoden/Attributen geht in die generierte "Summary" in der Übersicht, der Rest in die "Details"
  • Die "Summary" sollte kein kompletter Satz sein, wird aber wie ein Satz geschrieben (Groß beginnen, mit Punkt beenden). Es sollte nicht beginnen mit "Diese Methode macht ..." oder "Diese Klasse ist ...". Ein gutes Beispiel wäre "Berechnet die Steuerrückerstattung."
  • Danach kommen die Details, die in der generierten Dokumentation erst durch Aufklappen der Elemente sichtbar sind. Erklären Sie, wieso der Code was machen soll und welche Designentscheidungen getroffen wurden (und warum).
• Leerzeilen gliedern den Text in Absätze. Neue Absätze werden mit einem <p> eingeleitet. (Ausnahmen: Wenn der Text mit <ul> o.ä. beginnt oder der Absatz mit den Block-Tags.)
• Die "Block-Tags" @param, @return, @throws, @deprecated werden durch einen Absatz von der restlichen Beschreibung getrennt und tauchen in exakt dieser Reihenfolge auf. Die Beschreibung dieser Tags ist nicht leer - anderenfalls lässt man das Tag weg. Falls die Zeile für die Beschreibung nicht reicht, wird umgebrochen und die Folgezeile mit vier Leerzeichen (beginnend mit dem @) eingerückt.
  • Mit @param erklären Sie die Bedeutung eines Parameters (von links nach rechts) einer Methode. Beispiel: @param date Tag, Wert zw. 1 .. 31. Wiederholen Sie dies für jeden Parameter.
  • Mit @return beschreiben Sie den Rückgabetyp/-wert. Beispiel: @return Anzahl der Sekunden seit 1.1.1970. Bei Rückgabe von void wird diese Beschreibung weggelassen (die Beschreibung wäre dann ja leer).
  • Mit @throws geben Sie an, welche "checked" Exceptions die Methode wirft.
  • Mit @deprecated können Sie im Kommentar sagen, dass ein Element veraltet ist und möglicherweise mit der nächsten Version o.ä. entfernt wird. (siehe nächste Folie)

=> Dies sind die Basis-Regeln aus dem populären Google-Java-Style [googlestyleguide].

Veraltete Elemente

/**
 * Beschreibung Beschreibung Beschreibung.
 *
 * @deprecated As of v102, replaced by <code>Foo.fluppie()</code>.
 */
@Deprecated
public void wuppie() {}

• Annotation zum Markieren als "veraltet" (in der generierten Dokumentation): @deprecated
• Für Sichtbarkeit zur Laufzeit bzw. im Tooling/IDE: normale Code-Annotation @Deprecated

Dies ist ein guter Weg, um Elemente einer öffentlichen API als "veraltet" zu kennzeichnen. Üblicherweise wird diese Kennzeichnung für einige wenige Releases beibehalten und danach das veraltete Element aus der API entfernt.

Autoren, Versionen, ...

/**
 * Beschreibung Beschreibung Beschreibung.
 *
 * @author  Dagobert Duck
 * @version V1
 * @since   schon immer
 */

• Annotationen für Autoren und Version: @author, @version, @since

Diese Annotationen finden Sie vor allem in Kommentaren zu Packages oder Klassen.

Was muss kommentiert werden?

• Alle public Klassen

• Alle public und protected Elemente der Klassen

• Ausnahme: @Override (An diesen Methoden kann, aber muss nicht kommentiert werden.)

Alle anderen Elemente bei Bedarf mit normalen Kommentaren versehen.

Beispiel aus dem JDK: ArrayList

Schauen Sie sich gern mal Klassen aus der Java-API an, beispielsweise eine java.util.ArrayList:

• Generierte Dokumentation: zu "ArrayList" runterscrollen bzw. direkt
• Quellcode: ArrayList.java

Best Practices: Was beschreibe ich eigentlich?

Unter Documentation Best Practices finden Sie eine sehr gute Beschreibung, was das Ziel der Dokumentation sein sollte. Versuchen Sie, dieses zu erreichen!

Wrap-Up

• Javadoc-Kommentare sind normale Block-Kommentare beginnend mit /**

• Generierung der HTML-Dokumentation mit javadoc *.java

• Erste Zeile ist eine Zusammenfassung (fast immer sichtbar)

• Längerer Text danach als "Description" einer Methode/Klasse

• Annotationen für besondere Elemente: @param, @return, @throws, @deprecated

• Faustregel: Alle public und protected Elemente mit Javadoc kommentieren!

Logging

Wie prüfen Sie die Werte von Variablen/Objekten?

1. Debugging

   • Beeinflusst Code nicht
   • Kann schnell komplex und umständlich werden
   • Sitzung transient - nicht wiederholbar

2. "Poor-man's-debugging" (Ausgaben mit System.out.println)

   • Müssen irgendwann entfernt werden
   • Ausgabe nur auf einem Kanal (Konsole)
   • Keine Filterung nach Problemgrad - keine Unterscheidung zwischen Warnungen, einfachen Informationen, ...

3. Logging

   • Verschiedene (Java-) Frameworks: java.util.logging (JDK), log4j (Apache), SLF4J, Logback, ...

Java Logging API - Überblick

Paket java.util.logging

Eine Applikation kann verschiedene Logger instanziieren. Die Logger bauen per Namenskonvention hierarchisch aufeinander auf. Jeder Logger kann selbst mehrere Handler haben, die eine Log-Nachricht letztlich auf eine bestimmte Art und Weise an die Außenwelt weitergeben.

Log-Meldungen werden einem Level zugeordnet. Jeder Logger und Handler hat ein Mindest-Level eingestellt, d.h. Nachrichten mit einem kleineren Level werden verworfen.

Zusätzlich gibt es noch Filter, mit denen man Nachrichten (zusätzlich zum Log-Level) nach weiteren Kriterien filtern kann.

Erzeugen neuer Logger

import java.util.logging.Logger;
Logger l = Logger.getLogger(MyClass.class.getName());

• Factory-Methode der Klasse java.util.logging.Logger

  public static Logger getLogger(String name);

  => Methode liefert bereits vorhandenen Logger mit diesem Namen (sonst neuen Logger)

• Best Practice: Nutzung des voll-qualifizierten Klassennamen: MyClass.class.getName()

  • Leicht zu implementieren
  • Leicht zu erklären
  • Spiegelt modulares Design
  • Ausgaben enthalten automatisch Hinweis auf Herkunft (Lokalität) der Meldung
  • Alternativen: Funktionale Namen wie "XML", "DB", "Security"

Ausgabe von Logmeldungen

public void log(Level level, String msg);

• Diverse Convenience-Methoden (Auswahl):

  public void warning(String msg)
  public void info(String msg)
  public void entering(String srcClass, String srcMethod)
  public void exiting(String srcClass, String srcMethod)

• Beispiel

  import java.util.logging.Logger;
  Logger l = Logger.getLogger(MyClass.class.getName());
  l.info("Hello World :-)");

Wichtigkeit von Logmeldungen: Stufen

• java.util.logger.Level definiert 7 Stufen:

  • SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST (von höchster zu niedrigster Prio)
  • Zusätzlich ALL und OFF

• Nutzung der Log-Level:

  • Logger hat Log-Level: Meldungen mit kleinerem Level werden verworfen
  • Prüfung mit public boolean isLoggable(Level)
  • Setzen mit public void setLevel(Level)

=> Warum wird im Beispiel nach log.setLevel(Level.ALL); trotzdem nur ab INFO geloggt? Wer erzeugt eigentlich die Ausgaben?!

Jemand muss die Arbeit machen ...

• Pro Logger mehrere Handler möglich

  • Logger übergibt nicht verworfene Nachrichten an Handler
  • Handler haben selbst ein Log-Level (analog zum Logger)
  • Handler verarbeiten die Nachrichten, wenn Level ausreichend

• Standard-Handler: StreamHandler, ConsoleHandler, FileHandler

• Handler nutzen zur Formatierung der Ausgabe einen Formatter

• Standard-Formatter: SimpleFormatter und XMLFormatter

=> Warum wird im Beispiel nach dem Auskommentieren von log.setUseParentHandlers(false); immer noch eine zusätzliche Ausgabe angezeigt (ab INFO aufwärts)?!

Ich ... bin ... Dein ... Vater ...

• Logger bilden Hierarchie über Namen

  • Trenner für Namenshierarchie: "." (analog zu Packages) => mit jedem "." wird eine weitere Ebene der Hierarchie aufgemacht ...
  • Jeder Logger kennt seinen Eltern-Logger: Logger#getParent()
  • Basis-Logger: leerer Name ("")
    • Voreingestelltes Level des Basis-Loggers: Level.INFO (!)

• Weiterleiten von Nachrichten

  • Nicht verworfene Log-Aufrufe werden an Eltern-Logger weitergeleitet (Default)
    • Abschalten mit Logger#setUseParentHandlers(false);
  • Diese leiten an ihre Handler sowie an ihren Eltern-Logger weiter (unabhängig von Log-Level!)

Wrap-Up

• Java Logging API im Paket java.util.logging

• Neuer Logger über Factory-Methode der Klasse Logger

  • Einstellbares Log-Level (Klasse Level)
  • Handler kümmern sich um die Ausgabe, nutzen dazu Formatter
  • Mehrere Handler je Logger registrierbar
  • Log-Level auch für Handler einstellbar (!)
  • Logger (und Handler) "interessieren" sich nur für Meldungen ab bestimmter Wichtigkeit
  • Logger reichen nicht verworfene Meldungen defaultmäßig an Eltern-Logger weiter (rekursiv)

Code Smells

Code Smells: Ist das Code oder kann das weg?

class checker {
    static public void CheckANDDO(DATA1 inp, int c, FH.Studi
    CustD, int x, int y, int in, int out,int c1, int c2, int c3 = 4)
{
    public int i; // neues i
for(i=0;i<10;i++) // fuer alle i
{
        inp.kurs[0] = 10; inp.kurs[i] = CustD.cred[i]/c;
}
      SetDataToPlan(  CustD  );
    public double myI = in*2.5; // myI=in*2.5
    if (c1)
        out = myI; //OK
    else if(  c3 == 4  )
    {
        myI = c2 * myI;
    if (c3 != 4 || true ) { // unbedingt beachten!
        //System.out.println("x:"+(x++));
        System.out.println("x:"+(x++)); // x++
        System.out.println("out: "+out);
    } }}   }

Der Code im obigen Beispiel lässt sich möglicherweise kompilieren. Und möglicherweise tut er sogar das, was er tun soll.

Dennoch: Der Code "stinkt" (zeigt Code Smells):

• Nichtbeachtung üblicher Konventionen (Coding Rules)
• Schlechte Kommentare
• Auskommentierter Code
• Fehlende Datenkapselung
• Zweifelhafte Namen
• Duplizierter Code
• "Langer" Code: Lange Methoden, Klassen, Parameterlisten, tief verschachtelte if/then-Bedingungen, ...
• Feature Neid
• switch/case oder if/else statt Polymorphie
• Globale Variablen, lokale Variablen als Attribut
• Magic Numbers

Diese Liste enthält die häufigsten "Smells" und ließe sich noch beliebig fortsetzen. Schauen Sie mal in die unten angegebene Literatur :-)

Stinkender Code führt zu möglichen (späteren) Problemen.

Was ist guter ("sauberer") Code ("Clean Code")?

Im Grunde bezeichnet "sauberer Code" ("Clean Code") die Abwesenheit von Smells. D.h. man könnte Code als "sauberen" Code bezeichnen, wenn die folgenden Eigenschaften erfüllt sind (keine vollständige Aufzählung!):

• Gut ("angenehm") lesbar
• Schnell verständlich: Geeignete Abstraktionen
• Konzentriert sich auf eine Aufgabe
• So einfach und direkt wie möglich
• Ist gut getestet

In [Martin2009] lässt der Autor Robert Martin verschiedene Ikonen der SW-Entwicklung zu diesem Thema zu Wort kommen - eine sehr lesenswerte Lektüre!

=> Jemand kümmert sich um den Code; solides Handwerk

Warum ist guter ("sauberer") Code so wichtig?

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

 Quelle: [Fowler2011, p. 15]

Auch wenn das zunächst seltsam klingt, aber Code muss auch von Menschen gelesen und verstanden werden können. Klar, der Code muss inhaltlich korrekt sein und die jeweilige Aufgabe erfüllen, er muss kompilieren etc. ... aber er muss auch von anderen Personen weiter entwickelt werden und dazu gelesen und verstanden werden. Guter Code ist nicht einfach nur inhaltlich korrekt, sondern kann auch einfach verstanden werden.

Code, der nicht einfach lesbar ist oder nur schwer verständlich ist, wird oft in der Praxis später nicht gut gepflegt: Andere Entwickler haben (die berechtigte) Angst, etwas kaputt zu machen und arbeiten "um den Code herum". Nur leider wird das Konstrukt dann nur noch schwerer verständlich ...

Code Smells

Verstöße gegen die Prinzipien von Clean Code nennt man auch Code Smells: Der Code "stinkt" gewissermaßen. Dies bedeutet nicht unbedingt, dass der Code nicht funktioniert (d.h. er kann dennoch compilieren und die Anforderungen erfüllen). Er ist nur nicht sauber formuliert, schwer verständlich, enthält Doppelungen etc., was im Laufe der Zeit die Chance für tatsächliche Probleme deutlich erhöht.

Und weil es so wichtig ist, hier gleich noch einmal:

"Broken Windows" Phänomen

Wenn ein Gebäude leer steht, wird es eine gewisse Zeit lang nur relativ langsam verfallen: Die Fenster werden nicht mehr geputzt, es sammelt sich Graffiti, Gras wächst in der Dachrinne, Putz blättert ab ...

Irgendwann wird dann eine Scheibe eingeworfen. Wenn dieser Punkt überschritten ist, beschleunigt sich der Verfall rasant: Über Nacht werden alle erreichbaren Scheiben eingeworfen, Türen werden zerstört, es werden sogar Brände gelegt ...

Das passiert auch bei Software! Wenn man als Entwickler das Gefühl bekommt, die Software ist nicht gepflegt, wird man selbst auch nur relativ schlechte Arbeit abliefern. Sei es, weil man nicht versteht, was der Code macht und sich nicht an die Überarbeitung der richtigen Stellen traut und stattdessen die Änderungen als weiteren "Erker" einfach dran pappt. Seit es, weil man keine Lust hat, Zeit in ordentliche Arbeit zu investieren, weil der Code ja eh schon schlecht ist ... Das wird mit der Zeit nicht besser ...

Maßeinheit für Code-Qualität ;-)

Es gibt eine "praxisnahe" (und nicht ganz ernst gemeinte) Maßeinheit für Code-Qualität: Die "WTF/m" (What the Fuck per minute): Thom Holwerda: www.osnews.com/story/19266/WTFs_.

Wenn beim Code-Review durch Kollegen viele "WTF" kommen, ist der Code offenbar nicht in Ordnung ...

Code Smells: Nichtbeachtung von Coding Conventions

• Richtlinien für einheitliches Aussehen => Andere Programmierer sollen Code schnell lesen können

  • Namen, Schreibweisen
  • Kommentare (Ort, Form, Inhalt)
  • Einrückungen und Spaces vs. Tabs
  • Zeilenlängen, Leerzeilen
  • Klammern

• Beispiele: Sun Code Conventions, Google Java Style

• Hinweis: Betrifft vor allem die (äußere) Form!

Code Smells: Schlechte Kommentare I

• Ratlose Kommentare

  /* k.A. was das bedeutet, aber wenn man es raus nimmt, geht's nicht mehr */
  /* TODO: was passiert hier, und warum? */

  Der Programmierer hat selbst nicht verstanden (und macht sich auch nicht die Mühe zu verstehen), was er da tut! Fehler sind vorprogrammiert!

• Redundante Kommentare: Erklären Sie, was der Code inhaltlich tun sollte (und warum)!

  public int i; // neues i
  for(i=0;i<10;i++)
  // fuer alle i

  Was würden Sie Ihrem Kollegen erklären (müssen), wenn Sie ihm/ihr den Code vorstellen?

  Wiederholen Sie nicht, was der Code tut (das kann ich ja selbst lesen), sondern beschreiben Sie, was der Code tun sollte und warum.

  Beschreiben Sie dabei auch das Konzept hinter einem Codebaustein.

Code Smells: Schlechte Kommentare II

• Veraltete Kommentare

  Hinweis auf unsauberes Arbeiten: Oft wird im Zuge der Überarbeitung von Code-Stellen vergessen, auch den Kommentar anzupassen! Sollte beim Lesen extrem misstrauisch machen.

• Auskommentierter Code

  Da ist jemand seiner Sache unsicher bzw. hat eine Überarbeitung nicht abgeschlossen. Die Chance, dass sich der restliche Code im Laufe der Zeit so verändert, dass der auskommentierte Code nicht mehr (richtig) läuft, ist groß! Auskommentierter Code ist gefährlich und dank Versionskontrolle absolut überflüssig!

• Kommentare erscheinen zwingend nötig

  Häufig ein Hinweis auf ungeeignete Wahl der Namen (Klassen, Methoden, Attribute) und/oder auf ein ungeeignetes Abstraktionsniveau (beispielsweise Nichtbeachtung des Prinzips der "Single Responsibility")!

  Der Code soll im Normalfall für sich selbst sprechen: WAS wird gemacht. Der Kommentar erklärt im Normalfall, WARUM der Code das machen soll.

• Unangemessene Information, z.B. Änderungshistorien

  Hinweise wie "wer hat wann was geändert" gehören in das Versionskontroll- oder ins Issue-Tracking-System. Die Änderung ist im Code sowieso nicht mehr sichtbar/nachvollziehbar!

Code Smells: Schlechte Namen und fehlende Kapselung

public class Studi extends Person {
    public String n;
    public int c;

    public void prtIf() { ... }
}

Nach drei Wochen fragen Sie sich, was n oder c oder Studi#prtIf() wohl sein könnte! (Ein anderer Programmierer fragt sich das schon beim ersten Lesen.) Klassen und Methoden sollten sich erwartungsgemäß verhalten.

Wenn Dinge öffentlich angeboten werden, muss man damit rechnen, dass andere darauf zugreifen. D.h. man kann nicht mehr so einfach Dinge wie die interne Repräsentation oder die Art der Berechnung austauschen! Öffentliche Dinge gehören zur Schnittstelle und damit Teil des "Vertrags" mit den Nutzern!

• Programmierprinzip "Prinzip der minimalen Verwunderung"

  • Klassen und Methoden sollten sich erwartungsgemäß verhalten
  • Gute Namen ersparen das Lesen der Dokumentation

• Programmierprinzip "Kapselung/Information Hiding"

  • Möglichst schlanke öffentliche Schnittstelle
  • => "Vertrag" mit Nutzern der Klasse!

Code Smells: Duplizierter Code

public class Studi {
    public String getName() { return name; }
    public String getAddress() {
        return strasse+", "+plz+" "+stadt;
    }

    public String getStudiAsString() {
        return name+" ("+strasse+", "+plz+" "+stadt+")";
    }
}

• Programmierprinzip "DRY" => "Don't repeat yourself!"

Im Beispiel wird das Formatieren der Adresse mehrfach identisch implementiert, d.h. duplizierter Code. Auslagern in eigene Methode und aufrufen!

Kopierter/duplizierter Code ist problematisch:

• Spätere Änderungen müssen an mehreren Stellen vorgenommen werden
• Lesbarkeit/Orientierung im Code wird erschwert (Analogie: Reihenhaussiedlung)
• Verpasste Gelegenheit für sinnvolle Abstraktion!

Code Smells: Langer Code

• Lange Klassen

  • Faustregel: 5 Bildschirmseiten sind viel

• Lange Methoden

  • Faustregel: 1 Bildschirmseite
  • [Martin2009]: deutlich weniger als 20 Zeilen

• Lange Parameterlisten

  • Faustregel: max. 3 ... 5 Parameter
  • [Martin2009]: 0 Parameter ideal, ab 3 Parameter gute Begründung nötig

• Tief verschachtelte if/then-Bedingungen

  • Faustregel: 2 ... 3 Einrückungsebenen sind viel

• Programmierprinzip "Single Responsibility"

  Jede Klasse ist für genau einen Aspekt des Gesamtsystems verantwortlich

Lesbarkeit und Übersichtlichkeit leiden

• Der Mensch kann sich nur begrenzt viele Dinge im Kurzzeitgedächtnis merken
• Klassen, die länger als 5 Bildschirmseiten sind, erfordern viel Hin- und Her-Scrollen, dito für lange Methoden
• Lange Methoden sind schwer verständlich (erledigen viele Dinge?)
• Mehr als 3 Parameter kann sich kaum jemand merken, vor allem beim Aufruf von Methoden
• Die Testbarkeit wird bei zu komplexen Methoden/Klassen und vielen Parametern sehr erschwert
• Große Dateien verleiten (auch mangels Übersichtlichkeit) dazu, neuen Code ebenfalls schluderig zu gliedern

Langer Code deutet auch auf eine Verletzung des Prinzips der Single Responsibility hin

• Klassen fassen evtl. nicht zusammengehörende Dinge zusammen

  public class Student {
      private String name;
      private String phoneAreaCode;
      private String phoneNumber;
  
      public void printStudentInfo() {
          System.out.println("name:    " + name);
          System.out.println("contact: " + phoneAreaCode + "/" + phoneNumber);
      }
  }

  Warum sollte sich die Klasse Student um die Einzelheiten des Aufbaus einer Telefonnummer kümmern? Das Prinzip der "Single Responsibility" wird hier verletzt!

• Methoden erledigen vermutlich mehr als nur eine Aufgabe

  public void credits() {
      for (Student s : students) {
          if (s.hasSemesterFinished()) {
              ECTS c = calculateEcts(s);
              s.setEctsSum(c);
          }
      }
  }
  
  // Diese Methode erledigt 4 Dinge: Iteration, Abfrage, Berechnung, Setzen ...

  => Erklären Sie die Methode jemandem. Wenn dabei das Wort "und" vorkommt, macht die Methode höchstwahrscheinlich zu viel!

• Viele Parameter bedeuten oft fehlende Datenabstraktion

  Circle makeCircle(int x, int y, int radius);
  Circle makeCircle(Point center, int radius);  // besser!

Code Smells: Feature Neid

public class CreditsCalculator {
    public ECTS calculateEcts(Student s) {
        int semester = s.getSemester();
        int workload = s.getCurrentWorkload();
        int nrModuls = s.getNumberOfModuls();
        int total = Math.min(30, workload);
        int extra = Math.max(0, total - 30);
        if (semester < 5) {
             extra = extra * nrModuls;
        }
        return new ECTS(total + extra);
    }
}

• Zugriff auf (viele) Interna der anderen Klasse! => Hohe Kopplung der Klassen!
• Methode CreditsCalculator#calculateEcts() "möchte" eigentlich in Student sein ...

Weiterführende Links

• "Foundations: Clean Code" (The Odin Project)
• "Documentation Best Practices" (Google Styleguide)

Wrap-Up

• Code entsteht nicht zum Selbstzweck => Lesbarkeit ist wichtig

• Code Smells: Code führt zu möglichen (späteren) Problemen

  • Richtiges Kommentieren und Dokumentieren

    In dieser Sitzung haben wir vor allem auf Kommentare geschaut. Zum Thema Dokumentieren siehe die Einheit zu “Javadoc”.

  • Einhalten von Coding Conventions

    • Regeln zu Schreibweisen und Layout
    • Leerzeichen, Einrückung, Klammern
    • Zeilenlänge, Umbrüche
    • Kommentare

  • Einhalten von Prinzipien des objektorientierten Programmierens

    • Jede Klasse ist für genau einen Aspekt des Systems verantwortlich. (Single Responsibility)
    • Keine Code-Duplizierung! (DRY - Don't repeat yourself)
    • Klassen und Methoden sollten sich erwartungsgemäß verhalten
    • Kapselung: Möglichst wenig öffentlich zugänglich machen

Coding Conventions und Metriken

Coding Conventions: Richtlinien für einheitliches Aussehen von Code

=> Ziel: Andere Programmierer sollen Code schnell lesen können

• Namen, Schreibweisen: UpperCamelCase vs. lowerCamelCase vs. UPPER_SNAKE_CASE
• Kommentare (Ort, Form, Inhalt): Javadoc an allen public und protected Elementen
• Einrückungen und Spaces vs. Tabs: 4 Spaces
• Zeilenlängen: 100 Zeichen
• Leerzeilen: Leerzeilen für Gliederung
• Klammern: Auf selber Zeile wie Code

Beispiele: Sun Code Conventions, Google Java Style, AOSP Java Code Style for Contributors

Beispiel nach Google Java Style/AOSP formatiert

package wuppie.deeplearning.strategy;

/**
 * Demonstriert den Einsatz von AOSP/Google Java Style ................. Umbruch nach 100 Zeichen |
 */
public class MyWuppieStudi implements Comparable<MyWuppieStudi> {
    private static String lastName;
    private static MyWuppieStudi studi;

    private MyWuppieStudi() {}

    /** Erzeugt ein neues Exemplar der MyWuppieStudi-Spezies (max. 40 Zeilen) */
    public static MyWuppieStudi getMyWuppieStudi(String name) {
        if (studi == null) {
            studi = new MyWuppieStudi();
        }
        if (lastName == null) lastName = name;

        return studi;
    }

    @Override
    public int compareTo(MyWuppieStudi o) {
        return lastName.compareTo(lastName);
    }
}

Dieses Beispiel wurde nach Google Java Style/AOSP formatiert.

Die Zeilenlänge beträgt max. 100 Zeichen. Pro Methode werden max. 40 Zeilen genutzt. Zwischen Attributen, Methoden und Importen wird jeweils eine Leerzeile eingesetzt (zwischen den einzelnen Attributen muss aber keine Leerzeile genutzt werden). Zur logischen Gliederung können innerhalb von Methoden weitere Leerzeilen eingesetzt werden, aber immer nur eine.

Klassennamen sind UpperCamelCase, Attribute und Methoden und Parameter lowerCamelCase, Konstanten (im Beispiel nicht vorhanden) UPPER_SNAKE_CASE. Klassen sind Substantive, Methoden Verben.

Alle public und protected Elemente werden mit einem Javadoc-Kommentar versehen. Überschriebene Methoden müssen nicht mit Javadoc kommentiert werden, müssen aber mit @Override markiert werden.

Geschweifte Klammern starten immer auf der selben Codezeile. Wenn bei einem if nur ein Statement vorhanden ist und dieses auf die selbe Zeile passt, kann auf die umschließenden geschweiften Klammern ausnahmsweise verzichtet werden.

Es wird mit Leerzeichen eingerückt. Google Java Style arbeitet mit 2 Leerzeichen, während AOSP hier 4 Leerzeichen vorschreibt. Im Beispiel wurde nach AOSP eingerückt.

Darüber hinaus gibt es vielfältige weitere Regeln für das Aussehen des Codes. Lesen Sie dazu entsprechend auf Google Java Style und auch auf AOSP nach.

Formatieren Sie Ihren Code (mit der IDE)

Sie können den Code manuell formatieren, oder aber (sinnvollerweise) über Tools formatieren lassen. Hier einige Möglichkeiten:

• IDE: Code-Style einstellen und zum Formatieren nutzen

• google-java-format: java -jar google-java-format.jar --replace *.java (auch als IDE-Plugin)

• Spotless in Gradle:

  plugins {
      id "java"
      id "com.diffplug.spotless" version "6.5.0"
  }
  
  spotless {
      java {
          // googleJavaFormat()
          googleJavaFormat().aosp()  // indent w/ 4 spaces
      }
  }

  Prüfen mit ./gradlew spotlessCheck (Teil von ./gradlew check) und Formatieren mit ./gradlew spotlessApply

Einstellungen der IDE's

• Eclipse:
  • Project > Properties > Java Code Style > Formatter: Coding-Style einstellen/einrichten
  • Code markieren, Source > Format
  • Komplettes Aufräumen: Source > Clean Up (Formatierung, Importe, Annotationen, ...) Kann auch so eingestellt werden, dass ein "Clean Up" immer beim Speichern ausgeführt wird!
• IntelliJ verfügt über ähnliche Fähigkeiten:
  • Einstellen über Preferences > Editor > Code Style > Java
  • Formatieren mit Code > Reformat Code oder Code > Reformat File

Die Details kann/muss man einzeln einstellen. Für die "bekannten" Styles (Google Java Style) bringen die IDE's oft aber schon eine Gesamtkonfiguration mit.

Achtung: Zumindest in Eclipse gibt es mehrere Stellen, wo ein Code-Style eingestellt werden kann ("Clean Up", "Formatter", ...). Diese sollten dann jeweils auf den selben Style eingestellt werden, sonst gibt es unter Umständen lustige Effekte, da beim Speichern ein anderer Style angewendet wird als beim "Clean Up" oder beim "Format Source" ...

Analog sollte man bei der Verwendung von Checkstyle auch in der IDE im Formatter die entsprechenden Checkstyle-Regeln (s.u.) passend einstellen, sonst bekommt man durch Checkstyle Warnungen angezeigt, die man durch ein automatisches Formatieren nicht beheben kann.

Google Java Style und google-java-format

Wer direkt den Google Java Style nutzt, kann auch den dazu passenden Formatter von Google einsetzen: google-java-format. Diesen kann man entweder als Plugin für IntelliJ/Eclipse einsetzen oder als Stand-alone-Tool (Kommandozeile oder Build-Skripte) aufrufen. Wenn man sich noch einen entsprechenden Git-Hook definiert, wird vor jedem Commit der Code entsprechend den Richtlinien formatiert :)

Spotless und google-java-format in Gradle

Hinweis: Bei Spotless in Gradle müssen je nach den Versionen von Spotless/google-java-format bzw. des JDK noch Optionen in der Datei gradle.properties eingestellt werden (siehe Demo und Spotless > google-java-format (Web)).

Tipp: Die Formatierung über die IDE ist angenehm, aber in der Praxis leider oft etwas hakelig: Man muss alle Regeln selbst einstellen (und es gibt einige dieser Einstellungen), und gerade IntelliJ "greift" manchmal nicht alle Code-Stellen beim Formatieren. Nutzen Sie Spotless und bauen Sie die Konfiguration in Ihr Build-Skript ein und konfigurieren Sie über den Build-Prozess.

Metriken: Kennzahlen für verschiedene Aspekte zum Code

Metriken messen verschiedene Aspekte zum Code und liefern eine Zahl zurück. Mit Metriken kann man beispielsweise die Einhaltung der Coding Rules (Formate, ...) prüfen, aber auch die Einhaltung verschiedener Regeln des objektorientierten Programmierens.

Beispiele für wichtige Metriken (jeweils Max-Werte für PM)

Die folgenden Metriken und deren Maximal-Werte sind gute Erfahrungswerte aus der Praxis und helfen, den Code Smell "Langer Code" (vgl. “Code Smells”) zu erkennen und damit zu vermeiden. Über die Metriken BEC, McCabe und DAC wird auch die Einhaltung elementarer Programmierregeln gemessen.

• NCSS (Non Commenting Source Statements)
  • Zeilen pro Methode: 40; pro Klasse: 250; pro Datei: 300 Annahme: Eine Anweisung je Zeile ...
• Anzahl der Methoden pro Klasse: 10
• Parameter pro Methode: 3
• BEC (Boolean Expression Complexity) Anzahl boolescher Ausdrücke in if etc.: 3
• McCabe (Cyclomatic Complexity)
  • Anzahl der möglichen Verzweigungen (Pfade) pro Methode + 1
  • 1-4 gut, 5-7 noch OK
• DAC (Class Data Abstraction Coupling)
  • Anzahl der genutzten (instantiierten) "Fremdklassen"
  • Werte kleiner 7 werden i.A. als normal betrachtet