Zwei Klassen benötigen sich gegenseitig

[Max Odenbrett]

Hallo zusammen!

Ich habe zwei Klassen TFischTeich und TFisch die in zwei verschiedenen Units implementiert sind. Der FischTeich benutzt Objekte vom Typ TFisch. Soweit kein Problem. Allerdings muss ich in TFisch auch eine Variable vom Typ TFischTeich haben, damit der Fisch weiß, in welchem Teich er ist. Da man die beiden Units aber nicht ineinander einbinden kann, brauche ich einen Ausweg. Drei habe ich schon ausprobiert, aber ich bin nicht so richtig zufrieden:

1.) In TFisch die Variable für den Teich einfach als TObject deklarieren. Bei der Verwendung im Implementationsteil (da kann die Unit dann ja eingebunden werden) dann immer eine Typenumwandlung TFischTeich(Teich).xyz durchführen. Das find ich aber zu Umständlich.

2.) Vorwärtsdeklaration verwenden, in dieser Reihenfolge:
TFischTeich = class;
TFisch = class(TObject) ... end;
TFischTeich = class(TObject) ... end;
Das hat aber den Nachteil, dass die gesamte Implementation beider Objekte in der gleichen Unit stehen muss. Das ist zu unübersichtlich und soll aus formalen Gründen (für jede Klasse eine eigene Unit) auch nicht sein.

3.) Erst eine Klasse mit abstrakten Prozeduren deklarieren und in der Implementierung dann eine Instanz der "mit Leben gefüllten" Klasse verwenden. Aber auch hier sind Typumwandlungen nötig und auch das finde ich eigentlich zu unübersichtlich.

Hat jemand eine bessere Idee? Oder welche der drei Varianten findet ihr am besten?

Danke, dass ihr euch dieses Problem angeschaut habt!
-Max

[Andreas Kosch]

Hallo,

>Das ist zu unübersichtlich und soll aus formalen Gründen (für jede Klasse eine eigene Unit) auch nicht sein.

Sogar Borland nutzt in der VCL massiv Units, in denen sehr viele Klassen (Komponenten) deklariert und implementiert werden. Wenn eine Klasse in einem Objektfeld einen Bezug auf einen andere Klasse hat, "gehören" die beiden zusammen, so dass eine gemeinsame Unit durchaus Sinnvoll ist. Die Forward Declaration wurde genau für diese Situation vorgesehen

[Wolfgang Roller]

Hallo Max,

ich kann mich hier nur Andreas Koschs Meinung anschließen. Wenn sich zwei Klassen im Deklarations-Teil gegenseitig referenzieren, dann ist die sauberste Lösung beide in derselben Unit zu speichern. Alles andere ist Krampf.

Da du noch Schüler bist, würde mich mal interessieren von wem die "formalen Gründe" stammen, die für jede Klasse eine eigene Unit fordern. Für mich hört sich das an als hätte derjenige (du oder dein Lehrer) die in Java zwingend vorgeschriebene Arbeitsweise, jede öffentliche Klasse in eine eigene Datei, auch für Delphi übernommen.

Dazu kann ich nur sagen: Man kann sich an Java schon ein Beispiel nehmen, aber man sollte es auch nicht übertreiben. Theoretisch kann ich in Delphi ein ganzes Projekt in einer einzigen Unit zusammenfassen. Dann wird's aber verdammt unübersichtlich, außerdem brauche ich garnichts als private deklarieren, weil ja innerhalb einer Unit alles public ist. Das ist natürlich nicht die professionelle Vorgehensweise.
Aber ich hatte schon mit einem Projekt zu tun, das aus ca. 60 Units bestand. Aber in 5 Units war mindestens 1/4 des kompletten Quellcodes enthalten. Da sage ich mir dann schon manchmal, es wäre schön, wenn es in Delphi ebenfalls den Zwang gäbe: Eine Klasse pro Unit. Dann wären auch solche Leute gezwungen sich ein bißchen mehr Gedanken über das Klassen-Design zu machen.
Anderseits habe ich auch schon in etlichen Java-Projekten mitgemacht. Oft bin ich auch erst in der Endphase ins Projekt gekommen. Wir arbeiten mit CVS und beim Auschecken kommen einem dann tausende von .java-Dateien entgegen gepurzelt. Dann weiß man schon beim Auschecken, ja es ist ein Java-Projekt. Was ich damit sagen will ist, daß ich es auch nicht für optimal halte für jedes kleine "Hilfs-Klässechen" eine eigene Datei verwenden zu müßen.

Deshalb so viel als möglich was thematisch zusammen gehört in eine separate Unit tun, aber nicht auf Teufel komm raus meinen, man müßte Java nacheifern und pro Unit höchstens eine Klasse zu speichern. Das ist auch in sofern falsch als, daß die Unit-Entsprechung in Java nicht die einzelne Java-Datei ist, sondern das Package.

Gruß

Wolfgan

[Max Odenbrett]

Danke für eure Antworten!

=> Warum das ganze als Schüler?
Nun, ich nehme am Bundeswettbererb Informatik teil. Und da ist odentliche Objektorientierung und Objektmoddelierung wichtig. Außerdem will ich diese Leistung mit ins Abitur reinnehmen und dann muss mein Lehrer sie korrigieren. Der nimmt es an den sinnvollen Stellen sehr genau mit solchen formalen Dingen. Aber ich finde das auch selber nicht schlecht. Kann sein, dass das von Java kommt, das machen wir nämlich gerade im Unterricht.

=> Warum nicht alles in eine Unit.
Zum einen wegen der Zugehörigkeit und dann auch wegen der Übersichtlichkeit. Mir werden die Units schlichtweg zu lang, unübersichtlich etc., wenn nicht alles fein säuberlich gruppiert ist. Ich schreibe auch aus Selbstdisziplin (sonst wird es chaotisch und ich finde nie was wieder) die Prozeduren im Implementationsteil in der gleichen Reihenfolge wie im Interface-Abschnitt.

=> Wie gelöst?
Also, leider geht die Vorwärtsdeklaration ja nicht über Unitgrenzen hinaus. Warum eigentlich nicht. Ich habe jetzt erst eine "abstrakte" Klasse deklariert, diese für die Deklaration der anderen verwendet und im Implementationsteil dann eine Instanz der nicht-abstrakten Nachfolgeklasse erzeugt. Polymorphie sei Dank!!!
Aber ich gebe zu, dass das auch nicht gerade "übersichtlich" ist.

Schöne Grüße
Max Odenbret

[Andreas Kosch]

Hallo,

>...Der nimmt es an den sinnvollen Stellen sehr genau mit solchen formalen Dingen...

was steht denn im Mittelpunkt? Dass eine Anwendung in der geplanten Projektzeit erfolgreich realisiert werden kann, oder dass der Sourcecode einen "OOP-Schönheitspreis" bekommt? Ein Grund für das "Scheitern" von Java im Bereich der GUI-Anwendungen (Desktop) lag ja gerade darin, dass Java einen fundamentalistischen Ansatz hat und bestimmte (sinnvolle) Sachen nicht erlaubt. In der "reinen Lehre" (bei dem der Faktor Zeit für die Projektrealisierung überhaupt keine Rolle spielt) mag das auch angehen, aber im richtigen Leben dauert das Ganze viel zu lange.

>..Ich habe jetzt erst eine "abstrakte" Klasse ..

Der Implementierungsaufwand steigt und die Übersichtlichkeit sinkt - wo ist da bitte schön der Nutzen? Wenn Borland diese Vorgehensweise in Delphi erzwingen würde, verliert Delphi einen Teil seine RAD-Vorteile (Rapid Application Development)

[Bernd Schulz]

Hallo!<br>
Wie wäre es mit der Einführung einer Superklasse, die das gesamte System Fisch und Fischteich abdeckt?!? Diese SKlasse kann dann Objekte von Typ TFisch und TFischteich beinhalten. Verbindungen von Fisch nach Teich und umgekehrt müßten von dieser SKlasse verwaltet werden. Somit hast Du nur eine Abhängigkeit "nach unten" und nicht mehr bidirektional.<br>
Etwas Literatur, die das Problem etwas anders als Dein Lehrer sieht:
http://www.objectmentor.com/resources/articles/granularity.pdf<br>
BYE BERN