Meine Empfehlung: der Kurs „Spring framework 5: Beginner to Guru“, den ich im Februar 2019 angefangen habe, um die Basics von JHipster besser zu verstehen.
John Thompson erneuert in diesem Kurs zudem „deprecated“ Videos. Das mag erst einmal nerven („Bekomme ich den Kurs denn nie zu Ende…“), dient aber auch zur Wiederholung.
Zum prinzipiellen Verständnis des Spring frameworks zählen sicher die
I.) Single Responsibility Principle
- Jede Klasse sollte eine Zuständigkeit verwalten
- Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern
- Die Klassen sollten klein sein – nie mehr Code als auf einen Bildschirm passt
- „Göttliche“ Klassen sollten vermieden werden
- Große Klassen sollten in kleinere Klassen aufgeteilt werden
II.) Open-Close Principle
- Eine Klasse sollte offen für Erweiterungen sein
- Eine Klasse sollte geschützt sein vor Änderungen
- Es sollte möglich sein, das Verhalten einer Klasse zu ändern ohne die Klasse selbst zu ändern
- Es sollten private Variablen mit Gettern und Settern verwendet werden – letztere Methoden ausschließlich dann, wenn diese gebraucht werden!
- Es sollten wann immer möglich abstrakte Basisklassen verwendet werden, in denen den erbenden Klassen ggf. abstrakte Methoden zur Implementierung vorgegeben werden
III.) Liskov Substitution Principle (Barbara Liskov, 1998)
- Objekte innerhalb eines Programms sollten austauschbar sein mit Instanzen ihrer Subtypen ohne die Korrektheit des Programmes zu ändern
- Ein Verstoß gegen dieses Prinzip kann oft entdeckt werden mit dem „… ist ein …“-Test: ein Quadrat ist ein Rechteck
- Jedoch: ein Rechteck „ist kein“ Quadrat!
IV.) Interface Segregation Principle
- Interfaces sollten detailliert und client-spezifisch (spezifisch für einen Anwendungsfall) ausgearbeitet sein
- Eine Vielzahl client-spezifischer Interfaces ist besser als ein „Universal-Interface“
- Alle Komponenten sollten fokussiert bleiben und Abhängigkeiten untereinander sollten vermieden werden
- Der Zusammenhang zum Single Responsibility Principle ist offensichtlich: „göttliche“ Interfaces sollten vermieden werden
V.) Dependency Inversion Principle
- Abstraktionen sollten nicht von Details abhängen
- Details sollten von Abstraktionen abhängen
- Es ist wichtig, dass Objekte höherer Ordnung und Objekte niedrigerer Ordnung von derselben abstrakten Interaktion abhängen
- Dependency Inversion nicht mit Dependency Injection verwechseln! Dependency Injection beschreibt, wie Objekte die weitere Objekte erhalten, von welchen sie abhängig sind