Aufbau eigene Klasse mit Property und TStrings

[Jens Hartmann]

Zitat von sx2008:

Die perfekte Lösung wäre also die, dass die Klasse TMB100 die Einstellungen für die serielle Schnittstelle überhaupt nicht zu kennen braucht, sondern sie braucht nur zu wissen welche COM-Port-Komponente sie benützen soll.

Genau das eben nicht. Ich werde später mehrer Klassen schreiben. Je nach angeschlossener und Lizenzierter Hardware, wird die entsprechende Klasse genommen und die Einstellungen der Hardware der ComPort Komponente zugewiesen. Die Anwendung und der Dienst sollen später 4 Ports verarbeiten. In der aktuellen Entwicklungsphase mache ich das zur Zeit folgendermaßen...

Ich habe einen Compilerschalter eingebaut, welcher mir je nach Lizenz die Klassensteuerung übernimmt. Somit bin ich mir sicher, das wirklich nur Lizenzierte Funktionen mit in die Anwendung kompiliert werden.

Delphi-Quellcode:

unit psComServMain;
{$I CompilerSchalter.inc}
//...
type
  THardware = (MB100, MB256, ESSERIQ8, BOSCHUEZ);
//..
procedure TfMain.FormCreate(Sender: TObject);
var
  Hardware : THardware;
begin
  try
    Caption := FormCaption + GetVersionInfos(Application.ExeName);
      {$IFDEF MB100_P1}//Eine Hardware vom Typ MB100 an COM1
        DataModuleServer.SetComPort(0,1);//0=MB100,1=COM1
      {$ENDIF}

Gruß Jens

[sx2008]

Ist es nicht so, dass es 4 verschiedene Hardware-Geräte gibt, die alle über die serielle Schnittstelle angesteuert werden?
Sagen wir mal es handelt sich um Alarmanlagen von verschiedenen Herstellern.
Jedes Hardware-Gerät hat ein etwas anderes Datenprokoll.
Aber die Gemeinsamkeit ist doch, dass immer die serielle Schnittstelle für die Kommunikation benützt wird.
Man wird daher auch immer die gleiche Komponenten-Klasse für die ser. Schnittstelle benützen.

Also könnte man doch folgende gemeinsame Basisklasse erstellen:

Delphi-Quellcode:

TAlarmAnlage = class
public
  property ComPort : TComPort read FComPort write FComPort;  // *)
end;

TMB100 = class(TAlarmAnlage)
...
end;

Das Property bei *) ist nun so zu verstehen:
Ich, die Klasse TAlarmAnlage, erwarte von dem Programmierer, dass ich ein Objekt vom Typ TComPort übergeben bekomme; ansonsten kann ich nicht arbeiten.
Ausserdem erwarte ich, dass der Zustand der seriellen Schnittstelle gleich "Connected" ist.
Baudrate, Parity,usw. sind mir piepegal; gib' mir einfach eine aktive Komponente über die ich kommunizieren kann!

Jemand, der mit der Klasse TMB100 arbeiten will muss also zuerst ein Objekt der Klasse TComPort erzeugen, dann Baudrate, Parity,usw. einstellen und die Schnittstelle öffnen.

Die Klasse TAlarmAnlage machst es sich selbst ganz einfach und überträgt die Aufgabe der Initialisierung des Kommunikationsobjekts an denjenigen, der die Klasse benützen will.
Was für Dich im ersten Augenblick vielleicht wie Faulheit aussieht ist Softwaretechnisch aber ein grosser Vorteil.
Die Klasse könnte genausogut eine geöffnete TCP/IP-Verbindung verlangen und darüber kommunizieren ohne sich das Geringste um die IP-Adresse zu scheren.
TAlarmAnlage braucht einfach nur ein Kommunikations-Objekt über das sie lesen und schreiben kann.

[Jens Hartmann]

Das Problem ist etwas größer, zumindest glaube ich das, als wie es aussieht. Also ich versuche es mal zu
beschreiben.
Ich habe 10 verschiedene Hardwarekomponenten (Aktuell, es können mehr werden).
Zusätzlich möchte ich wenigstens, gleichzeitige 4 Verbindung über die Serielle Schnittstellen ermöglichen. Soll
bedeuten, der entsprechende PC stellt die Schnittstellen COM1-COM4. Oder COM1, COM3, COM4, COM5 wie auch immer.

Daraus folgt doch:

Ich nehme ein Datenmodule, füge diesem 4 ComPort Komponenten zu, welche über den Dienst oder über die Anwendung
konfiguriert und genutzt werden können.

Das Datenmodule speichert die Empfangenen Daten in der Datenbank und liefert der Anwendung die visuelle Anzeige.
Der Dienst benötigt dies ja nicht. Deshalb möchte ich dieses auch über Propertys lösen, da ich diese ja aus dem
Dienst einfach nicht abfragen brauche. Die Anwendung nutzt diese Propertys.

Also, 1 Anwendung oder 1 Dienst

nutzen 1 Datenmodul mit der Anbindung an die entsprechende Datenbank.

Dann kann das Datenmodul mit der entsprechenden Klasse kommunizieren. Soll heißen, da jede Hardware andere
Einstellungen nutzt(Baudrate, Parität, Parser), verankere ich die Einstellungen doch am besten in der
entsprechenden Klasse. So habe ich doch den Vorteil, einen neue Hardware, eine neue Klasse. An dem Datenmodul
muss ich nichts mehr ändern. Das Datenmodul holt sich einfach aus der entsprechenden Klasse die Konfiguration
der Schnittstelle.
Desweiteren wird ja der Parser der entsprechenden Hardware in der Klasse implementiert. Somit habe ich alles
was zur Hardware MB100 gehört in der Klasse MB100, usw.
Das, so denke ich, würde zur Folge haben, das die Anwendung irgendwann fertig ist und nur noch der
BUG-Beseitigung Aufmerksamkeit gespendet werden muss. Sollte eine neue Hardware notwendig sein, wird eine neue
Klasse geschrieben, welche erstmal kopiert und nur noch angepasst werden muss. Die Klasse kann ins Datenmodul
implementiert werden fertig.

Naja, vieleicht sind das ja Traumvorstellungen. Aber so ist zur Zeit mein Überlegung.

Vieleicht aber zeigt Ihr mir wo die Gedanken Fehler liegen,

Gruß Jens

PS: Da glaubt man, man hat viel gelesen und es verstanden, aber irgendwie ist man immer noch so dumm wie vorher.

Quellen:
Kurzreferenz
Wikibooks

und viele mehr....

[Bummi]

@Jens

Ich habe nach dem von Dir beschriebenen Schema bereits Steuerungen/Messungen umgesetzt, das funktioniert. Eine Basisklasse mit allgemeinen Eigenschaften und Ereignisbehandlungsroutinen, Fehlerroutinen (z.T. als virtual und oder abstract) und darauf die spezifischen Klassen für das Parsen/Interpretieren/Schreiben.