Kommando retour!?

Monsterklassen

Ich hätte mir wohl bevor ich ans Werk gehe das Softwareentwicklungs-Tutorial genauer durchlesen sollen. Das Problem, das mir gerade beim Lesen gekommen ist, ist vielfältiger Natur:

• Die meisten meiner Klassen sind zu komplex
• Die Klassen sind nicht sauber nach Boudary-/Controller-&Entity-Klassen getrennt. Sehr häufig verrichtet eine einfache Entity-Klasse zusätzlich Aufgaben von Boundary- oder Controller-Klassen. So zum Beispiel die eigentlich als Entity-Klasse gedachte User-Klasse. Sie sollte eigentlich nur die Stammdaten, das Registrierungsdatum, etc. abspeichern, die toString()-methode als Abstrakte Methode versehen und als superklasse für die 3 anderen Entity-Klassen Sklave, Herr und Gott dienen. Mit der Zeit haben sich aber auch Funktionen dazugesellt, von denen ich mir anscheinend nicht vorstellen konnte, dass man sie in eine eigene Klasse kapseln könnte. Nun habe ich aber gerade Folgendes gelesen und das hat mich skeptisch bezüglich meinem Klassendiagramm gemacht:

Alle Funktionen die Sie besitzen haben unmittelbar mit den gespeicherten Daten zu tun (das schließt durchaus Datenmanipulation ein). Sobald aber andere Klassen gerufen werden müssen, ist die Funktion mit großer Sicherheit bei der Entity-Klasse falsch postiert. [...] Eine Funktion ‘getName’ gehört ganz klar zu ‘Mitarbeiter’. Auch ‘getTelefonNummerAsString’ ist OK, denn es werden nur die Informationen der Entity-Klasse in veränderter Form zurückgegeben. Eine Funktion ’setAnschrift’ kann OK sein, wenn nur die Anschrift geändert wird. Falls aber im Zuge der Anschriftsänderung auch die Personalabteilung über die Änderung benachrichtigt werden soll, ist es besser die Methode als ‘AendereAnschrift’ einer Control-Klasse zu geben, und die „Set“-Funktion für die Anschrift so einfach wie möglich zu halten.

• Boundary-Klassen sind im Prinzip gar nicht vertreten. Vor allem, wenn man liest, dass kein Akteur das System ohne Boundary-Klassen benutzen kann, da dort die User-interkationen (GUI-Elemente, Formulardaten, Checkboxen etc.) gekapselt sind. Das müssen wir nachholen.

Was mir zum Verständnis auch noch etwas geholfen hat, war folgender Satz bezüglich Boundary-Klassen und ihr Verhältnis zu den anderen Klassen:

[N]iemand kann direkt auf sie Zugreifen. Alle Aktionen von außen werden von Boundary-Klassen aufgenommen, an Control-Klassen weitergeleitet und erst dann an die Entity-Klassen übergeben. Entity-Klassen sind meist auch sehr allgemein gehalten. Spezielle Funktionalitäten werden (wie oben gezeigt) an Control-Klassen übergeben.

Pointiert gesagt: Die meisten meiner identifizierten Klassen sind ein Gemisch von allen drei Klassentypen, und genau das ist es ja, was man nicht haben will. Man will ja, zwecks Übersichtlichkeit und Wiederverwendbarkeit überschaubare, kleine Klassen, um den sogenannten „Big Ball of Mud“ zu verhindern, was heißt: das System leicht verstehbar, wartbar, veränderbar zu machen und die Komplexität in den Griff zu bekommen. Da müssen wir wohl nochmal ran.

Konsequenzen:

Was heißt das nun für uns?

Gottseidank haben wir es mit einem iterativen und inkrementellen SWE-Prozess zu tun, der es ja gerade ermöglichen soll, Fehler dieser oder anderer Art leicht zu beheben, da man noch nicht das komplette System entwickelt hat.

Da wir gleich ein Meeting haben, müssen wir uns überlegen, wie wir mit der vorliegenden Version umgehen wollen. Das Überblicks-Klassendiagramm und das halbe Sequenzdiagramm, das ich erstellt habe, sind zumindest die Dokumentation dafür, dass gearbeitet wurde. Die Frage ist nur, was wir heute in der Übung vorstellen werden?

Das einfachste wäre, das Sequenzdiagramm zu vervollständigen (+ die anderen Diagramme dazuzuzeichnen) und bei der Vorstellung den Hinweis zu geben , dass wir draufgekommen sind, dass die Klassen zu monströs sind und wir das überarbeiten werden.

Das aufwändigere wäre, alles von 0 auf neu zu machen und die verschiedenen Klassentypen gleich zu berücksichtigen, wobei sich die Frage stellt, ob wir das bis zum Beginn der Übung (wir haben ca. 2,5 Stunden) schaffen?

Ich optiere für die einfachere Lösung, zumal unsere Motivation (aufgrund der mangelnden Bierspenden) ohnehin im Keller ist ^^ und Stress außerdem ungesund ist.