uses im interface und implementation-Teil

[Tyrael Y.]

Den letzten Beitrag von muetze nicht überlesen hier

...eine Anmerkung hab ich noch dazu

Wieso mache ich mir nicht eine Unit in der ich alle von mir benötigten Variablen global definiere? Ich passe einfach auf, dass ich JEDE Variable hier definiere und dabei alle Variablen alphabetisch anordne, so dass einen kleinen Überblick darüber habe....dann brauch ich auch nur noch an einer Stelle zu suchen....

weil?...ok mehr Speichernutzung...und sonst?....genau...ich benutze alles nur da, wo ich es auch brauche

[uligerhardt]

Zitat von mashutu:

Ich will zirkulaere Bezuege gaenzlich vermeiden und moechte daher, dass der Compiler den Entwickler auf diesen Misstand aufmerksam macht.

Nur mal, um sicher zu gehen, dass ich dich recht verstehe - du möchtest so etwas

Delphi-Quellcode:

TControl = class(TComponent)
  property Parent: TWinControl read FParent write SetParent;
end;
  
TWinControl = class(TControl)
  property Controls[Index: Integer]: TControl read GetControl;
end;

vermeiden?

Uli.

[mashutu]

Zitat von uligerhardt:

Nur mal, um sicher zu gehen, dass ich dich recht verstehe - du möchtest so etwas

Delphi-Quellcode:

TControl = class(TComponent)
  property Parent: TWinControl read FParent write SetParent;
end;
  
TWinControl = class(TControl)
  property Controls[Index: Integer]: TControl read GetControl;
end;

vermeiden? :mrgreen:
Uli.

Nein so etwas will ich nicht vermeiden. 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.

[taaktaak]

Hmmm, meine Verwirrung steigt
Was haben zirkuläre Referenzen mit globalen Variablen und der Sichtbarkeit von Klassen im Sinne der hier zur Diskussion gestellten Vorgehensweise zu tun? Das einzige Gegenargument, was ich bisher nachvollziehen konnte ist das von Muetze: Verlangsamung der Compilierung bei > 2 Mio Codezeilen....

[Phoenix]

Zitat von mashutu:

Nein so etwas will ich nicht vermeiden. 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.

Derartige Bezüge sind bei einem wirklich sauberen Code-Design (= 1 Klasse -> 1 Unit) sogar zum Teil absolut notwendig.

Ausserdem gibt es nur einen einzigen Grund, warum der Delphi-Compiler in diesem Moment meckert: Delphi ist ein Single-Pass Compiler und würde sonst in eine Endlosschleife rennen. Wäre es ein Multipass-Compiler, dann würde er sich gar nicht erst an der ersten Unit-Liste aufhalten, sondern gleich den Interface-Teil parsen, und erst wenn er einen unbekannten Typen entdeckt die vorher angegebenen Units danach durchsuchen.

Wenn die andere Unit hingegen im implementation-Teil steht, dann hat er bereits alle notwendigen Typen der Klassendeklaration geparst und kann gefahrlos weiterarbeiten.

Solche Referenzen sind in der sauberen, strukturierten Programmierung üblich, ein wichtiges Hilfsmittel und lassen sich auch ohne Probleme automatisiert testen.

Du würdest (bei einem sauberen Code-Design (nochmal: genau eine Klasse gehört in genau eine Unit) damit sämtliche Forward-Declarations verbieten. Andersrum: Wenn Du nach genau dieser Regel konsequent arbeiten würdest, hättest Du in Deinen Units keine Forward-Declarations mehr. Entferne mal alle und gucke, ob es sich dann noch kompilieren lässt.

Dein Kollege hat im übrigen vollkommen recht: Die Uses-Listen sollten immer optimiert sein, keine unnötigen Units enthalten und wenn eine Unit nur in der Implementierung benötigt wird, dann ist es sauber, sie auch nur dort einzubinden wo sie benötigt wird. Andernfalls könnte es nämlich insbesondere hier bei Delphi sogar passieren, dass unter Umständen eine initialization-Teil einer Unit zu früh durchlaufen wird, weil sie oben im Interface stand anstelle im Implementation. Mal von der Compilergeschwindigkeit (und insbesondere dem Speicherverbrauch beim Kompilieren und Linken) abgesehen.

Das Hilfsmittel, um die Uses-Klauseln korrekt zu sortieren und in Deinem Fall hoffentlich schnellstmöglich das unnötige Zeug raus- und das falsch Platzierte in den implementation-Teil zu verschieben heisst Icarus Uses List Analyzer, was nicht umsonst sagt, welche Uses entfernt und verschoben gehören-

[taaktaak]

Ich möchte mashutu nicht vorgreifen, aber:

Das im interface keine unnötigen Units aufgeführt werden, ist doch eigentlich selbstredend.

Im übrigen entnehme ich der bisherigen Diskussion, dass zirkuläre Bezüge von den Profis nicht für schlechtes Design erachtet werden und manchmal sogar notwendig sind - korrekt?

Ist es dann bereits ein unprofessioneller Denkansatz, zirkuläre Bezüge -wann immer es geht- zu vermeiden?

[Tyrael Y.]

Zitat von taaktaak:

Was haben zirkuläre Referenzen mit globalen Variablen und der Sichtbarkeit von Klassen im Sinne der hier zur Diskussion gestellten Vorgehensweise zu tun?.

Laufen tut vieles, sauber ist nicht alles.

Zitat von taaktaak:

Im übrigen entnehme ich der bisherigen Diskussion, dass zirkuläre Bezüge von den Profis nicht für schlechtes Design erachtet werden und manchmal sogar notwendig sind - korrekt?

Exakt. Zirkuläre Aufrufe sind oft gewollt und völlig sauberer Code.

[Phoenix]

Zitat von taaktaak:

Ist es dann bereits ein unprofessioneller Denkansatz, zirkuläre Bezüge -wann immer es geht- zu vermeiden?

Jain. "Wann immer es geht" ist zu hart. Dieser Ansatz dazu führen, dass man sich beim Designen einen abbricht und einen Workaround einbaut, um eine Rückreferenz zu vermeiden. Nur führt dieser Workaround dann in aller Regel zu (viel) mehr Code, als eigentlich notwendig ist. Mehr Code = mehr Stellen, wo Fehler sein können. Mehr Code = mehr zu warten. Mehr Code = mehr zu testen. Und das liesse sich durch eine einfache Rückreferenz vermeiden.

Das ganze lässt sich im übrigen aber tatsächlich in 90% aller Fälle relativ einfach vermeiden: Man definiert ein Interface, und inkludiert dieses Interface in alle beteiligten Units. Interfaces sind nicht das Allheilmitteln, aber an der Stelle in den allermeisten Fällen das korrektere Hilfsmittel als überkreuzende Bezüge. Aber es gibt eben stellen, da macht auch ein Interface weniger Sinn als ein Rückbezug (insbesondere, wenn es um einen Typen geht, der nur einmal benutzt wird).

[taaktaak]

Ok, dieser Argumentation kann ich (zustimmend) folgen - Danke!

PS: Interfaces sind für mich derzeit (noch) ein völlig unbekanntes Terrain. Habe daher bisher im Bedarfsfall mit Botschaften gearbeitet um zirkuäre Bezüge zu vermeiden - und dies in den konkreten Anwendungsfällen auch als übersichtlich und wartungsfreundlich angesehen.

[mjustin]

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.