Was kann man aus einem Klassendiagramm lesen?
-
Kann man Aufgrund des allgemeinen Aussehens eines Klassendiagramms auf die Qualität des Desgins schließen? Ist das Design besser, wenn es weniger Abhängigkeiten und Beziehungen unter allen Klassen gibt? Oder kann man sowas garnicht sagen, da es vom Projekt abhängt?
-
Das Design ist gut, wenn man kein Diagramm braucht
-
Das ist doch Quatsch.
Klar kann man am Diagramm erkennen ob das Design gut ist oder nicht. Wenn nicht daran, woran dann? Am fertigem Code? Wohl kaum. Es ist sogar so, dass es Metriken gibt um Design bewerten zu koennen. Eines sollte man aber bedenken: Metrics are not god.
-
Soweit wie Apollon würde ich nicht gehen.
Ich sage: man kann an einem Klassendiagramm erkennen, ob ein Design schlecht ist. Der Umkehrschluß ist nicht zulässig, d.h. ein gutes Design setzt ein gutes Klassendiagramm voraus, ist damit aber noch nicht beendet.
-
Gut, dass die Frage mal aufkommt. Was ist das überhaupt, "gutes Design"?
-
Was gutes Design ist, kann man nicht immer beurteilen. Es gibt sicherlich Schnitzer die man vermeiden sollte, aber im Prinzip kann man nicht sagen "Das ist aber jetzt mal ein schlechtes Design."
Ich kann da nur Bjarne Stroustrup zitieren:
Die Frage "Wie schreibt man ein gutes C++-Programm?" hat sehr viel Ähnlichkeit mit der Frage "Wie schreibt man gute englische Prosa?". Darauf gibt es zwei Antworten: "Wisse, was Du sagen willst" und "Übe. Halte Dich an gute Vorbilder." Beide Antworten gelten für C++ ebenso wie für Englisch -- und sind ebenso schwer zu befolgen.
(TCPL, §1.7)
Habe Ende letzten Jahres ein Projekt übernommen, besser gesagt ein Framework. Und was soll ich sagen? Ich hätte an manchen Stellen etwas anders gemacht!
Aber das was mein Vorgänger gemacht hat, ist besser, als alles andere, was sein Vorgänger gemacht haben. Tja, und wenn sich das jemand anders anschaut, wird ihm das auch nicht gefallen.
-
Hinweise auf gutes Design:
- Klassenstruktur die dem Prinzip folgt: Oberklassen fassen gemeinsame Funktionen zusammen, Unterklassen implementieren die Unterschiede.
- Klare Namensgebung
- sauber definierte Schnittstellen zwischen den Klassen.
- Klassen sollten so sauber gekapselt sein, daß man eine einzelne Klasse komplett austauschen könnte ohne dabei den übrigen Code verändern zu müssen.
- Jede Klasse für sich betrachtet sollte testbar sein (->Stichwort design for testeability)
-
Apollon schrieb:
Das ist doch Quatsch.
Nö. Aber ganz ernst gemeint war es auch nicht (siehe Ende des Postings)
Im Allgemeinen würde ich mich Marc++us anschließen.
-
.filmor schrieb:
Im Allgemeinen würde ich mich Marc++us anschließen.
Da will wer Mod werden
-
Quark.
Das ist einfach so, Apollon hat das Beispiel mit der Prosa ja gebracht, es ist relativ einfach ein schlechtes Design zu erkennen - wenn jeder mit jedem turtelt, die Klassen riesig groß sind, usw. Da sieht man sofort "oje, nicht gut". Interessanterweise kann man aber daraus, daß solche Fehler nicht vorhanden sind, immer noch nicht schliessen, daß das Design gut ist. Denn vielleicht ist die Zerlegung und Zergliederung in sich optimal, passt aber wiederum nicht zum Problemfall, oder modelliert diesen nicht.
-
skals schrieb:
Hinweise auf gutes Design:
- Klassenstruktur die dem Prinzip folgt: Oberklassen fassen gemeinsame Funktionen zusammen, Unterklassen implementieren die Unterschiede.
- Klare Namensgebung
- sauber definierte Schnittstellen zwischen den Klassen.
- Klassen sollten so sauber gekapselt sein, daß man eine einzelne Klasse komplett austauschen könnte ohne dabei den übrigen Code verändern zu müssen.
- Jede Klasse für sich betrachtet sollte testbar sein (->Stichwort design for testeability)
reicht aber nicht aus.
gutes design kommt mit dem essen und läßt sich nicht auf class a, b c, d herunterdiskutieren.
deine allgemeinen aussagen sind in jedem lehrbuch zu finden und natürlich einzuhalten. aber konkret wird man um den dynamischen prozess und manchmal auch den irrweg, das trauen des wegwerfens und des neu machens nicht rumkommen. testen: klar, immer. unit.. zum bleistift.
und manchmal wird man auch die lösung nehmen, die dann doch nicht diejenige.. nach dem lehrbuch ist.bashar: gutes design außerhalb des lehrbuchs: ein ewiger diskussionspozess an einem KONRKETEN PROJEKT mit KONRKETEN ZIELEN, mit der traute, was umzuwerfen und neu zu machen. auf jeden fall bleibts dadurch immer spannend
