Zitat von
mashutu:
Aber ich will vermeiden, dass
Unit A
unit B benutzt UND umgekehrt, weil man es sonst wesentlich schwerer hat modulare Tests zu machen. Solche Zirkelbezuege sind (
IMHO) ueberfluessig und weisen auf Designfehler im Code hin, die ich rechtzeitig erkennen will.
Ich denke auch, dass verborgene Kreuz- und Querbezüge zu schlechter Software führen.
Aber nehmen wir mal M:N Beziehungen - was spricht dagegen, die beteiligten Klassen in je eine
Unit zu packen? Delphi ermöglicht es, mit dem Umweg über implementation und unschöne (aber unvermeidbare) Typecasts.
Selbst in der Praxis gängige Entwurfsmuster (wie z.B. "Besucher") sind ohne zirkuläre Bezüge in Delphi nicht darstellbar, wenn man je Klasse eine
Unit hat. Nachträglich alle Units wieder zu einer 'Monster'-
Unit zusammenzufassen, nur um diese Bezüge zu vermeiden, fiele für mich auch nicht gerade in die Kategorie 'Modernes Design'. Es sind zwei Seiten einer Medaille - Lösungen, die funktionieren, sind nicht immer zugleich auch 'schön'.
Schade, aber es gibt m.W. keine Werkzeuge für Delphi, die Unitabhängigkeiten analysieren und gegen selbst definierte Kriterien prüfen können - z.B. um festzulegen, dass die 'Schichten' der Software nur darunterliegende 'Schichten' aufrufen dürfen. Das wäre bei großen Projekten ein enorm zeitsparendes Werkzeug.