Problem mit Uses-Klausel

[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'?

[DeddyH]

Wenn die Funktion TAuto zurückgibt, muss TAuto auch bekannt sein, sonst könnte die MainUnit ja gar nicht wissen, dass diese über eine Methode/Property NReifen verfügt.

[Sir Rufo]

Zitat von philharmony:

Aber geht {2}?

Ja die Variante {2} funktioniert so

[DeddyH]

Sicher? Ich hab gerade kein Delphi am Start, aber es würde mich wundern.

[Sir Rufo]

Zitat von DeddyH:

Sicher? Ich hab gerade kein Delphi am Start, aber es würde mich wundern.

Absolut sicher. Siehe meinen Beitrag #10

[Medium]

Ich bin fest davon überzeugt, dass philharmonys Annahmen völlig korrekt sind, und man keinen Getter für 2 bräuchte. Wenn das nicht wäre, würde man ja sowas von übel im Klassendesign beschränkt sein, und jede Pupel-Property durchreichen müssen. Man kann eben nur die Instanz von Parkhaus.Auto[i] keiner Variablen zuweisen, da für diese kein passender Typ verfügbar wäre.*

*)Wäre es schon: Jede Elternklasse von TAuto ginge, nur könnte man nachher nicht mehr dort hin casten um an die Member heranzukommen die seit dem verwendeten Typ dazu kamen. Und da alle Klassen zwangsweise von TObject erben, ginge durchaus dieses:

Delphi-Quellcode:

var
  auto: TObject;
begin
  auto := Parkhaus.Autos[0];

Nur könnte man nicht mehr auf auto.NReifen zugreifen, da es das in TObject noch nicht gibt. Gäbe es hingegen einen Vorfahren von TAuto - z.B. TBereiftesVehikel - der bereits den Member NReifen kennt, und man dessen Unit einbände, DANN ginge das wieder. Aber das sind jetzt langsam eigentlich nur noch theoretische Überlegungen.

[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