Forward in Klassen funktioniert nicht

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

[Sherlock]

Und alles liegt unter der Klasse Lebewesen.

Sherlock

[BadenPower]

Zitat von Sherlock:

Und alles liegt unter der Klasse Lebewesen.

Und diese Klasse wurde von den Delphi-Entwicklern bereitgestellt.

Das kann nur so sein, da sie aussergewöhnlich viele Fehler enthält.

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