Problem mit Uses-Klausel

[Sir Rufo]

Zitat von Medium:

Edit: Okay, den Spezialfall den Sir Rufo nennt gibt es auch. Das habe ich bisher aber meist nur im Zusammenhang mit DBControls gesehen, und ich persönlich würde diese Praxis auf einem absolut notwendigen Minimum halten. Zumal die Uses-Klauseln dadurch alles andere als übersichtlicher würden.

Diesen "Spezialfall" hast du bei 99% aller Komponenten (z.B. TButton, TEdit, etc.) und ist auch nur "speziell" bei installierten Komponenten aus der Komponentenpalette möglich, da es sich um ein "spezielles" Verhalten der IDE handelt

Und der TE fragte auch ganz "speziell" nach Komponenten.
(ist aber in diesem Zusammenhang aber eher nur eine Randnotiz wert, weil es eben IDE "speziell" ist)

[Medium]

Das ja, was aber nicht ginge ist:

Delphi-Quellcode:

unit MyMainUnit;

interface

uses
   Auto; // kennt nur Auto

var
   MeinAuto : TAuto;

MeinAuto.Lenkrad := TLenkrad.Create;

Da die Deklaration von TLenkrad fehlt. Memberzugriff geht immer, auch ohne das der Typ des Objekt-Feldes im Scope liegt. Nur die unmittelbare Verwendung dessen geht nicht. Ebenso geht auch z.B. das nicht:

Delphi-Quellcode:

uses
   Auto; // kennt nur Auto

var
   MeinAuto : TAuto;

MeinAuto := TMercedes.Create;

Um das zu realisieren gibt es mehrere Wege: Eine Factory, die eine Enummeration als Parameter erhält und anhand dessen ein Objekt des richtigen Typs liefert; das gleiche nur anders: In der Unit Auto müssten dann noch Dinge wie "TMercedesClass = class of TMercedes;" usw. deklariert werden, welche statt der Enummeration übergeben würden; eine String-Basierte Factory die einen Text-Parameter nimmt und anhand diesem unterscheidet, ... letztlich würde hier, wenn es um das Erzeugen eines spezifischen Autos geht, am ehesten aufs Factory-Pattern hinauslaufen. Fühlt sich für mich zumindest am "natürlichsten" an. Wie man dieser nun konkret sagt, was sie erzeugen soll, wäre dann wie o.g. sehr variabel. Da käme es dann auf den genauen Einsatz an, und wohl auch persönlichen Geschmack.


@Roter-Kasten-Rufo: Dass die VCL nicht der Gold-Standard der Best-Practices ist, weiss ich auch ;P

[Sir Rufo]

@Medium

[stahli]

Irgendwas kam mir doch schon beim Abschicken merkwürdig vor.
Hätte auf meine Signatur hören sollen.

[philharmony]

Hmm nächstes Problem: meine 'TParkhaus' enthält eine 'Autos : TList', die nur die Pointer auf die verwendeten 'TAuto' enthält. Ich habe zwar eine procedure Parthaus.AddAuto(Name : String), und eine function Parkhaus.GetAuto : TAuto, allerdings kennt UnitMain ja nur 'Parkhaus' und kann dann zwar ein Auto hinzufügen, aber nichts mit dem ReturnValue von GetAuto vom Typ TAuto anfangen, richtig?

[DeddyH]

Richtig.

[philharmony]

Ich glaube, die Rupie hängt noch knapp über dem Boden fest:

Wenn 'TParkhaus' eine Property vom Typ 'TAuto' hat, dann kennt die MainUnit, die TParkhaus verwendet auch TAuto. Ist das richtig?
Dann könnte ich anstatt der GetAuto ja auch eine ArrayProperty mit Typ TAuto benutzen, die den entsprechenden Zeiger aus der TList zurückgibt. Kennt die MainUnit dann TAuto?

[DeddyH]

Damit die MainUnit die Klasse TAuto kennt, muss diese in irgendeiner der eingebundenen Units auch deklariert sein.

[philharmony]

Ok danke, ich denke ich habs. Ich bin noch von meiner Arbeit mit C ausgegangen, wo ein #include den gesamten damit eingebundenen Text inklusive aller dort vorhandenen #includes kennt.

[Medium]

Wichtiger Unterschied zu Includes: Diese werden quasi wie einkopierter Text behandelt (imho werden sie sogar genau das), während unter Units ein "semantischer" Zusammenhang besteht: Lediglich das, was in einer Unit explizit an Typen deklariert ist, ist nach aussen hin sichtbar, und die Sichtbarkeit erstreckt sich auch nur über genau eine Uses-Klausel, und wird über diese nicht an weitere "Unterbenutzer" weitergeleitet.
Delphi kennt unterdessen auch Includes. Hier aber nicht über ein Keyword, sondern eine Compilerdirektive ({$i Dateiname} wenn ich nicht irre, grad kein Delphi parat). Dabei wird dann ebenfalls nur der Inhalt von "Dateiname" an die Stelle kopiert, wo die Direktive steht. Ist keine gängige Praxis, und imho auch kein allzu astreiner Stil, in manchen Situationen aber sehr hilfreich. Bei dir bin ich aber der festen Überzeugung, dass sich das auch über ein geeignetes Klassendesign schöner lösen lässt.