Jobliste Kommunikation mit externem Gerät

[Der_Unwissende]

Das Speerobjekt brauchst du eigentlich nur in einer Unit, da wo die Liste verwaltet wird. Letztlich muss die Liste ja auch allen die darauf zugreifen bekannt sein. Du könntest dies verhalten z.B. in einer eigenen Unit kapseln (und die Liste umhüllen).
Dann hast einen Wrapper, der dir einfach sagt ob die Liste leer ist, der ein Objekt hinzufügen kann und wenn sie nicht leer ist dir das nächste Objekt zurück gibt. Beim erzeugen dieses Wrappers legst du eine Instanz Variable vom Typ TCriticalSection an, die dann immer gesperrt wird, bevor du ein Element in die Liste tust bzw. aus ihr entfernst:

Delphi-Quellcode:

type
  TJobList = class(TObject)
    private 
      FSyncObj : TCriticalSection;
      FList : TObjectList;
    public 
      constructor create;
      destructor destrory; override;

      procedure addJob(const Job : TBaseJob);
      procedure getNextJob(out Job : TBaseJob);
      function isEmpty : Boolean;
  end;

// Konstruktor und Destruktor sind klar, erzeugen bzw. freigeben der Objekte

procedure TJobList.addJob(const Job : TBaseJob);
begin
  self.FSyncObj.Acquire;
  self.FList.Add(Job);
  self.FSyncObj.Release;
end;

procedure TJobList.getNextJob(out Job : TBaseJob);
begin
  self.FSyncObj.Acquire;
  Job := TBaseJob(self.FList.Extract(self.FList[0]));
  self.FSyncObj.Release;
end;

function TJobList.isEmpty : Boolean;
begin
  self.FSyncObj.Acquire;
  result := self.FList.Count > 0;
  self.FSyncObj.Release;
end;

[DelphiManiac]

Super klappt alles wie gewollt.

Danke für deine Hilfe!!

[DelphiManiac]

@Der_Unwissende

Hallo, eine Frage hätte ich noch:

beim jeglichen Zugriff auf die VCL muss man ja synchronisieren, dass ist mir ja klar, da sie nicht Threadsafe ist.

Nun habe ich ja jetzt meine verschiedenen Jobs
wie zb.

ReadMesswerte

In meinem Thread arbeite ich nun die Liste ab:

Delphi-Quellcode:

procedure TJobListThread.Execute;
var
  einJob: TBaseJob;
begin

  { Thread-Code hier einfügen }
  while NOT (Terminated) do
  begin
    If NOT (JobListe.isempty) then
    begin
      JobListe.getNextJob(einJob);
      einJob.doJob;
      Jobliste.deleteJob(einJob);
//      Synchronize(einJob.doJob);
      Sleep(100);
    end;

  end;

end;

Meine Frage nun, ich habe in meiner spezifischen Implementation von doJob eine Funktion, die die Einzelnen Messwerte holt und die VCL aktualisiert (Labels...usw) eine Art Observer Pattern.
Wie kann ich denn diesen Zugriff auf die VCL synchronisieren, ich will ja nicht den kompletten Job Synchronisieren,...
dann bräuchte ich ja den Thread nicht .


Vielen Dank

[Der_Unwissende]

Zitat von DelphiManiac:

Meine Frage nun, ich habe in meiner spezifischen Implementation von doJob eine Funktion, die die Einzelnen Messwerte holt und die VCL aktualisiert (Labels...usw) eine Art Observer Pattern.
Wie kann ich denn diesen Zugriff auf die VCL synchronisieren, ich will ja nicht den kompletten Job Synchronisieren,...
dann bräuchte ich ja den Thread nicht .

Na am einfachsten, in dem du die Aktualisierung der VCL in eine Extra Methode auslagerst. Du hast ja in jedem Job eine bestimmte Anzahl von neuen Messwerten, die du gerne eintragen/anzeigen würdest. Machst du das alles in einem Rutsch, ist die Synchronisation pro VCL-Element wahrscheinlich günstiger, als wenn du hier nach jedem einzelnen Punkt synchronisierst.
Also einfach den Job ausführen, dir merken welche Werte dabei verändert wurden und dann in einer Methode xyz (die dann auch in der abstrakten Klasse verfügbar ist) die VCL Komponenten aktualisieren.

Delphi-Quellcode:

procedure TJobListThread.Execute; 
var 
  einJob: TBaseJob; 
begin 

  { Thread-Code hier einfügen } 
  while NOT (Terminated) do 
  begin 
    If NOT (JobListe.isempty) then 
    begin 
      JobListe.getNextJob(einJob); 
      einJob.doJob; 
      Jobliste.deleteJob(einJob); 
      synchronize(einJob.xyz);
//      Synchronize(einJob.doJob); 
      Sleep(100); 
    end; 

  end; 

end;

Ok, am Namen xyz kann man noch arbeiten , aber die Idee ist denke ich klar. Du könntest hier z.B. auch einen Datensatz zurückgeben, der alle Messwerte enthält und die GUI kümmert sich selbst um die aktualisierung.
Was deine Messungen angeht, so hätte ich hier mal noch eine Frage, ob du hier wirklich immer alle 100 ms etwas machst? An sich denke ich wäre es schöner, wenn die Jobliste alle Jobs (wenn mal welche in der Liste sind) so schnell wie möglich abarbeitet. Sollte dann eine Pause zwischen zwei Jobs gemacht werden, wäre es irgendwie schöner, wenn man dies hier in den Jobs festlegen kann.
Andererseits gibt es natürlich auch Zeitpunkte an denen die Jobliste keine Jobs beinhaltet, dann sollte natürlich auch der Thread nicht wirklich viel tun, deshalb würde ich dir empfehlen, dass du den Thread immer schlafen legst (self.suspend) und den von außen halt einfach aufweckst, wenn der schläft bevor und du einen Job einfügst.

[DelphiManiac]

@Der_Unwissende
Hi danke,

ja die Idee ist klar.

Eines der Gründe warum ich mich für Delphi als Programmiersprache entschieden habe ist, diese Forum gewesen...
Habe also keinen Fehler gemacht, was das angeht

Meine Jobliste, soll an sich eigentlich immer was zu tun bekommen
Es soll z.B.: immer der Status des Geräts gelesen werden und bestimmte Parameter (Druck/Temp usw) dann kommen je nach angezeigter Maske noch andere Werte hinzu, die ständig, bzw einmalig (Beispiel anzeigen einer Kalbrierungsmaske (einlesen der Kalibrierungswerte)) gelesen werden müssen.

Bin immer noch nach etwa 1 1/2 Jahren dabei ein Programmdesign (wobei ich den Code + Gui und deren maximale Trennung voneinander)
Suche Beispielprojekte, die etwas konkreter sind.
Ich habe im Forum gesehen, dass du dich mit Entwurfsmustern sehr gut auskennst.
Bin auch gerade dabei ein paar Bücher zu wälzen zu einigen Mustern.
Aber wie gesagt, mir fehlt da oft die praktische Anwendung.
Wollte dich mal fragen, ob du mir mal eines deiner Projekte schicken könntest?

Ich weiss ist wahrscheinlich zuviel verlangt, aber irgendwie muss man ja dazulernen.
Um was es in dem Projekt geht ist mir eigentlich egal, es geht mir hauptsächlicht um die Kommunikation von Fachkonzept und GUI.
Vielen Dank ...

Gruß DelphiManiac

[Der_Unwissende]

Zitat von DelphiManiac:

Wollte dich mal fragen, ob du mir mal eines deiner Projekte schicken könntest?

Ich weiss ist wahrscheinlich zuviel verlangt, aber irgendwie muss man ja dazulernen.
Um was es in dem Projekt geht ist mir eigentlich egal, es geht mir hauptsächlicht um die Kommunikation von Fachkonzept und GUI.
Vielen Dank ...

Ja, ich verstehe schon was du meinst, dass ist glaube ich auch wirklich eines der Probleme am Programmdesign, man kann es nur mit der Erfahrung verbessern. An sich ist es aber so, dass du nie das perfekte Design von Anfang bis Ende haben wirst, also nicht enttäuscht sein, wenn du an irgendeiner Stelle etwas ändern musst. Die Bücher über die Planung, die Objekt Orientierung, die Entwurfsmuster, ... helfen zwar, aber sie können halt auch nicht mehr leisten als guten Code, den man leicht anpassen kann. Dagegen, dass einige Projekte/Kunden plötzlich doch eine Menge neuer (komplett anderer) Wünsche haben, dagegen kann man nichts tun. Die resultierenden Probleme halten sich damit halt nur stark in Grenzen.
Was ein Projekt angeht, so muss ich dich leider enttäuschen, die wo du ein sauberes Design und eine Halbwegsentkopplung vorfindest sind alles kommerzielle Produkte, an denen hält mein Arbeitgeber bzw. verschiedene Kunden die Copyrights, die darf ich also nicht ohne weitere herausgeben. Ich denke dass verstehst du und wirst das nicht persönlich nehmen. Da ich privat dann immer lieber das leben geniesse als zu programmieren, kann ich dir leider auch hier kein Programm zu schicken.
Ich kann dir nur anbieten dir weiterhin (sogut es geht) bei Entscheidungen eine weitere Meinung zu liefern, wobei ich sagen muss, dass ich genau wie Du und alle anderen auch nur Ideen für's Design habe, es können sich alle gleich irren.

Ich denke das wichtigste für ein gutes Desing ist und bleibt die Einfachheit. Kleine Units, die genau ein Objekt (soweit du OO verwendest) beinhalten (bzw. analog eine bestimmte Funktionalität). Auch dieses Objekt / die Funktionen / Methoden sollten möglichst einfach gehalten sein. Das führt zu wenig Fehlern und verständlichen Code. Möchte man dies konsequent erreichen, führt dass quasi automatisch zur Entkoppelung, da die Darstellung eine andere Funktionalität als die Verwaltung der Daten oder die Logik ist. Design-Pattern helfen hier einfach nur bei dem Verständnis für bestimmte Dinge. Design Entscheidungen sollten immer gut dokumentiert werden, da es sie das Programm ausmachen. Später kann man anhand dieser Entscheidungen leicht nachvollziehen warum das Programm wie aufgebaut ist, was die Wartbarkeit erhöht. Bei den Design-Pattern hat man damit zwei Vorteile:
1. Jmd. hat hier schon ein bestimmtes Problem gelöst
2. Die Lösung ist eindeutig definiert. Verweist man auf ein Pattern ist klar was gemeint ist

Der Rest ist dann noch ein wenig Abstraktion. An sich sollte es bei komplexeren Vorgängen, an denen Verschiedene Objekte beteiligt sind immer einen Controller geben, der zwischen den einzelnen Objekten vermitteln kann. Nur der muss dann alle Objekte kennen, diese sich jedoch nicht. Der Controller kann wiederum mit Abstrakten Klassen oder Interfaces arbeiten, so dass hier die Logik des Controllers unabhängig von der Implementierung der von ihm verwalteten Klassen erhalten bleiben kann. Ja, es ist klar, dass ein Kontroller dann wiederum zwischen Teilsystemen vermitteln kann, wobei der Controller hier nur zwischen anderen Controllern (denen des Teilsystems) vermittelt.

Versucht man diese Prinzipien in eigenen Programmen umzusetzen, so hat man (meiner Erfahrung nach) immer eine recht orgentliche Basis. Wie gesagt, die höchste Priorität hat imho die Einfachheit.

Gruß Der Unwissende