Tach!
- Ist es sinnvoller zu erst ein solches Diagramm zu erstellen und dann zu programmieren? Damit man schon anhand des Diagramms erkennt, ob etwas Sinn macht, wie die Abhängigkeiten sein sollten?
Wenn es dir hilft, dann mach das. Es wäre dann auch sinnvoll, das immer mit dem Code synchron zu halten. Wenn du es (später) immer aus den Klassen automatisch erstellen lässt, dann musst du es nicht dauerhaft aufheben, weil du das ja jederzeit herstellen kannst, wenn du meinst, eins zu brauchen.
- Gibt es eine Regel, welche, wie viele Methoden in eine Klasse sollten und wann man besser eine weitere Klasse erstellt?
Ja, diverse Leute haben diverse Faustregeln formuliert. Aber wichtiger als solche Regeln ist deine persönliche Einschätzung, wann etwas sinnvoll ist und wann nicht. Jedes Projekt hat seine eigenen Anforderungen, und nur du musst damit arbeiten. (Oder dein Team, aber dann musst du es mit dem Team absprechen.)
Wenn du Regeln brauchst, Prinzipien objektorientierten Designs listet viele auf. Die beschreiben aber auch eher qualitative Dinge und keine quantitativen.
Siehe z.B. die Klasse
ReadSheet
. Hier gibt es auch Methoden, die die Google Sheet URL und deren Rückgabe prüfen. Gehört das wirklich ins ObjektReadSheet
oder in eine neue Klasse wieCheckSheetUrl
?
Vielleicht. Vielleicht auch nicht. Für Test Driven Design ist es sinnvoll, nicht zu viel in eine Einheit zu packen, weil der Testaufwand steigt. Für die allgemeine Übersichtlichkeit ist es auch sinnvoll, kleine verständliche Einheiten zu packen. Die Komplexität wird damit aber nicht geringer, sondern veteilt sich nur auf mehr Einheiten. Und damit steigt dann auch der Aufwand, alles unter einen Hut zu bekommen. Das ist dann Abwägungssache, was einem mehr Vorteile bingt.
Mein Wunsch und Ziel ist es auch nach Monaten Abstand von einem Projekt schnell zu erkennen, was es kann, welche "Legosteine" (Klassen, Funktionen) ich zur Verfügung habe, welche ich zusammengebaut habe und ob ich einen Legostein anpassen/erweitern muss oder neuen brauche.
Da hilft vor allem ein gutes Ordnungssystem und aussagekräftige Bezeichnungen. Es ist zum Beispiel wenig sinnvoll, alle Interfaces in ein Verzeichnis zu packen, nur weil es Interfaces sind. Sinnvoller empfinde zumindest ich es, die Einheiten nach fachlichen Kriterien zusammenzufassen. Dann kann man schon anhand der Verzeichnisstruktur sehen, wie das Projekt gegliedert ist, und was zu wem gehört.
dedlfix.