Problem mit Uses-Klausel

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

[philharmony]

Zitat:

Bei dir bin ich aber der festen Überzeugung, dass sich das auch über ein geeignetes Klassendesign schöner lösen lässt.

Definitv, bin grade dran, das Ganze ein wenig umzustricken. Das Projekt ist meine erste Baustelle in OOP, bisher hab ich in C nC Programmiert. Muss eben meine Denke erstmal auf OOP und Delphi umstellen.
Eine Frage hab ich dazu noch:

Ich habe also

Delphi-Quellcode:

uses UnitAuto;
type
 Parkhaus = class
  FAuto : TList;
  function GetAuto(Index : Integer) : TAuto;
  ...
  property Auto[index : integer] : TAuto read GetAuto;
 end;


//In der UnitMain
uses UnitParkhaus;
...
{1}
function meinAuto : TAuto;
begin
  result := Parkhaus.Auto[0];  
end;

{2}
function AnzahlReifen : Integer;
begin
  result := Parkhaus.Auto[0].NReifen;
end;

Demnach geht {1} natürlich nicht, da UnitMain TAuto nicht kennt, wie vorhin schon klargestellt. Aber geht {2}?
Oder braucht es dazu eine
'function TParkhaus.GetNReifen(Index) : integer'?

[JamesTKirk]

Zitat von Medium:

Ist keine gängige Praxis, und imho auch kein allzu astreiner Stil, in manchen Situationen aber sehr hilfreich.

Das mit dem "keine gängige Praxis" trifft so aber auch eigentlich nur auf Delphi zu. In Free Pascal sind Includes vor allem in den Units der RTL und der anderen Basisunits ziemlich gang und gäbe. Vor allem erleichtern sie es plattformspezifischen Code zu haben ohne den Code mit zigtausend ifdefs zu zupflastern. Ein {$include platformspecific.inc} zusammen mit dem richtigen Include-Verzeichnis als Compilerparameter reicht hier

Und zudem bietet die Lazarus IDE auch eine bessere Unterstützung für Includes (eben genau wegen der oben genannten gängigen Praxis) als es Delphi hat.

Gruß,
Sven