Jede Komponente in EIGENER Unit

[Pseudemys Nelsoni]

Moin moin,

ich möchte gern jede Komponente die ich schreibe in einer eigenen Unit, da es einfach übersichtlicher ist als alles in einer zu haben.

Das Problem: Die eine Klasse braucht die andere und umgekehrt, d.h Klasse1 hat ein Feld "FOwner" das die Komponente des Besitzers angeben soll. In Klasse2 wiederum(Hauptklasse) ist ein Feld von Klasse1.

Ist es denn gar nicht möglich das irgendwie in 2 Units unterzubringen? D.h ich müsste Die eine unit in der Anderen im uses-teil haben und umgekehrt. (was aber ja nicht geht)

Das macht mich fertig :cry:

[SirThornberry]

du musst die unit unter implementation eintragen (da in die uses, bzw. eine neue uses dort anlegen).

Bei der Deklaration gibst du dann oben TObject als Owner an und überprüfst dann in der funktion ob der typ stimmt.

Delphi-Quellcode:

type
  TMyClass1 = class;
  public
    procedure OwnerSetzen(AOwner: TObject);
  end;

implementation

uses
  unitMitTMyClass2;

procedure TMyClass1.OwnerSetzen(AOwner: TObject);
var LOwner: TMyClass2;
begin
  //Hier ist TMyClass2 dann bekannt, deshalb kannst du jetzt prüfen ob AOwner vom Typ "TMyClass2" ist
  if AOwner is TMyClass2 then
  begin
    LOwner := TMyClass2(AOwner);
    //do something with LOwner
  end;
end;

[Pseudemys Nelsoni]

Moin SirThornberry,

das mit dem implementationstail hab ich mir auchschon überlegt,aber ich brauche die andere Unit ja schon bereits im Interface teil, da ich dort ja den "FOwner: MyClass2" festlegen muss


EDIT: ah ich seh schon, danke ich teste das mal :)

[Robert_G]

Zitat:

Zitat von SirThornberry

du musst die unit unter implementation eintragen (da in die uses, bzw. eine neue uses dort anlegen).

Bei der Deklaration gibst du dann oben TObject als Owner an und überprüfst dann in der funktion ob der typ stimmt.

Dann könnte er ja genausogut den Owner von TComponent übernemhmen. Ich denke mal, er findet dieses Rumgecaste ziemlich hässlich. ;)
Ohne Interfaces bzw. abstrakte Klassen wirst du da nicht weiter kommen. ;)

[Pseudemys Nelsoni]

Du hast recht, ich finde es hässlich, aber von Interfaces habe ich nicht wirklich Ahnung ;)

Solange es funktioniert und die Komponente fertig ist und ich sie mir nichtmehr angucken muss ist mir das egal *g*

@Thornberry: wofür steht das L deiner Variablen? "Local" ? Eigentlich ne gute Idee, dann können sich Argumente mit Lokalen Variablen nicht "ersetzen".(Gleicher name z.b)

[Hansa]

Zitat:

Zitat von Robert_G

Ohne Interfaces bzw. abstrakte Klassen wirst du da nicht weiter kommen. ;)

Fange nicht schon wieder damit an. :mrgreen: Aber im Ernst : was ich so gesehen habe und es auch selber so mache : in jedem Package sind Komponenten, die vom gleichen Vorfahren abstammen. Dadurch fällt die Fehlerquelle weg, gleich mehrere Units, also Komponenten registrieren zu müssen. Und abstract ist dann auch in diesem Falle überflüssig.

Beispiel :

ich habe 2 Komponentengruppen in 2 Units. Das sind jeweils 3 Stück. Die eine ist abgeleitet von TEdit, die andere von TDBEdit. Leider ging das mit vertretbarem Aufwand nicht anders, aber mit .NET soll sich das ja ändern. Die eine Unit sieht nun ungefähr so aus : (abgeleitet von TEdit) -> MeinEdit -> MeinIntEdit -> MeinRealEdit. Mit etwas Phantasie kann man sich ausrechnen, was da gemacht wird : im OnKeyPress werden die zulässigen Zeiechen geprüft, bei Zahlen steht das Default-Alignment auf rechts und und.

Als Faustregel würde ich mal sagen : alles was in der Komponentenpalette in einen eigenen Registerreiter gehört, das gehört auch in eine eigene Unit.

[stoxx]

wie würde sich dieses Problem denn da mit abstrakten Klassen lösen lassen ?
So ganz klar is mir das noch nicht jetz ? :nerd:

[sakura]

Auch wenn Du es nicht willst, so möchte ich es zumindest gesagt haben. Wenn Du zwei Komponenten / Klassen hast, welche so eng miteinander verbunden sind (z.B. TreeView und TreeItem), dann sollten diese auch in einer Unit sein und somit deren Zusammengehörigkeit direkt verdeutlichen.

...:cat:...

[Hansa]

Indem Du etwas da definierst, ohne es zu impemetieren, wo es eigentlich nicht hingehört und dann anderwo sagst, wo es her kommt und die Implementierung dann da machst. Für so Spaghetti-Code dürfte dir Robert_G helfen können. :mrgreen:

[Edit] Sakuras Beispiel ist noch krasser als meins. Vor allem sollte man noch bedenken, daß es um OOP geht. Man also wirklich nur die Unterschiede zwischen den Klassen neu machen muß. Für meine RealEdit-Klasse, die vom IntEdit kommt und nur den DecimalSeparator abhandelt, mache ich doch keine eigene Unit.

[Robert_G]

Zitat:

Zitat von stoxx

wie würde sich dieses Problem denn da mit abstrakten Klassen lösen lassen ?
So ganz klar is mir das noch nicht jetz ? :nerd:

Wenn du Benachrichtigungen so standardisierst dass du zum Bleistift mit einem Interface INotifiable und einem INotifier auskommst, kannst du schon einige Owner/Child - Probleme lösen.
Dabei würdest du weder den Owner noch das Child fest aneinander koppeln.
Aber bei so loser Kopplung wirst du um einen TypCast bei den Benachritungen nicht vorbeikommen*.

Wenn du jetzt eine Basisklasse für den Owner hast**, die du in beiden Units benutzen kannst, könntest du so virtuelle/abstrakte Methoden des Owners ohne TypCasting ausführen.
Aber etwas Gewurschtel wird es eigentlich immer werden. ;)

@mieze
In dem Fall würde es auch nicht viel Sinn machen. ;)
Aber ich fange jetzt ganz sicher nicht mit dem internal und den fehlenden forward declarations aus C# an. :mrgreen:

@Hansa
Dass du absolut keine Peilung von OOP hast dürfte man in Pseudos anderem Thread gemerkt haben. :mrgreen:

*Irgendwas spezielles wird der INotifier ja dem INotifiable mitteilen wollen. ;)
**die keinen direkten Verweis auf die Childklasse hat