Units überkreuzt - ist das ok?

[Alallart]

Ich habe es bisher selbst noch nie gemacht, weiß aber, dass es geht - ich meine die die Units überkreuzt eintragen.

Um was geht es? Meine Unit1 ist inzwischen etwas voll. Deshalb dachte ich einige Teile in eine zweite Unit auszulagern (Unit2). In den Prozeduren wird aber auf einige Komponenten der Unit1 zugegriffen, zb ist die CheckBox1 Checked?

Damit ich die Prozeduren der Unit2 aufrufen kann, habe ich sie in Unit1 eingetragen. Damit aber in Unit2 auf die Komponenten der Unit1 zugegriffen werden kann, habe ich in Unit2 die Unit1 eingetragen.

Meine Frage ist: ist das Ok, oder kann es später zu Problemen kommen? Um was es mir geht ist letztendlich alles etwas übersichtlicher zu gestalten, also auf zwei oder drei Units aufzuteilen.

[Bernhard Geyer]

besser soweit trennen das man ohne Überkreuzbezug auskommt, auch wenn man 3 Units benötigt.

[Jasocul]

Technisch ist das zwar OK, aber für mich ein NoGo.
Auf lange Sicht endet das oft im Chaos und ist meiner Meinung nach ein Zeichen von schlecht strukturiertem Code.

[Uwe Raabe]

Mit dem entsprechenden Design lässt sich so eine zyklischen Unit-Referenz in der Regel vermeiden. Obwohl sowas prinzipiell geht, versuche ich das weitestgehend zu vermeiden. Bei Projekten, in denen das über einen langen Zeitraum akzeptiert oder gar bewusst praktiziert wurde, kann das schon mal etwas aufwändiger werden. Bisher hat sich das Auflösen solcher Zyklen aber immer als vorteilhaft dargestellt. Deswegen würde ich hier gleich zu einem entsprechenden Design raten, bei dem keine Zyklen vorkommen.

Bill Meyer geht in seinem Buch Delphi Legacy Projects: Strategies and Survival Guide auf die Nachteile solcher UDC (Unit Dependency Cycles) ein. In einer Präsentation schreibt er:

Zitat:

Long Build Times
•At some point, large projects may begin to suffer long build times.
• These build times are the result of Unit Dependency Cycles (UDCs).
•A UDC is created when UnitA uses UnitB, which uses UnitA.
•In a large project with many UDCs, once the build times begin to
increase, the problem will multiply.
•UDC effect on builds is an exponential burden. The exponent is small,
but any exponent will eventually become a burden.

[Alallart]

Aus diesem Grund habe ich es bisher auch immer vermieden.

Allerdings will ich zu meiner Ehrenrettung sagen, dass ich nicht auf Prozeduren, Funktionen oder Variablen der Unit1 aus der Unit2 zugreife, sondern lediglich einige Prozeduren auslagere. Solche die in sich abgeschlossen sind und nicht auf andere Prozeduren zugreifen.

[himitsu]

Es gibt auch viele, die möglichts alle Units zwanghaft in die Implementation schreiben (abgesehn wo es nicht anders geht, weil sie im Interface benötigt wrden).

Ich mach möglichst alles ins USES des Interfaces. (abgesehn, da wo absichtliche eine Kreuz-/Kreisreferenz nötig ist)
* hier weiß ich einmal wo es eine Kreuzung gibt
* und normal habe ich auch alle Units zusammenstehend, also sehe sofort was Alles eingebunden ist (ohne immer in zwei USES gucken zu müssen)

* außerdem sind in Initialization und in Class-Constructor immer alle Units des Interaces initialiert
* für Units in der Implementation kann die Initialisierung auch erst nach meiner Unit passieren
* bei Finalization und Class-Destructor andersrum, also fremde Units werden immer nach mir Finalisiert (ich kann sie bei mir also noch benutzen)

* Und steht dagegen alles in der Implementation, dann weiß niemand, ob es eine Kreutung gibt, oder nicht

[jaenicke]

Ja, ich finde auch, dass die Vorteile überwiegen, wenn man alles unter interface in die uses schreibt.

[bernau]

Zitat:

Zitat von jaenicke (Beitrag 1523139)

Ja, ich finde auch, dass die Vorteile überwiegen, wenn man alles unter interface in die uses schreibt.

Bei mir auch so :thumb: