Forward in Klassen funktioniert nicht

[ATS3788]

Hallo ich mache da wohl einen Denkfehler und komme nicht drauf

Delphi-Quellcode:

type
  // Define the classes in this Unit at the very start for clarity
  TForm1 = Class;          // This is a forward class definition


  TFruit = Class(TObject)  // This is an actual class definition :
    // Internal class field definitions - only accessible in this unit
     private
       t        : TForm1;  // Warum ist die variable ungültig !
       isRound  : Boolean;
       length   : single;
       width    : single;
       diameter : single;
    // Fields and methods only accessible by this class and descendants
    procedure SetForm(const Value : TForm1);
     protected
    // Externally accessible fields and methods
     public

      // 2 constructors - one for round fruit, the other long fruit
       constructor Create(diameter : single);               overload;
       constructor Create(length : single; width : single); overload;
    // Externally accessible and inspectable fields and methods
     published
      // Note that properties must use different names to local defs
       property round : Boolean
         read   isRound;
       property len   : single
         read   length;
       property wide  : single
         read   width;
       property diam  : single
         read   diameter;
  end;                    // End of the TFruit class definition

  // The actual TForm1 class is now defined
   TForm1 = Class(TForm)
    Button1: TButton;
    Button2: TButton;
     procedure FormCreate(Sender: TObject);
     procedure ShowFruit(fruit : TFruit);
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
   private
    // No local data
    f : TFruit;
   public
    // Uses just the TForm ancestor class public definitions
   end;

 var
   Form1: TForm1;

 implementation

 {$R *.dfm}

// Create a round fruit object
 constructor TFruit.Create(diameter: single);
 begin
  // Indicate that we have a round fruit, and set its size
   isRound       := true;
   self.diameter := diameter;
 end;

// Create a long fruit object
 constructor TFruit.Create(length, width: single);
 begin
  // Indicate that we have a long fruit, and set its size
   isRound     := false;
   self.length := length;
   self.width  := width;
 end;


 procedure TFruit.SetForm(const Value : TForm1);
 var
 f1 : TForm1;
 begin
   t := nil;  // Nicht mal das geht
   f1 := Value; // Das würde gehen
   t := Value; // und das ist der Grund für den Eintrag
 end;


// Form object - action taken when the form is created
 procedure TForm1.Button1Click(Sender: TObject);
begin
FormCreate(Sender);
end;

procedure TForm1.Button2Click(Sender: TObject);
 var
 Fruit : TFruit;
begin
 Fruit := TFruit.Create(23);

  ShowFruit(Fruit);
end;

procedure TForm1.FormCreate(Sender: TObject);
 var
   apple, banana : TFruit;
 begin
 f.SetForm(self);

  // Let us create our fruit objects
   apple  := TFruit.Create(3.5);
   banana := TFruit.Create(7.0, 1.75);

  // Show details about our fruits
   ShowFruit(apple);
   ShowFruit(banana);
 end;

// Show what the characteristics of our fruit are
 procedure TForm1.ShowFruit(fruit: TFruit);
 begin
   if fruit.round
   then ShowMessage('We have a round fruit, with diam = '+
                    FloatToStr(fruit.diam))
   else
   begin
     ShowMessage('We have a long fruit');
     ShowMessage('    it has length = '+FloatToStr(fruit.len));
     ShowMessage('    it has width  = '+FloatToStr(fruit.wide));
   end;
 end;

 end.

http://www.delphibasics.co.uk/RTL.asp?Name=Class
Ich habe das Beispiel ein wenig abgeändert
Meine Frage wie kann ich dem Object TFruit
mitteilen das TForm1 Object mitteilen.

[Dejan Vu]

Welche Meldung kommt?
Das Feld 't' wird nicht verwendet (dem Wert wird nur etwas zugewiesen), vielleicht meckert dein Delphi darüber...

[bcvs]

Dein Ansatz ist schon richtig, Du musst nur das Object f erst erzeugen, bevor du darauf zugreifst:

Delphi-Quellcode:

f:=TFruit.Create(0);
f.SetForm(self);

Und du musst dafür sorgen, dass f irgendwo wieder freigegeben wird, am Besten im OnDestroy.

[bernau]

Warum muss TFruit eigendlich etwas von TForm1 wissen? Du greifst in TFruit in keiner Procedure auf TForm1 zu.

OK. Quellcode ggf. nicht komplett. Ich rate mal. Wenn du auf der Form irgend etwas von TFruit anzeigen möchtest, dann konnte die Form das selber übernehmen. Du brauchst nur ein TNotify-Event anlegen. Damit kann TFruit dem TForm1 mitteilen, daß was geändert wurde und Form1 zeichnet selber.

P.S.: Ich will nicht etwas gegen Forwarding sagen. Verwende ich selber sehr oft. Kommt aber auf die Situation an.

[DeddyH]

Das sehe ich ähnlich. Für mich hat Klassenforwarding ein Geschmäckle, denn es wird meist dazu benutzt, Klassen untereinander bekannt zu machen. Das ist zwar nicht in jedem Fall immer einfach zu umgehen, elegant ist das IMO allerdings nicht.

[BadenPower]

Zitat von DeddyH:

Für mich hat Klassenforwarding ein Geschmäckle, denn es wird meist dazu benutzt, Klassen untereinander bekannt zu machen.

Dann darfst Du aber nicht programmieren, denn die halbe VCL kann nur durch voherige Bekanntmachung weiterer Klassen funktionieren.


Class-Forwarding heisst ja nur, "Hallo mich gibt es".

[DeddyH]

Nur weil im letzten Jahrtausend etwas in der VCL gemacht wurde, heißt das ja noch nicht, dass das auch gut ist.

[BadenPower]

Zitat von DeddyH:

Nur weil im letzten Jahrtausend etwas in der VCL gemacht wurde, heißt das ja noch nicht, dass das auch gut ist.

Eine gute Lösung ist aber immer dann eine gute Lösung, wenn es keine andere Lösung gibt.

Oder wie würdest Du sonst Abhängigkeiten untereinander bekanntmachen?
Jetzt nicht speziell für Delphi, sondern auch gerne ganz allgemein.

[DeddyH]

Zitat von BadenPower:

Abhängigkeiten untereinander

Genau das ist doch der Knackpunkt. Hier würde ich mich bereits fragen, ob das wirklich sein muss oder nicht doch auch anders geht.

[BadenPower]

Zitat von DeddyH:

Zitat von BadenPower:

Abhängigkeiten untereinander

Genau das ist doch der Knackpunkt. Hier würde ich mich bereits fragen, ob das wirklich sein muss oder nicht doch auch anders geht.

Ja das muss sein.

Selbst das Leben besteht nur, weil es solche Abhänigkeiten kennt.

Da gibt es die Klassen "Sperma", "Eizelle" und "Mensch". Die Klasse "Mensch" sogar in den Unterklassen "Männlich" und "Weiblich".

"Mensch" muss entwerder "Sperma" oder "Eizelle" kennen. "Eizelle" muss "Sperma" kennen und umgekehrt, sonst wissen die gar nicht, dass sie zusammenfinden müssen. Haben sie sich gefunden, dann müssen sie aber wiederum die Klasse "Mensch" kennen, den sie zusammen daraus entwickeln wollen.

Ich will jetzt erst gar nicht auf die Proceduren der Unterklassen "Männlich" und "Weiblich" eingehen, welche es "Sperma" und "Eizelle" ermöglichen sich zu treffen.