F2047 Zirkuläre Unit-Referenz ?

[oki]

Moin omata,

zur Sicherheit vorweg. Falls jemand den Eindruck haben sollte ich will streiten, is nicht so. Sollte der nächste Satz zu hart klingen, positiv sehen.
So, du umschreibst immer schön wortreich, das das nie nötig ist. Auf konkrete Beispiele zeigst du aber keine neue Herangehensweise. Ich hab das Beispiel jetzt mal schnell hingetippt. Da mach ich mir keine tieferen Gedanken, ob das Property readonly und der Constructor überschrieben sein sollte. Hier geht es darum, ob sich zirkuläre Bezüge grundsätzlich immer vermeiden lassen. Ich habe auch nicht irgendein Stück Code hingeschrieben wo das dann auch einfach nur so ist, sondern im Vorfeld erläutert, um welchen Ansatz es geht.
Da ich auch nicht den Stein der Weisen gefunden habe, bin ich gerne bereit an dieser Stelle zu lernen. Aber dann bitte mit konkreten Lösungsvorschlägen. Wie löse ich das Problem, wenn eine Klasse durch eine eigene procedure sein Eigenschaftenfenster aufruft, (von mir aus auch eine mitgegebene Fensterinstanz) in der seine Eigenschaften angezeigt und verändert werden können. Dabei helfen Aussagen wie

Zitat:

Aber das war ja gerade mit "grundlegend" gemeint, kann man das was man erzeugen will auch strukturiert realisieren? Das war und ist die Intention, und da kann man ganz klar sagen, das geht und zwar immer. Es muss keine Frikellösung her. Das ist nicht nötig. Natürlich muss man dann einen Moment länger über die Lösung nachdenken.

Dann bitte her mit der Lösung. Von mir auch grundlegend. Du darfst auch gerne länger nachdenken.

Manchmal habe ich so viele eigene Klassen, dass ich für die Übersicht diese in einzelne Units auslager. Selten, aber manchmal, nehme ich dann zähneknirschend einen Zirkulären Bezug in Kauf. Der Vorteil der Übersichtlichkeit überwiegt.

Um es nochmal klar zu stellen, ich halte zirkuläre Bezüge für keine gute Sache und versuche sie generell zu vermeiden. Auf jedes Beispiel pauschal mit denk dir was besseres aus zu antworten ohne konkrete Lösungsansätze zu bringen halte ich für nicht richtig. Helfen tut es auch keinem. Nebenbei bemerkt hab ich festgestellt, dass sich auch in älteren Threads Mitglieder mit diesem Thema beschäftigt haben, denen ich so einiges zutraue.

Also omata, so sehr ich deine fachlichen Hinweise in anderen Threads schätze, bitte keine hoch gestochenen Pauschalweisheiten, sondern konkrete Strategie-, Design- und Lösungsansätze. Und wenn es für die angeführten Beispiele ist.

Gruß oki

[omata]

...

[oki]

Hi omata,

schau ich mir heute Abend an, versprochen.

Gruß oki

[oki]

Hi omata

Klar, wenn ich das Formular aus der Hauptanwendung starte, dann erledigt sich das natürlich mit dem zirkulären Bezug. Mir ging es hier aber explizit um den Aufruf des Formulars aus der Klasse heraus. Natürlich gebe ich dir recht, dass es immer (fast immer; kann mich da nicht fest legen) einen Weg gibt das zu umgehen. Ich habe aber Situationen gehabt, da war es einfacher und sinnvoller einen zirkulären Bezug in Kauf zu nehmen.

Ich denke mal, dass ich meine Aussage entschärfe. Zirkuläre Bezüge können vermieden werden, sind aber unter speziellen Umständen akzeptabel.

Dann gute Nacht und Gruß

oki

[omata]

Zitat:

Zitat von oki

Klar, wenn ich das Formular aus der Hauptanwendung starte, dann erledigt sich das natürlich mit dem zirkulären Bezug. Mir ging es hier aber explizit um den Aufruf des Formulars aus der Klasse heraus.

Ohne da jetzt noch weiter drauf rumzureiten...

Trotzdem nochmal ein neues Beispiel.
Und das meinte ich mit "grundlegend", wenn ich soetwas machen möchte, warum nicht das Control als Form auslegen?

[nicodex]

Letzendlich kann man sich immer in einer dritten Unit eine (abstrakte) Schnittstelle definieren.
Die Frage ist nur, ob sich der Aufwand immer lohnt. Wenn die Möglichkeit besteht, dass die Funktionalität irgendwann getrennt, verändert oder erweitert wird, dann sollte man sich die Arbeit machen.