F2047 Zirkuläre Unit-Referenz ?

[mkinzler]

Es geht in Delphi ja. Ist aber ( auch in C# usw. ) nicht sauber.

[oki]

Zitat von omata:

Nur weil etwas geht ist es noch lange nicht sinnvoll.

Die Hinweise, die hier gegeben wurden sind zwar richtig, allerdings nicht sinnvoll.
Solche Zirkelschlüsse sind niemals nötig, wenn man so etwas braucht, hat man etwas grundlegendes falsch gemacht.

Hi omata,

das zirkuläre Bezüge grundsätzlich zu vermeiden sind, aus allen hier benannten Gründen und noch vielen mehr, ist unbestritten. Zu behaupten, dass das nicht sinnvoll ist halte ich aber für Falsch. Leider läßt sich das auch bei sauber Strukturierung nicht immer vermeiden.

Ein Beispiel:

Du proggst ein eigenes Control, dass auf seiner Oberflächen einen Button für ein eigenes Property-Form hat. Somit beinhaltet die Unit in der du deine Komponente schreibst einen Bezug auf die Property-Form-Unit. Diese benötigt jetzt aber einen Bezug auf deine Komponenten, wenn sofort nach dem ändern eines Wertes die Komponente direkt aktualisiert werden soll ohne das Fenster zu schließen.

Dann bin ich gezwungen die Unit der Form im Implementationteil einzubinden, da das Formular ja durch die Komponente kreiert wird. Die Unit der Komponente binde ich im interface-Teil der Form ein, da ich die Instanz des Controls für die Wertezuweisung im Formular brauche.

Die zirkulären Bezüge in diesem Bsp. sind glücklicherweise überschaubar und imho zu verkraften. Wenn du da eine bessere Lösung anbieten kannst, schau ich mir gerne an.

Gruß oki

[mjustin]

Zitat von mkinzler:

Es geht in Delphi ja. Ist aber ( auch in C# usw. ) nicht sauber.

Es geht, wenn man immer alles in eine einzige Unit packt

Wenn man jede Klasse in eine eigene Unit packt, und die Klassen sich wechselseitig referenzieren, weil das halt im Objektmodell (fachliches oder Domänenmodell) so ist, kommt man in Delphi leider nur mit Klimmzügen ans Ziel.
Sauber sind gegenseitige Bezüge im Prinzip schon, und in C#, Java und anderen Sprachen mit später Bindung zum Glück auch problemlos möglich.

Anderes Beispiel: es gibt keinen Weg, das Visitor-Pattern der Gang of Four zu implementieren, wenn die beteiligten Klassen in verschiedenen Units stehen, und man ohne Typecasts arbeiten will.

[oki]

... und selbst mit Typecast muss die Klasse bekannt sein und somit die Unit in der sie definiert ist eingebunden werden.

Gruß oki

[omata]

Zitat von oki:

Du proggst ein eigenes Control, dass auf seiner Oberflächen einen Button für ein eigenes Property-Form hat. Somit beinhaltet die Unit in der du deine Komponente schreibst einen Bezug auf die Property-Form-Unit. Diese benötigt jetzt aber einen Bezug auf deine Komponenten, wenn sofort nach dem ändern eines Wertes die Komponente direkt aktualisiert werden soll ohne das Fenster zu schließen.

Ich würde ja gerne etwas genaueres dazu sagen, allerdings erschliesst sich mir diese Gedankenwelt leider nicht.

Deshalb ganz kurz: Ich würde da eigene Events für schreiben, dann ist auch hier kein Zirkelschluss nötig.

[oki]

Hi omata,

ok, dann mit Events, Kein Problem. Und welche Klassenreferenz übergibst du dann um eine spezielle Eigenschaft deiner Klasse zu setzen?

Gruß oki

[omata]

Zitat von oki:

Und welche Klassenreferenz übergibst du dann um eine spezielle Eigenschaft deiner Klasse zu setzen?

Self, oder Referenzparameter über den Methodenzeiger.

[oki]

Sorry omata, ich glaube wir reden aneinander vorbei. Gib mal ein Beispiel für deine Version.

Hier meine:

Delphi-Quellcode:

unit MyClasses;

interface

type
  TCustomClass = class(TCustomControl)
....


implementation

uses CustomPropertyForm;

...
procedure TCustomClass.ShowPropertyForm;
var PropForm : TPropertyForm;
begin
  PropForm := TPropertyForm.create(nil);
  PropForm.Item := self;
  PropForm.Show;
end;

Delphi-Quellcode:

unit CustomPropertyForm;

interface

uses MyClasses;

type
  TPropertyForm = class(TForm)
  ...
  public
    property Item : TCustomClass read FItem write SetItem;
  ...

Gruß oki

[omata]

Natürlich kannst du hier ein Minimalbeispiel liefern, indem du so einen starken Knebel ansetzt, so dass man da gar keinen anderen Ausweg, als einen Zirkelschluss sieht.
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.

Also muss hier erstmal klar werden, was im Großen möglich sein soll, sonst kann hier natürlich keine sinnvolle Lösung gezeigt werden.

Zum Beispiel: Warum kann die Property auch überschrieben werden? Wäre es da nicht besser den Kontruktur zu überschreiben und den Item somit fest zu initialisieren und nur einen lesenden Zurgiff von außen zu gestatten? Aber das soll jetzt nicht vom eigentlichen Problem ablenken.

Ich muss zugeben, ich sehe noch keinen Sinn in dieser Struktur, das liegt aber wohl nur daran, dass ich bis jetzt solch eine Struktur nicht benötigt habe. Oder aber es liegt einfach daran, dass ich solche Strukturen anders löse und deshalb gar nicht weiss, dass dies hier jetzt eine solche, gewünschte Struktur erfordert.

Also, es kann sehr gut sein, dass wir aneinander vorbeireden.

Gruss
Thorsten

[stoxx]

hier gibts eine recht praktikable Lösung für Sonderfälle, wo es sich mal nicht vermeiden lässt, oder wo einzelne Klassen mal doch nicht hierarchisch gestaltet werden wollen ..


http://www.delphipraxis.net/internal...highlight=unit