Zitat von
1ceman:
Also wie schon gesagt verwaltet diese
Unit Richedits und Buttons, die während der Laufzeit erstellt werden.
Diese Richedits liegen auf einem TabControl. Wenn man jetzt einen der erzeugten Button drückt, soll dem TabControl ein Tab hinzugefügt
werden und das entsprechende Richedit angezeigt werden. Das Problem ist jetzt nur, dass ich mit der Buttonprocedure auf das TabControl auf
der Form zugreifen muss, was halt nicht geht.
Ich hoffe das ich mein Problem genau genug beschrieben habe, damit ihr mir sagen könnt, wie ich es am besten löse.
Ja, das ist schon viel besser erklärt.
Du sagst aber vollkommen richtig:
Zitat von
1ceman:
Diese Richedits liegen auf einem TabControl
Wie gesagt, das ist so vollkommen richtig. Sie liegen später auf einem Tabcontrol, du musst aber für ihre Verwaltung doch gar nicht wissen auf welchem, oder? Du hast also die Möglichkeit (z.B.) beim anlegen deiner Klasse ein TabControl zu übergeben.
Du könntest also praktisch etwas in der Richtung erstellen:
Delphi-Quellcode:
TLinList = class(TObject)
private
FTabControl : TTabControl;
...
public
constructor create(TabControl : TTabControl);
...
end;
Dann hättest du die Möglichkeit, dass dein Formular zwar die
Unit U_List kennen müsste, aber nicht umgekehrt. Die U_List bekommt dann im Konstruktor ein TTabControl übergeben. Es muss nicht wissen wo dieses herkommt! So hast du alle Eigenschaften eines TTabControls ohne dass du die
Unit kennst aus der dieses kommt. Erstellst du jetzt also ein zweites Formular in einer weiteren
Unit, so könntest du auch diesem die Funktionalität von U_List zur Verfügung stellen (um nochmal die Wiederverwendbarkeit zu verdeutlichen).
Die Frage ist halt welche Eigenschaften von einem TTabControl du wirklich benötigst.
Du kannst halt die Vorteile der Objekt Orientierung (OO) immer ganz gut nutzen. Hier siehst du ja schon, dass du nun ein beliebiges TTabControl übergeben könntest. Dabei ist es egal, woher es kommt und die
Unit funktioniert mit jedem TTabControl. Allerdings gibt es Komponenten, die du sicherlich noch viel allgemeiner verwenden möchtest. Typische Beispiele wären hier alle
VCL-Komponenten. Du möchtest ein Label sicherlich sowohl auf einem beliebigen Formular, einem Frame, einem Panel, ... (insbesondere auch eigenen Komponenten) verwenden können. Hier kannst du dann die Vererbung ausnutzen.
Klassen können von anderen Klassen erben. Statt vom Vererben kann man auch vom Erweitern sprechen (in Java wird z.B. das Schlüsselwort extends verwendet). Jedenfalls hat jeder Erbe alle Eigenschaften seines Vorgängers (genauer aller Vorgänger).
Die Vererbungshierachie findest du in der Delphi Hilfe unter Hierachie.
So erbt z.B. jede Klasse aut. von TObject. Alle Eigenschaften und Methoden von TObject stehen damit jeder Klasse zur Verfügung. Das siehst du z.B. immer dann, wenn du im Konstruktor inherited create aufrufst. Damit musst du dich einfach nicht selbst um das Erzeugen einer neuen Instanz kümmern.
In deinem Fall solltest du schauen, welche Eigenschaften du wirklich benötigst. Würdest du z.B. im Konstruktor statt einem TTabControl dann ein TCustomTabControl verwenden, hast du hier wieder eine Menge mehr Möglichkeiten. TTabControl ist eine sehr konkrete Klasse, alle anderen kannst du hier nicht übergeben. TCustomTabControl hingegen ist eine (abstrakte) Basisklasse. Verwendest du diese, kannst du alle Nachfahren übergeben (und hast alle Eigenschaften zur Verfügung). Damit könntest du dann alle TTabControls übergeben, aber z.B. auch alle TPageControls (falls du hier mal was ändern möchtest) oder alle anderen Nachfahren (z.B. die TabControls aus den Jedis).
Ich hoffe, das der Vorteil grob klar ist. Im Moment bindest du dich halt ein spezielles Formular. Das ist nie gut! Alle großen Systeme arbeiten in getrennten Schichten, aber auch sehr viele kleinere tun dies. Und das nicht ohne Grund. Schon das sehr einfache MVC Konzept bringt dir eine Menge Vorteile. Deswegen kann ich dir nur empfehlen es dir anzuschauen!
Auch wenn es nicht überall nötig scheint, Projekte wachsen schneller als man glaubt und einen Nachteil hat diese Trennung nie. Solltest du z.B. ein zweites Formular nehmen und hier die gleiche Verwaltung von Buttons und TabControls verwenden wollen, kannst du diese Verwaltung natürlich auch in die zweite
Unit kopieren. Dann merkst du irgendwann, dass dir ein Fehler unterlaufen ist. Möchtest du den korrigieren, darfst du also in allen Units die diese Verwaltung verwenden gehen und es hier anpassen (überleg dir einfach mal, was ist wenn es mehr als 2 sind). Noch ein wenig später, merkst du dass du das alles viel effizienter machen könntest...
Wie gesagt, in jede
Unit sollte immer nur die Lösung eines Problems / einer Gruppe von Problemen rein. Eine Klasse pro
Unit finde ich persönlich auch vollkommen ok. Das ist dann aber eher Geschmackssache. Nur je kleiner eine Datei ist, desto leichter blickst du in dieser
Unit durch, desto klarer ist was in dieser
Unit passiert, desto weniger Abhängigkeiten ermöglichst du, usw.