Forward in Klassen funktioniert nicht

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

Zitat von BadenPower (Beitrag 1283982)

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:

Zitat von BadenPower (Beitrag 1283982)

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:

Zitat von BadenPower (Beitrag 1283982)

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]

:thumb:

[BadenPower]

Zitat:

Zitat von Dejan Vu (Beitrag 1284008)

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:

Zitat von BadenPower (Beitrag 1284011)

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.

[BadenPower]

Zitat:

Zitat von Dejan Vu (Beitrag 1284013)

Och, auch mit Delphi kann man recht sauberen Code produzieren.

Du widersprichst Dir selbst.

Einerseits sagst Du, dass Forward-Deklarationen von Klassen nicht den "Grundregeln moderner Softwarearchitektur" entsprechen, andererseits verwendest Du Delphi, welches voll ist mit Klassen-Forward-Deklarationen.

Entweder sind dann auch Klassen-Forward-Deklarationen "sauberer Code" oder Dein Programm hat KEINEN sauberen Code, denn Dein Programm besteht zu einem sehr großen Teil aus Delhi-Code.

Du solltest Dich für eine Variante entscheiden.

Zitat:

Zitat von Dejan Vu (Beitrag 1284013)

Zitat:

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

Doch. Programmierer, die was auf sich halten (oder sich das einbilden), schon.

Also ich habe ein eigenes TPageControl und ein eigenes TTabSheet und habe es dennoch nicht übers Herz gebracht eine unnötige 3. Klasse zu erstellen, damit sich beide Klassen unterhalten können oder gar in zwei verschiedenen Units ihr Dasein zu fristen.

Zitat:

Zitat von Dejan Vu (Beitrag 1284013)

Zitat:

Zitat von BadenPower (Beitrag 1284011)

Eine Funktion ist immer dazu da, benutzt zu werden.

Hmmm. Ein 'goto' auch? ;-)

Selbstverständlich.

Auch ein "Goto" war ein sehr gut einzusetzender und effektiver Befehl.

[ATS3788]

Sir Rufo:thumb:

Ohhhh Danke Dir, das Object wurde noch nicht erstellt Oooohhhhhhhhhh
Nur warum ging das mit der Lokalen Variablen
dann wäre mir das auch aufgefallen.
Ein schönes Weihnachtsfest.

Zitat:

http://www.delphipraxis.net/183177-d...scheidung.html
Schaut doch mal in den Beitrag von mir. Knapp 700€ für XE7 sind viel Geld
wenn man kein Geld mit Programmieren verdient. Vielleicht habt ihr ja noch
eine gute Idee.