Zitat von
DelphiManiac:
TObjectlist ist ja eine Klasse, die Zeiger speichert, sehe ich doch richtig, oder?
Nicht ganz. Also ist nicht direkt falsch, aber es sind sehr spezielle Zeiger. Du speicherst vielmehr Referenzen. Eine Referenz ist ein Zeiger auf ein Objekt, und damit halt immer auf einen Nachfahren von TObject. Jedes Objekt muss damit z.B. die Methode Free besitzen, so dass diese Liste den Speicher der Elemente in ihr auch selbst frei geben kann, wenn sie zerstört wird.
An sich ist hier dann die Idee, dass du dir einfach ein Abstraktes BasisObjekt schaffst.
Delphi-Quellcode:
type
TBaseJob = class(TObject)
public
procedure doJob; virtual; abstract;
end;
Dieses Objekt hat eine Methode doJob, die hier aber abstrakt (nicht implementiert) ist. Du hast somit nur festgelegt, dass jeder Nachfahre eine solche doJob Methode besitzen muss, die irgendwie implemntiert werden kann.
Damit hast du auch schon die Basis für alle Jobs:
Delphi-Quellcode:
type
TStopJob = class(TBaseJob)
public
procedure doJob; override;
end;
TReadHerstellerDatenJob = class(TBaseJob)
public
procedure doJob; override;
end;
...
procedure TStopJob.doJob;
begin
// konkrete Implementierung
end;
...
Ok, soweit hast du erstmal nur eine Menge von Klassen und vielleicht auch eine Menge an Overhead. Wo liegt jetzt also der Sinn? Ganz einfach, du kannst nun eine Liste von TBaseJobs verwalten. Vererbung kann in der Programmierung auch als Erweiterung oder Spezialisierung beschrieben werden. TStopJob und TReadHerstellerDatenJob sind Erben von TBaseJob. Das heißt, dass sie mindestens dass können, was auch TBaseJob kann. Du kannst sie also auch als TBaseJob behandeln. So kann dein TStopJob noch 10 weitere Funktionen haben, behandelst du ihn als TBaseJob, kannst du nur auf die Funktion doJob zugreifen (weil das alles ist, was ein TBaseJob hat). Diese Funktion kann aber natürlich auf alle anderen Funktionen von TStopJob zugreifen und alle Variablen lesen (usw).
So, nun erzeugst du zu einfach die speziellen Jobs, die du benötigst und tust die in eine TObjectList. Die TObjectList speichert hier alles was du reintust als TObject ab. Wenn du also einen Job rausnimmst, musst du ihn casten. Da für alle Jobs eine Basis existiert, castest du in ein TBaseJob (muss für alle Jobs klappen) und rufst von diesem TBaseJob die Methode doJob auf. Damit ist es egal was für einen Job du gerade aus der Liste genommen hast, du musst keine Details über diesen Job kennen, du weißt dass er eine Methode doJob hat und die verwendest du:
Delphi-Quellcode:
// hinzufügen von neuen Jobs:
self.objectList.Add(TStopJob.Create(...));
self.objectList.Add(TReaderHerstellerAngabenJob.Create(...));
self.objectList.Add(TStopJob.Create(...));
...
Delphi-Quellcode:
var buffer : TBaseJob;
// Abarbeitung der Jobs
while (self.objectList.Count > 0) do
begin
buffer := TBaseJob(self.objectList[0]);
buffer.doJob;
self.ojectList.remove(0); // hier musst du schauen ob die Funktion so heißt, kann auch delete sein
end;
Ja, ist jetzt hier etwas aus eine bestimmten Prozedur rausgenommen, aber ich hoffe die Idee ist so klar.
Die eigentliche Implementierung, wie man einen Job stoppt oder eben hinzufügt steckt nun in den Hüllklassen (Wrapper), hier wären dass TStopJob usw. Die beerben alle eine Basisklasse, die einfach die Signatur einer Methode festlegt, die alle Nachfahren besitzen müssen.
Die JobListe macht wiederum nichts anderes als den ersten enthaltenen Job zu entnehmen und abzuarbeiten. Was für ein Job das genau ist, ist der Liste egal. Die Logik steckt in der Instanz, die diese Methode überschrieben hat.
Diese Vorgehensweise entspricht ein wenig dem Kommando-Pattern.
Gruß Der Unwissende