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.

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.

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.

- 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)

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.

Im Allgemeinen würde ich mich Marc++us anschließen.

Da will wer Mod werden

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.

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