vererbende Klasse oder Interface? oder beides?

[Vis]

Zitat:

Zitat von jaenicke (Beitrag 1233246)

[DELPHI]

Delphi-Quellcode:

var
  a: TMessgerät;
  b: ISchreibenLesen;
begin
  a := TMessgerät2.Create;
  b := a as ISchreibenLesen;
  b.readStuff;
end;

(Wobei das Objekt nach der Methode durch das Interface freigegeben wird.)

Ein solcher Aufruf ist mir noch nicht geläufig. Wo liegt der Unterschied wenn ich stattdessen mit dem Objekt a arbeite? Also a.readStuff.


@sx2008
Also der Datentransport ist schon in ein eigenen Klasse mit direktem Zugriff auf den GPIB-Bus.

Delphi-Quellcode:

procedure send (addr : integer; s : AnsiString; var status : integer);
procedure enter (var s : Ansistring; maxlen : word; var len : word;
                       addr : integer; var status : integer);

procedure ieee488_send (addr : longint; c : Pointer; len : longint; var status : longint) stdcall;
        external 'IEEE_32M.DLL' name 'IEEE488_SEND';
procedure ieee488_enter (c : Pointer; maxlen : longint; var len : longint;
                 addr : longint; var status : longint) stdcall;

Also diese Klasse TGPIB weiß auch nichts von anderen Klassen.

Nur sind eben die Befehle für die Messgeräte unterschiedlich, z.B. Agilent und Keithley.

Delphi-Quellcode:

procedure send (22, 'ID?', status); //Agilent
procedure send (22, 'IDN?', status); //Keithley

Für jede Unterklasse muss man also fast alle Methoden implementieren. Den Vorteil den ich sehe, ist dass man einmal Methodennamen festlegt (auf Höhe der abstrakten TMessgeräte-Klasse), die dann immer wieder gebraucht werden und man so eine einheitliche Syntax über alle Messgeräte hat.

Vergleichen kann man das vielleicht mit der IVIDmm Klasse zur Ansteuerung von Messgeräten. Die besitzt auch ganz allgemeine Methoden Initialize, Close, Configure und Propertys Measurement.Read usw. Was am Ende für ein Messgerät dran hängt ist egal.

Ob es sich bei mir wirklich so allgemeingültig durchführen lässt, bin ich gerade am probieren.

[sx2008]

Zitat:

Zitat von Vis (Beitrag 1233382)

Nur sind eben die Befehle für die Messgeräte unterschiedlich, z.B. Agilent und Keithley.

Delphi-Quellcode:

procedure send (22, 'ID?', status); //Agilent
procedure send (22, 'IDN?', status); //Keithley

Für jede Unterklasse muss man also fast alle Methoden implementieren.

Muss man nicht unbedingt wenn der Unterschied nur in der Schreibweise der Befehle liegt.

In der Basisklasse führst du eine virtuelle Funktion ein die eine Kennung in einen Befehl umsetzt:

Delphi-Quellcode:

const
  QUERYSTATUS = 1;
  RESETDEVICE = 2;
  // usw.

function TMessgeraet.GetCommandString(commandid:Integer):string;  // virtual, protected
begin
  raise Exception.CreateFmt('command %d not implemented (%s)', [commandid, Classname]);
end;

function TMessgeraetAgilent.GetCommandString(commandid:Integer):string; // override;
begin
  case commandid of
    QUERYSTATUS: Result := 'ID?';
    RESETDEVICE: Result := ...;
  else
    result := inherited GetCommandString(commandid);
end;

Anstelle der Konstanten kann man auch einen Aufzählungstyp verwenden.

[jaenicke]

Zitat:

Zitat von Vis (Beitrag 1233382)

Ein solcher Aufruf ist mir noch nicht geläufig. Wo liegt der Unterschied wenn ich stattdessen mit dem Objekt a arbeite? Also a.readStuff.

Man braucht für die Initialisierung kein weiteres Interface und muss diese Funktionalität auch nicht nach außen veröffentlichen. Danach packt man das Objekt in eine Interfacevariable und aktiviert damit die Referenzzählung.

Dieses Interface kann dann auf die zur Initialisierung notwendigen Routinen nicht zugreifen und es gibt auch kein anderes Interface, auf das man dafür casten könnte.

Theoretisch kann man auch hinterher noch auf den Objekttyp casten, sofern man sich im gleichen Modul der Anwendung befindet (selbe Exe, selbe DLL, ..), aber das sollte bei sauberer Implementierung aller Schnittstellen nicht notwendig sein.

[Vis]

@sx2008
interessante Idee. Werd ich mal im Hinterkopf behalten.

@jaenicke
danke für die Antwort. Vielleicht werd ichs demnächst verwenden.