Kennen Sie in Eclipse oder NetBeans schon die Funktion Shift+Ctrl+G bzw. Alt+F7 in IntelliJ? Vermutlich denken Sie: Wer diese Funktionen nicht kennt, ist doch wohl kein professioneller (Java-)Entwickler! Zugegebenermaßen ist diese Funktion sehr nützlich, aber ist meiner Erfahrung nach noch mehr: ein Indiz für schlechten Code. Ich stelle immer wieder fest, je unklarer mir eine Klasse erscheint, desto mehr navigiere ich in IntelliJ mit F4 vorwärts, mit Alt+F7 rückwärts in ihrem Umfeld herum in der Hoffnung, dem Sinn und Zweck der unverständlichen Implementierung näher zu kommen. Da das Gehirn nur einen sehr begrenzten Speicherplatz für das Erfassen logischer Zusammenhängen zwischen interagierenden Komponenten hat, stößt derartiges Klassen-Cruisen schnell an seine Grenzen. Also auch auf Klassenebene kann es bereits Anzeichen einer Dependency-Hölle geben. Eine Frage ergibt sich nun zwangläufig: Wie viele Klassen des Umfeldes sollte ich maximal in Betracht ziehen müssen, um die Funktionalität einer Klasse zu verstehen? (Ausnahmsweise) rigoros behaupte ich: keine! Kann das funktionieren? Schauen Sie sich bespielsweise das JDK an. Natürlich kenne ich nicht jede Klasse, aber diejenige Klassen, die ich mir angeschaut habe, verstehe ich ohne Shift+Ctrl+G und F3. Nun mag man entgegnen: Gut, das JDK ist lediglich eine Sammlung von Utilities, unsere Geschäftslogik ist erheblich komplizierter als alle SDKs der Welt zusammen. Und übrigens ist die GUI inzwischen so komplex, die lässt sich nicht einfach auf einzelne verständliche Klassen abbilden.
Ist dem wirklich so? Zugegebenermaßen findet man eine einfache verständliche Lösung selten auf Anhieb, denn wie Friedrich Schiller schon erkannte: Einfachheit ist das Resultat der Reife. Und so verlangen gute Lösungen i.d.R. mindestens zwei (größere) Refactorings. Es gibt aber zumindest einige Best Practices, um etwas schneller ans Ziel zu gelangen.
Benamung
Die Clean-Coder kennen „Separation of Concerns“ und „Single Responsibility Principle“. Neben KISS und YAGNI sind dies für mich die wichtigsten Clean-Coder-Prinzipien überhaupt.
Der Switch On/Off-Pattern.
State nicht verteilen. Nur im synchronen Fall beherrschbar.
Objekt-Orientierte Programmierung viele Zustand-Automaten interagieren und ändern auf wilde Art gegebseitige ihre Zustände. Daten und Funktionen gehören zusammen.
Funktional: Der Eingang der Funktion ist nur durch die Parameter gegeben, es wird kein Zustand gehalten. Daten und Funktionen sind getrennt.
Die Klasse als Konstrukt hat eine ordnende Funktion, indem sie nahelegt, einen Belang damit abzubilden => separatiion von Concerns wird gefördert.
Auch beim Objekt-Orientierten Design wäre es schön, wenn man funktional Denken würde und eine Separation so vornehmen würde, dass die Konfiguration und die Eingabeparameter klar sind. Jeder Teil der Software muss klar sein, wie ich ihne konstruiere und wie ich ihn aufrufe.
Die Main-Methode. Besser als Test. Beispiel: EIn Menü. Ein Test würde auf dem ViewModell aubeiten und schauen, ob dort die richtige Werte angekommen sind.
Drei blogs: Shift+Ctrl+G, Main-Methode, und Phänomen: Ich ändere,
aha, so müsste es gehen, ne wieder nicht.
Meiner Meiung nach gibt es einige einfache Prinzipien, die dies dennoch ermöglichen
Nun einen Punkt des
Der Fehler verschwindet einfach nicht
Tipp: schreiben Sie die Komponenten in einem eigenen Projekt, auf Ihrem Laptop, das verhindert Depencies.
Wiederverwendung ist schön, aber nur wenn es keine zusätziche Dependency erfordert.