Hallo Delphi-/Pascal-Programmierer.

Ich hab weniger ein Problem, als eine allgemeine Frage.

Wie implementiere ich zwei Objekte, die jeweils eine Beziehung zum Anderen pflegen?

Beispiel:

zusammenfalten · markieren

Delphi-Quellcode:

type
  A = class
  private
    <list of B>

    [...]
    end;

type
  B = class
  private
    myA: A;

    [...]
    end;

A und B sind in unterschiedlichen Modulen (zB: mA, mB).

ist es in irgend einer Weise möglich, dass zu realisieren, oder muss ich beide Definitionen in eine Type-Klausel (also in EIN Modul) beschreiben?

Gegen das "Ein-Modul-Konzept" spricht meine Philosophie, jedes Objekt in seine eigene Unit.
(Type-Casting auf untypisierte Pointer kommt aus stilistischen Gründen nicht in Frage)

Ich sehe selbst leider keine Möglichkeit, aber ich will es nicht unversucht lassen und frage deshalb euch

Ich hoffe, ihr könnt mir Tipps geben

Vielen Dank an euch

Einfach die Unit von B in den Uses einbinden

Kommt auf die Beziehung an. Eventuell kannst Du Abstrakte Klassen oder Interfaces in eine dritte Unit auslagern...

Edit:

Zitat von mkinzler:

Einfach die Unit von B in den Uses einbinden

So wie ich sein Problem verstanden habe, würde so eine zirkuläre Referenz enstehen, was Delphi so nicht erlaubt.

Hatte das gleiche Problem. Wollte es auch in eigenen Units lassen und habe es wie oft im VCL-Quellcode gelöst.

Pointer auf TObject ubergeben und Gültigkeit vorm Cast via Classname abfragen. Das ist kaum besser als untypisierte Pointer, aber ich hab' nach langem suchen auch keinen anderen Weg gefunden.

man hat ja Hoffnung, dass wenn sie jetzt den 64 Bit Compiler eh neu machen müssen, dass dieser Quatsch endlich mal in Delphi behoben wird.

Und alle Meinungen, die man sogar gelegentlich hört, es wäre sogar ein Feature statt ein Failure, (manche behauptetn ja sogar, dass dann was mit dem klassenkonzept nicht stimmen würde) sind auch nur halbherzig. Denn in einer einzigen Unit funktioniert es ja, dass man überkreuzende Bezüge zu Klassen herstellen kann, warum also nicht auch in verschiedenen Units, für mich ist da kein Unterschied.
Es führt dazu, dass man viel zu viel Quelltext in eine einzige Unit stecken muss. Modularisierung wäre schon toll...

ich benutze gelegentlich diese Lösung. So wird zumindest der Quellcode durch die unschönen Casts nicht belastet und bleibt damit befreit von unwichtigen Sachen. Meine Meinung ist, es sollte möglichst nur das in einer Funktion stehen, was wirklich zum funktionieren der Funktion wichtig ist.


http://www.delphipraxis.net/internal...euzender+bezug

@mirage228:

Ja, die Idee kam mir auch (ist auch vom Stil her elegant):

Hat man nur noch eine Klasse (und ein Modul) mehr

Danke euch für die schnellen Antworten:

Für die Vollständigkeit:

markieren

Delphi-Quellcode:

type
  A1 = class
    [...]
    end;

markieren

Delphi-Quellcode:

type
  B = class
    <list of A1>

    [...]
    end;

markieren

Delphi-Quellcode:

type
  A2 = class(A1)
    myB: B;

    [...]
    end;

Gibt es in Delphi abstrakte Klassen (wär der Wahnsinn!)???

Zitat von SebE:

Gibt es in Delphi abstrakte Klassen (wär der Wahnsinn!)???

Also soweit ich weiß kannst Du nur "normale" Klassen mit abstrakten Methoden machen (ala TStrings), sowas wie "type TKlasse = abstract class" gibt es meines wissens nach (zumindest für Win32) noch nicht...

@stoxx:

Dieses "forward"-Deklarieren ist zwar hilfreich, aber entspricht nicht dem Ansatz: Erst Deklarieren, dann nutzen.

Wie erstelle ich abstrakte Klassen (man könnte ja den Constructor virtual abstract definieren -> nicht sehr elegant)

@mirage228:
NOCH nicht?
in Pascal gab's die mal, also kann man davon ausgehen, dass es sie auch in Zukunft nicht mehr geben wird (schade eigentlich).