Das im Video zu den SOLID-Prinzipien vorgestellte Beispiel der “Bauzeichner 2.0”-Software wird in dieser Übung einmal gründlich gefactored - gemäß der Prinzipien von SOLID und Clean Code.
Alle nachfolgenden Schritte beziehen sich auf das Beispiel-Repo Bauzeichner2.0-CleanCode-SOLID. Das Repo ist so aufgebaut, dass es zwei Java-Projekte enthält.
before_refactoring ist die Version, die DDD- und SOLID-Prinzipien verletzt. Alle entsprechenden Tests
sind rot (bzw. gelb, in IntelliJ). Funktional ist die Implementierung ok (wenn auch unvollständig und
sehr lieblos runtergehauen …), was man daran sieht, dass die funktionalen Unit-Tests im
Package functionaltests grün sind.after_refactoring enthält die Variante nach dem Refactoring.Hinweis: Wegen der zwei Projekte sollten Sie also nicht den Top-Level-Ordner bauzeichner2.0-cleancode-solid
in IntelliJ öffnen, sondern die beiden unterliegenden Ordner before_refactoring und after_refactoring in
zwei verschiedenen IntelliJ-Instanzen.
Schauen Sie sich das Video an, und finden Sie Verstöße gegen die Clean-Code-Prinzipien. Das PMD-Plugin für IntelliJ kann Ihnen dabei helfen.
Machen Sie gemäß unserer Konventionen für die DDD-Schichtenarchitektur ein Refactoring des Übungs-Repos, so dass die DDD-Konventionen eingehalten werden. Denken Sie auch an die Namenskonventionen.
Finden Sie den hauptsächlichen Verstoß gegen das Single Responsibility Principle (SRP) im Code. Beheben Sie ihn.
Finden Sie den hauptsächlichen Verstoß gegen das Open-Closed Principle (OCP) im Code. Beheben Sie ihn.
Finden Sie den hauptsächlichen Verstoß gegen das Dependency Inversion Principle (DIP) im Code. Beheben Sie ihn.