![]() |
Problem mit Uses-Klausel
Hallo zusammen
Entweder ist hier ein Bug oder ich hab etwas doch noch nicht verstanden: Ich habe mein Projekt in diverse Units aufgeteilt, um den Text übersichtlicher aufzuteilen. Nun war ich bisher der Meinung, verstanden zu haben, wie sich die Uses-Klausel im Interface bzw. Implementation-Teil verhalten. Nun ist aber ein Problem aufgetaucht, was mich an meinem Verständnis doch zweifeln lässt: Ich hatte bisher eine Unit, nennen wir sie 'Autos', in der waren die die Klasse 'Auto', sowie die einzelnen Klassen 'Ford', 'Audi' und 'VW' mit allem drum und dran deklariert. Nun wurde mir das zu unübersichtlich, und ich wollte 'Ford', 'Audi' und 'VW' in jeweils eigene Units verschieben, und sie im Interface-Teil unter Uses zu 'Auto' hinzufügen. Jetzt muniert aber die Unit 'Parkhaus', in die ich 'Auto' eingebunden habe, sie würde die Klassen 'Ford', 'Audi'... nicht finden. Haut und Schlagt mich, aber bitte erklärts mir nochmal... |
AW: Problem mit Uses-Klausel
In Parkhaus musst Du Ford und Audi auch nochmal mit aufnehmen, da Parkhaus sonst wirklich nur Auto kennt.
Bei komplexeren Verschachtelungen muss man darauf achten, dass im Delphi keine zirkulären units verwendet werden können. Wenn A auf B zugreift und B auf A dann muss eine der Bezüge im Implementationsteil definiert werden. Eine Möglichkeit, so etwas loser zu lösen sind Schnittstellen. Dann müssen die konkreten Klassen bzw. Units nicht unmittelbar bekannt sein. Die Verwendung schon Schnittstellen macht aber zusätzlichen Aufwand. Je nach Projekt und Erfahrungen kann man diese aber nutzen. EDIT: Oh! Lazarus! Dann muss das so nicht stimmen! |
AW: Problem mit Uses-Klausel
Hmm, das ist ja dann ungeschickt. Angenommen, jemand schreibt eine komplexere Komponente. Dann weiß der Endbenutzer doch gar nicht, was dafür alles verwendet wurde, sondern fügt auch nur die jeweilige Unit mit der Komponente ein. So hatte ich das eigentlich geplant, in C ging das immer. Mache ich hier nen MDF (Mega Denkfehler)?
|
AW: Problem mit Uses-Klausel
Bei eine Komponente gibt es auch noch die Möglichkeit bestimmte Units automatisch einbinden zu lassen. Das passiert aber zur DesignTime und wird von der IDE gesteuert.
Klatscht man eine Komponente auf die Form und kompiliert (oder speichert), dann wird die uses Liste auf einmal erweitert um die fehlenden units für diese Komponente(n). Ansonsten ja, da muss man wissen, welche Unit benötigt wird. |
AW: Problem mit Uses-Klausel
Es ist auch üblich, dass man nicht alles und jeden aus der Uses-Hierachie "vererbt". Das wäre ja ein heilloses Durcheinander im Scope der letztendlichen Programme! Normal ist, dass man seine Klassen/Komponenten so designed, dass man über diese und ihrer Unit alle nötigen Aufgaben mit ihr erledigen kann.
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. |
AW: Problem mit Uses-Klausel
Verstehe ich das richtig:
Units 'Lenkrad', 'Reifen', 'Felge', 'Getriebe', ... werden in unit 'Auto' benötigt. Wenn Ich jetzt 'Auto' benutzen möchte, dann muss ich auch alle dafür benötigten Unter-Units immer mit einbinden? |
AW: Problem mit Uses-Klausel
Die Unit 'Parkhaus' muss die Klassen 'Ford', 'Audi' und 'VW' normalerweise auch nicht kennen.
Alle für Parkhaus benötigten Methoden und Eigenschaften sollten schon in der Basisklasse "Auto" deklariert sein. Die Implementierung der Methoden und die Werte der Eigenschaften können dann für jede abgeleitete Klasse unterschiedlich sein. Wenn du auf Eigenschaften von Auto zugreifen möchtest deren Typen in 'Lenkrad', 'Reifen', 'Felge', 'Getriebe' deklariert sind, müssen die jeweiligen Units auch eingebunden werden. |
AW: Problem mit Uses-Klausel
Nein, nur wenn Du auf aAuto.Lenkrad.Durchmesser zugreifen willst.
In dem Fall musst Du wissen, was ein Lenkrad ist und welche Eigenschaften das hat. Alternativ kannst Du dem Auto aber auch eine Schnittstelle hinzufügen: aAuto.Lenkraddurchmesser. Das könnte z.B. eine Funktion sein, die dann (intern) auf das Objekt TLenkrad zugreift. |
AW: Problem mit Uses-Klausel
Aaaah, ok jetzt fällt die Rupie. Dh wenn ich zur Klasse 'Auto' ne Funktion 'GetLenkradDurchmesser' einfüge, dann kann ich das "Tunneln". Danke
|
AW: Problem mit Uses-Klausel
Also so ganz ist das ja nicht :)
Delphi-Quellcode:
unit AutoTeile;
interface type TLenkrad = class property Durchmesser : integer; end;
Delphi-Quellcode:
unit Auto;
interface uses AutoTeile; type TAuto = class property Lenkrad : TLenkrad; end;
Delphi-Quellcode:
unit MyMainUnit;
interface uses Auto; // kennt nur Auto var MeinAuto : TAuto; // und doch geht der Zugriff auf MeinAuto.Lenkrad.Durchmesser |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:56 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz