Forward in Klassen funktioniert nicht

[bernau]

Zitat von BadenPower:

Zitat von Dejan Vu:

In der Softwareentwicklung müssen die Klassen nichts voneinander wissen.

Und wie nutzt man eine Klasse, welche niemand kennt?

Was glaubst Du für was die Uses-Klausel da ist. Um Klassen vor einander zu verstecken, oder dafür, dass die Klasse von anderen Klassen erfährt?

Es geht nicht darum, daß keiner keinen kennt. Das voneinander Wissen sollte nur in eine Richtung gehen.

Klasse A kennt Klasse B aber nicht umgekehrt.

Zum Thema Uses: Wenn ich eine Procedure aus den Sysutils verwenden möchte, dann sollte diese die Procedure aus SysUtils kennen, aber die Procedure aus Sysutils muss nicht unbedingt etwas von meiner procedure wissen.

[BadenPower]

Zitat von bernau:

Das voneinander Wissen sollte nur in eine Richtung gehen.

Aber um dann miteinander arbeiten zu können, müssen beide einen 3. kennen.

Warum also einen dritten hinzuziehen, wenn die beiden Klassen zusammengehörig sind und gegenseitig miteinander über den direkten Weg agieren können.

Bei den Proceduren und Funktionen, welche in einer Klasse angelegt sind macht sich doch auch niemand Gedanken darüber, dass sich ALLE gegenseitig kennen und vorwärts deklariert sind.


Also:
Ich bin für Vorwärts-Deklarationen auch bei Klassen.

[stahli]

Das ist ja auch nicht generell ein Problem und oft sinnvoll.

Man kann dann aber die beteiligten Klassen nicht mehr (so leicht) verselbständigen und an anderer Stelle einsetzen.

Auch wenn sich ein Projekt immer weiter vergrößert kann das irgendwann unübersichtlich werden.
Dann würdest Du vielleicht gern eine Klasse in eine eigene Unit legen, da aber alle Klassen mit allen anderen umgehen geht das dann nicht mehr.

Forward Deklaration ist sicher kein Problem, aber bei komplexen Projekten ist es besser, von Anfang an auf ordentliche Trennung zu achten.

[bernau]

Zitat von BadenPower:

Aber um dann miteinander arbeiten zu können, müssen beide einen 3. kennen.

Warum also einen dritten hinzuziehen, wenn die beiden Klassen zusammengehörig sind und gegenseitig miteinander über den direkten Weg agieren können.

Bei den Proceduren und Funktionen, welche in einer Klasse angelegt sind macht sich doch auch niemand Gedanken darüber, dass sich ALLE gegenseitig kennen und vorwärts deklariert sind.

Ich hatte ja eingangs geschrieben, daß auch ich gelegendlich eine Forward-Deklaration verwende. Manchmal geht es nicht anders. Aber wenn es möglich ist, dann vermeiden.

Das ist wie mit Units, die sich gegenseitig kennen müssen (Stichwort Zirkuläre Referenz). Wenn du so etwas drin hast.... Nee. Versuch es du vermeiden.

[BadenPower]

[QUOTE=bernau;1283985]

Zitat von BadenPower:

Stichwort Zirkuläre Referenz

Und genau deshalb gibt es ja die Möglichkeit einer Vorwärts-Deklaration von Klassen.

Und weil sie zusammengehören und direkt von einander abhängig sind, stehen sie auch in der selben Unit.

Und eine solche Ehe soll der Programmierer dann auch nicht scheiden.

[Sir Rufo]

Immer wenn ich auf mein Knie drücke tut es weh, genauso am Arm und am Ohr, sowie am Fuß, eigentlich überall.

Jetzt habe ich meine Diagnose: Finger gebrochen.

Delphi-Quellcode:

// Form object - action taken when
procedure TForm1.FormCreate(Sender: TObject);
 var
   apple, banana : TFruit;
 begin
  // ACHTUNG, DIESE ZEILEN EINFÜGEN
  if not Assigned( f ) then
    raise Exception.Create( 'Finger gebrochen!' );
  // DAS WAR ES SCHON - AUSPROBIEREN - WAS SEHEN WIR?
   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;

[Dejan Vu]

Zitat von BadenPower:

Aber um dann miteinander arbeiten zu können, müssen beide einen 3. kennen. ...Warum also einen dritten hinzuziehen, wenn die beiden Klassen zusammengehörig sind und gegenseitig miteinander über den direkten Weg agieren können.

Wegen der Wiederverwendbarkeit, z.B. Zirkuläre Referenzen sind eigentlich nie sinnvoll. Es verbindet beide Klassen unauslöschlich miteinander. Meistens (eigentlich immer) ist es ein Designfehler. Mir fällt kein sinnvolles Beispiel ein, wo zwei *Klassen* sich kennen müssen. A verwendet B, aber B muss A konkret nicht kennen, höchstens ein von A implementiertes Interface. Und -wupps- haben wir die zirkuläre Referenz aufgelöst.

Es gibt mittlerweile (also seit ca. 20 Jahren) Grundregeln moderner Softwarearchitektur, die man befolgen kann oder auch nicht. Nur wenn man sie nicht befolgt, dann muss man sich nicht wundern, wenn man dann in einer Diskussion, die sich am Rande auch um diese Regeln dreht, Gegenargumente bekommt. Oder teilweise Kopfschütteln.

Zitat:

Ich bin für Vorwärts-Deklarationen auch bei Klassen.

Wie fein. Andere Leute finden Bollerwagen toll. Aber das Transportgewerbe setzt gemeinhin auf bessere Lösungen.

[DeddyH]

[BadenPower]

Zitat von Dejan Vu:

Es gibt mittlerweile (also seit ca. 20 Jahren) Grundregeln moderner Softwarearchitektur, die man befolgen kann oder auch nicht. Nur wenn man sie nicht befolgt, dann muss man sich nicht wundern, wenn man dann in einer Diskussion, die sich am Rande auch um diese Regeln dreht, Gegenargumente bekommt.

Mich wundert es nicht, wenn ich für meine Meinung Gegenargumente bekomme, aber was mich wundert ist, dass man dann mit Delphi arbeitet, wenn man sich ausschließlich an "Grundregeln moderner Softwarearchitektur" halten will.

Eine Funktion ist immer dazu da, benutzt zu werden.

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen, oder seine komplett selbst programmierte VCL zu benutzen.
Sollte man allerdings tun, wenn man auf die "Grundregeln moderner Softwarearchitektur" besteht.

[Dejan Vu]

Zitat von BadenPower:

Eine Funktion ist immer dazu da, benutzt zu werden.

Hmmm. Ein 'goto' auch?

Zitat:

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen,

Doch. Programmierer, die was auf sich halten (oder sich das einbilden), schon. Ein TTabSheet möchte vielleicht einmal in einem anderen Container sein, als in einem TPageControl. Das geht so aber nicht. Wäre das TTabsheet nur abhängig von einem Container, der die notwendigen Methoden des TPageControl implementiert, ginge das.

Zitat:

aber was mich wundert ist, dass man dann mit Delphi arbeitet, wenn man sich ausschließlich an "Grundregeln moderner Softwarearchitektur" halten will.

Och, auch mit Delphi kann man recht sauberen Code produzieren. Man muss einfach nur die Anti-Pattern vermeiden.

Im Übrigen gilt in der modernen Softwarearchitektur auch und besonders, das man bestehende Frameworks benutzen sollte, wenn dies (TOC) günstiger ist, als selbst etwas zu entwickeln. Also verwende ich zähneknirschend die VCL und auch mal so ein in seiner Freiheit eingeschränktes TTabSheet.