Forward in Klassen funktioniert nicht

[Dejan Vu]

Zitat von BadenPower:

Ja das muss sein.

Nein. Muss es nicht.

Zitat:

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".

Du verwechselst 'Abhängigkeiten' mit 'Weiterentwicklung'.

In der Softwareentwicklung müssen die Klassen nichts voneinander wissen. Eine Eizelle und ein Mensch können sehr gut existieren, ohne einander zu kennen.

Zitat von BadenPower:

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

Abhängigkeiten sollten auf ein Minimum beschränkt sein. Eine Klasse soll nur die Dinge wissen, die gerade notwendig sind, damit sie (die Klasse) ihre Aufgabe erledigt kann. Mehr nicht.

Wechselseitige Abhängigkeiten sind dagegen erstens zu vermeiden und zweitens immer vermeidbar. Es reicht ja schon, ein Interface einzuführen. Alternativ dazu kann ich auch mit Events arbeiten.

Wechselseitige Abhängigkeiten führen zudem dazu, das die Klasse ihre Allgemeingültigkeit und Wiederverwendbarkeit einschränkt, wenn nicht sogar verliert.

[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?

Zitat von Dejan Vu:

Eine Eizelle und ein Mensch können sehr gut existieren, ohne einander zu kennen.

Das ist richtig.

Denn irgendein Mensch muss irgendeine Eizelle nicht kennen.

Aber die Klassen müssen sich gegenseitig kennen, sonst würde die Menschheit aussterben.

Zitat von Dejan Vu:

Wechselseitige Abhängigkeiten führen zudem dazu, das die Klasse ihre Allgemeingültigkeit und Wiederverwendbarkeit einschränkt, wenn nicht sogar verliert.

[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]