Frame: Button OnClick handler manchmal nicht zugewiesen?

[bernau]

Zitat von Uwe Raabe:

Weiterer Bonus: Man kann die Frame-Units in die Uses-Clause des Implementation Teil verlagern oder gleich die Frames über ein Factory-Pattern erzeugen. Das reduziert den Dependency-Wert oft gewaltig und sorgt nebenbei für eine strukturiertere Architektur.

Sollte man nicht units im Implementation-Teil vermeiden. Die Gefahr der zirkulären Abhängigkeit wird damit reduziert, wenn man die Units im Interface-Abschnitt auflistet.



Siehe auch https://docwiki.embarcadero.com/RADS..._Units_(Delphi)

Zitat:

To reduce the chance of circular references, it's a good idea to list units in the implementation uses clause whenever possible. Only when identifiers from another unit are used in the interface section is it necessary to list that unit in the interface uses clause.

[Uwe Raabe]

Zitat von bernau:

Sollte man nicht units im Implementation-Teil vermeiden. Die Gefahr der zirkulären Abhängigkeit wird damit reduziert, wenn man die Units im Interface-Abschnitt auflistet.

Davon bin ich ein strikter Gegner! Das ist zwar einfacher für den Entwickler, unterstützt aber meiner Meinung nach nur die Faulheit nicht über eine entsprechende Architektur nachdenken zu müssen.

[Uwe Raabe]

Abgesehen davon sagt das Zitat das genaue Gegenteil von dem was es meint...

[himitsu]

Ja, ich versuche auch immer ALLES, was möglich ist, im Interface anzugeben.
Da ist dann auch die Reihenfolge sichergestellt.

Es gibt aber auch Kollegen, die sind vehement der Meinung, dass man ALLES was möglich ist, in die Implementation machen MUß!


Im Interface wird ALLES so wie es da steht, in der Reihenfolge vor der eigenen Unit geladen/initialisiert.
Wenn etwas in den eingebundenen Units geladen wird, dann das natürlich entsprechend auch wieder zuerst.

In Implementation kann unterliegt die Reihenfolge im USES dem Gutdünken des Compilers und es kann sogar passieren, dass Units erst nach dem eigenen Initialization, bzw. nach eigenen Class-Constructor's vorhanden ist.
Greift man also im Initialization/ClassConstructor auf eine Variable/Funktion zu, kann es sein, das diese noch garnicht initialisiert ist, wenn die Unit im Implementation steht ... wenn in Interface, dann ist es immer schon da.
Genau andersrum beim Finalizaition, da kann es, wenn im Uses der Implementation, dann schon weg sein, bevor das eigenen Finalization/ClassConstructor anläuft.

[Uwe Raabe]

Zitat von himitsu:

Es gibt aber auch Kollegen, die sind vehement der Meinung, dass man ALLES was möglich ist, in die Implementation machen MUß!

Genau! Und das ist auch richtig
Damit verbirgt man die Details der Implementierung, die ja niemanden was angehen.

Natürlich gibt es keine Regel ohne Ausnahme, aber für mich gehört nur das in den Interface-Teil was da unbedingt nötig ist. (We agree to disagree)

[himitsu]

Zitat:

Damit verbirgt man ...

Security through Obscurity


Im Idealfall hab ich so aber auch nur ein Uses, was ich irgendwie schon bissl übersichtlicher empfinde.


Im Interface ist es immer in der selben Reihenfolge.
In der Implementation könnte, selbst bei unverändertem Code, bei jedem Compilieren was in einer anderen Reihenfolge geladen werden, was bei einer Fehlersuche besonders viel Spaß macht.

Aber das Wichtigste, im Interface habe ich nie "ausversehn" mal unbemerkte Kreisreferenzen drin ... in der Implementation fällt dir das nie auf,
außer da unten steht nur das drin, was absichtlich dort steht, wegen einer bekannten Kreuz-/Kreisreferenz.

[Uwe Raabe]

Zitat von himitsu:

Security through Obscurity

Eher Information hiding.

Zitat von himitsu:

In der Implementation könnte, selbst bei unverändertem Code, bei jedem Compilieren was in einer anderen Reihenfolge geladen werden

Das kann nur bei zyklischen Abhängigkeiten passieren, aber die lassen wir ja nicht zu.

Zitat von himitsu:

im Interface habe ich nie "ausversehn" mal unbemerkte Kreisreferenzen drin ... in der Implementation fällt dir das nie auf,

Das ist genau das obige Argument mit der Faulheit. Bei einer sauberen Architektur entstehen erst gar keine Zyklen und zur Sicherheit gibt es ja Code-Checks, die das spätestens beim Einchecken monieren.

Aber ich denke, das Thema ist zumindest hier nun ausreichend diskutiert. Wir können das gerne an anderer Stelle vertiefen wenn du möchtest.

[bernau]

Zitat von himitsu:

Aber das Wichtigste, im Interface habe ich nie "ausversehn" mal unbemerkte Kreisreferenzen drin ... in der Implementation fällt dir das nie auf, außer da unten steht nur das drin, was absichtlich dort steht, wegen einer bekannten Kreuz-/Kreisreferenz.

Genau so. Das hat auch nichts mit Faulheit zu tun. Es ist lediglich eine Hilfe, das diese "schrecklichen" zirkulären Referenzen sich nicht einschleichen.

[Frickler]

Zitat von bernau:

Sollte man nicht units im Implementation-Teil vermeiden. Die Gefahr der zirkulären Abhängigkeit wird damit reduziert, wenn man die Units im Interface-Abschnitt auflistet.

Nee genau andersherum. Steht da doch auch:

Zitat:

To reduce the chance of circular references, it's a good idea to list units in the implementation uses clause whenever possible. Only when identifiers from another unit are used in the interface section is it necessary to list that unit in the interface uses clause.