Neue Klasse erstellen mit 2 Klassen als Attribute

[Coffeecoder]

Hallo Leute,

Ich mache mir seit ein paar Tagen Gedanken um eine Klasse zu erstellen.
Ich weiss, dass Delphi wie auch in Java keine Mehrfachvererbung unterstützt!

Ich habe die zwei Klassen TComPort und TComTerminal vom Autor Dejan Crnila.
Zuerst einmal zu meinem Vorhaben, ich brauche die Attribute wie Baudrate, ComPort, Flow Control von der Klasse TComPort und die Methode StrReceive von der Klasse TComTerminal.
In meiner Klasse will ich noch ein paar Methoden und Attribute ergänzen.

Mein erster Ansatz war beide Klasse TComPort und TComTerminal als Attribut in meiner neuen Klassen zu deklarieren und dann im Konstruktor zu erstellen. Würdet Ihr das auch so machen?

Mein anderer Ansatz war von der Klasse TComPort oder von TComTerminal erben und dann die andere Klasse als Attribut ergänzen? Oder ganz anders?

Wenn Ihr mehr Informationen braucht, einfach Bescheid geben :)

Danke im Voraus.

[DeddyH]

Es kommt ein wenig auf die Beziehungen dieser 2 oder 3 Klassen zueinander an. Ein schneller Gedankenansatz meinerseits wäre:
- Eine Oberklasse mit den beiden Objekten als private Felder
- Die beiden Objekte werden vollständig verborgen, Zugriffe darauf geschehen indirekt über Properties bzw. Methoden.
- Das bedeutet, dass die Kommunikation mit der Außenwelt ausschließlich über die Oberklasse abgewickelt wird.

Auf diese Weise könnte man später nötigenfalls die enthaltenen Klassen gegen andere austauschen, ohne dass man das von außen mitbekommt.

[Coffeecoder]

@DeddyH: Danke schon mal für dein Vorschlag :)

Ich gebe hier noch kurz eine Beschreibung zur der Klasse die ich erstellen will:

Sie beinhaltet Methoden die die Befehle an die ComPort sendet um mit dem Gerät zu kommunizieren.
Sie bearbeitet/formatiert die Werte um in : YYYYMMDD#hh:mm#Wert und speichert nachher in einer separaten Datei ab.

Das ist der Zusammenhang der Klassen.

[DeddyH]

Ja gut, das spricht meinem Vorschlag ja nicht zuwider. Der einzige Nachteil, den ich bei meiner Lösung sehe, ist etwas Tippaufwand, da man ja mindestens für jede Property, die man "durchreichen" will, einen Getter und einen Setter braucht. Das könnte dann etwa so aussehen:

Delphi-Quellcode:

type
  TSubClass1 = class
  private
    FProp1: SomeType;
  public
    function SomeFunc: SomeOtherType;
    property Prop1: SomeType read FProp1 write FProp1;
  end;
  
  TSubClass2 = class
  private
    FProp2: SomeType;
  public
    procedure SomeProc;
    property Prop2: SomeType read FProp2 write FProp2;
  end;
  
  TMainClass = class
  private
    FClass1: TSubClass1;
    FClass2: TSubClass2;
    function GetProp1: SomeType;
    function GetProp2: SomeType;
    procedure SetProp1(const value: SomeType);
    procedure SetProp2(const value: SomeType);
  public
    function SomeFunc: SomeOtherType;
    procedure SomeProc;
    property Prop1: SomeType read GetProp1 write SetProp1;
    property Prop2: SomeType read GetProp2 write SetProp2;
  end;
  
function TMainClass.GetProp1: SomeType;
begin
  Result := FClass1.Prop1;
end;

function TMainClass.GetProp2: SomeType;
begin
  Result := FClass2.Prop2;
end;

procedure TMainClass.SetProp1(const value: SomeType);
begin
  FClass1.Prop1 := value;
end;

procedure TMainClass.SetProp2(const value: SomeType);
begin
  FClass2.Prop2 := value;
end;

function TMainClass.SomeFunc: SomeOtherType;
begin
  Result := FClass1.SomeFunc;
end;

function TMainClass.SomeProc;
begin
  FClass2.SomeProc;
end;

[Coffeecoder]

Gut das ist schon der Ansatz, den ich auch hatte.
Der Nachteil sehe ich auch darin, dass der Tippaufwand gross wird für alle Setter/Getter :pale:

Auf jeden Fall, danke für deine Tips DeddyH :)
Ich werde bei der nächsten Gelegenheit deinen Vorschlag testen.

Danke

[Sir Rufo]

Man kann sich natürlich einiges an Tipparbeit sparen, wenn es viele gleiche DatenTypen gibt:

Delphi-Quellcode:

unit uMyClass;

interface

type
  TMyBase1 = class
  private
    FMyStr : string;
    FMyInt : Integer;
  public
    property MyStr : string read FMyStr write FMyStr;
    property MyInt : Integer read FMyInt write FMyInt;
  end;

  TMyBase2 = class
  private
    FMyStr : string;
    FMyInt : Integer;
  public
    property MyStr : string read FMyStr write FMyStr;
    property MyInt : Integer read FMyInt write FMyInt;
  end;

  TMyClass = class
  private
    fMyBase1 : TMyBase1;
    fMyBase2 : TMyBase2;
    function GetString( const Index : Integer ) : string;
    procedure SetString( const Index : Integer; const Value : string );
    function GetInteger( const Index : Integer ) : Integer;
    procedure SetInteger( const Index, Value : Integer );
  public
    constructor Create;
    destructor Destroy; override;

    property FirstName : string index 1 read GetString write SetString;
    property LastName : string index 2 read GetString write SetString;

    property NameReadOnly : string index 1 read GetString;
    property NameWriteOnly : string index 1 write SetString;

    property Age : Integer index 1 read GetInteger write SetInteger;
    property Value : Integer index 2 read GetInteger write SetInteger;
  end;

implementation

{ TMyClass }

constructor TMyClass.Create;
begin
  inherited;
  fMyBase1 := TMyBase1.Create;
  fMyBase2 := TMyBase2.Create;
end;

destructor TMyClass.Destroy;
begin
  fMyBase1.Free;
  fMyBase2.Free;
  inherited;
end;

function TMyClass.GetInteger( const Index : Integer ) : Integer;
begin
  case Index of
    1 :
      Result := fMyBase1.MyInt;
    2 :
      Result := fMyBase2.MyInt;
  end;
end;

function TMyClass.GetString( const Index : Integer ) : string;
begin
  case Index of
    1 :
      Result := fMyBase1.MyStr;
    2 :
      Result := fMyBase2.MyStr;
  end;
end;

procedure TMyClass.SetInteger( const Index, Value : Integer );
begin
  case Index of
    1 :
      fMyBase1.MyInt := Value;
    2 :
      fMyBase2.MyInt := Value;
  end;
end;

procedure TMyClass.SetString( const Index : Integer; const Value : string );
begin
  case Index of
    1 :
      fMyBase1.MyStr := Value;
    2 :
      fMyBase2.MyStr := Value;
  end;
end;

end.

[DeddyH]

Wenn man die Klassenvervollständigung nutzt hält sich auch der Tippaufwand in erträglichen Grenzen ;)

[Coffeecoder]

Ich weiss dass unter Eclipse für Java mit Source > Generate Setter/Getter die ganze (unnötige) Tipparbeit einem erspart.

Gut zu wissen :)

[shmia]

Zitat:

Zitat von Coffeecoder (Beitrag 1140216)

Mein erster Ansatz war beide Klasse TComPort und TComTerminal als Attribut in meiner neuen Klassen zu deklarieren und dann im Konstruktor zu erstellen. Würdet Ihr das auch so machen?

Nö.
Mal angenommen bei dem Zielgerät handelt es sich um eine Wetterstation, die über eine serielle Schnittstelle angesprochen wird.
Dann gibt es 2 Klassen:
* TWetterstation
* TComPort
Die Klasse TWetterstation benötigt keine Baudrate, Stopbits, usw sondern
sie benötigt lediglich ein fertig konfiguriertes TComPort-Objekt.
Die ganzen Details der seriellen Parameter interessieren die Klasse TWetterstation nicht.

Dieses TComPort-Objekt wird über den Konstruktor übergeben:

Delphi-Quellcode:

TWetterstation = class(TObject)
private
  FComport : TComport;
public
  constructor Create(comport:TComPort);
  procedure Reset;
  procedure ReadWetterdaten;
  property Temperatur:double;
  property Feuchtigkeit:double;
  property Luftdruck:double;
end;

constructor TWetterstation.Create(comport:TComPort);
begin
  inherited;
  FComport := comport;
end;

Sollte die Übergabe im Konstruktor nicht möglich sein, kann man das Comport-Objekt
auch über ein Property übergeben.

[Coffeecoder]

Zitat:

Zitat von shmia (Beitrag 1140256)

Zitat:

Zitat von Coffeecoder (Beitrag 1140216)

Mein erster Ansatz war beide Klasse TComPort und TComTerminal als Attribut in meiner neuen Klassen zu deklarieren und dann im Konstruktor zu erstellen. Würdet Ihr das auch so machen?

Nö.
Mal angenommen bei dem Zielgerät handelt es sich um eine Wetterstation, die über eine serielle Schnittstelle angesprochen wird.
Dann gibt es 2 Klassen:
* TWetterstation
* TComPort
Die Klasse TWetterstation benötigt keine Baudrate, Stopbits, usw sondern
sie benötigt lediglich ein fertig konfiguriertes TComPort-Objekt.
Die ganzen Details der seriellen Parameter interessieren die Klasse TWetterstation nicht.

Dieses TComPort-Objekt wird über den Konstruktor übergeben:

Delphi-Quellcode:

TWetterstation = class(TObject)
private
  FComport : TComport;
public
  constructor Create(comport:TComPort);
  procedure Reset;
  procedure ReadWetterdaten;
  property Temperatur:double;
  property Feuchtigkeit:double;
  property Luftdruck:double;
end;

constructor TWetterstation.Create(comport:TComPort);
begin
  inherited;
  FComport := comport;
end;

Sollte die Übergabe im Konstruktor nicht möglich sein, kann man das Comport-Objekt
auch über ein Property übergeben.

Danke für deinen Vorschlag shmia.
Allerdings kommt mir da eine Frage auf: Vom TComTerminal brauch ich lediglich nur eine Methode onStrReceive, weil die TComPort Klasse nur die nötigen Parameter für die Kommunikation nötig sind.
Folglich muss ich in deinem Beispiel TWettersation doch noch die TComTerminal haben.

Dann habe ich:

Delphi-Quellcode:

TWetterstation = class(TObject)
private
  FComport : TComport;
  FComterminal :TComTerminal;
public
  constructor Create(comport:TComPort; comterminal : TComTerminal);
  procedure Reset;
  procedure ReadWetterdaten;
  property Temperatur:double;
  property Feuchtigkeit:double;
  property Luftdruck:double;
end;

constructor TWetterstation.Create(comport:TComPort; comterminal : TComTerminal);
begin
  inherited;
  FComport := comport;
  FComTerminal := comterminal;
end;

procedure TWettersation.ReadWetterdaten();
begin
     FComTerminal.onStrReceive();
end;

Das sollte so gehen? Ich habe im Moment kein Delphi auf dem Rechner hier drauf.

[shmia]

Zitat:

Zitat von Coffeecoder (Beitrag 1140269)

Allerdings kommt mir da eine Frage auf: Vom TComTerminal brauch ich lediglich nur eine Methode onStrReceive, weil die TComPort Klasse nur die nötigen Parameter für die Kommunikation nötig sind.
Folglich muss ich in deinem Beispiel TWettersation doch noch die TComTerminal haben.

Ich habe mich schon am Anfang gewundert, weshalb du TComTerminal noch ins Spiel bringst.
Mit TComTerminal emuliert man VT100, VT52 oder Ansi-Terminals die noch aus dem dunklen Mittelalter der Computertechnik stammen.
Da du kein Terminal hast (hoff' ich doch), brauchst du diese Klasse nicht.

[Coffeecoder]

Zitat:

Zitat von shmia (Beitrag 1140283)

Da du kein Terminal hast (hoff' ich doch), brauchst du diese Klasse nicht.

Nein das nicht :)
Ich werde mal deinen Vorschlag versuchen und Bescheid geben. Danke für deine Hilfe :thumb:

[DeddyH]

Wäre es aber in dem Fall nicht sinnvoller, gleich von TComPort abzuleiten und die paar zusätzlichen Methoden/Properties zu deklarieren? Ansonsten müsste man ja bei jedem Zugriff auf den ComPort mit Assigned() prüfen, ob er überhaupt zugewiesen wurde und kann selbst dann nicht sicher sein, dass es ihn auch wirklich noch gibt, er kann ja zugewiesen, aber trotzdem zwischendurch freigegeben, aber nicht genilt worden sein.

[Coffeecoder]

Zitat:

Zitat von DeddyH (Beitrag 1140285)

Wäre es aber in dem Fall nicht sinnvoller, gleich von TComPort abzuleiten und die paar zusätzlichen Methoden/Properties zu deklarieren?

Genau das ist mir auch gerade in den Sinn gekommen :)
Ich habe mir mal die Dokumentation für die TComport von Dejan Crnila runtergeladen und tatsächlich steht doch eine Methode zum Empfangen in der Klasse drin.

Als Resultat habe ich dann dies:

Delphi-Quellcode:

TWetterstation = class(TComport)
public
  constructor Create();
  procedure ReadWetterdaten;
  procedure SendWetterdaten(b: byte);
end;

... // ich kürze mal ab

Wir sind schon einige Schritte weiter als am Anfang. Danke für eure Hilfe :thumb:

[shmia]

Zitat:

Zitat von DeddyH (Beitrag 1140285)

Wäre es aber in dem Fall nicht sinnvoller, gleich von TComPort abzuleiten ...

Vererben oder Benutzen wäre hier also die Frage.
Ich sehe öfters mal, dass vererbt wird obwohl gar keine so enge Verwandschaft besteht.

Beispiel:
Es gibt die Klasse TField (Basisklasse) und TStringField (abgeleitete Klasse).
Hier kann man ganz klar sagen ein TStringField ist eine spezielle Variante von TField.

Bei der Wetterstation trifft dies nicht zu.
Die Wetterstation ist keine spezielle Variante von TComPort sondern
die Wetterstation benötigt ein TComPort-Objekt zur Kommunikation mit dem realen Messwertgeber.

[DeddyH]

Was mich an Deinem Vorschlag stört ist die Tatsache, dass eine Property der Klasse von außerhalb verwaltet wird. Das kann im dümmsten Fall in AVs enden (OK, nicht sehr wahrscheinlich, aber wer weiß schon immer vorher, was der Endbenutzer mit so einer Klasse anstellt, und wenn man es selbst ist?).

[Coffeecoder]

Zitat:

Zitat von shmia (Beitrag 1140344)

Ich sehe öfters mal, dass vererbt wird obwohl gar keine so enge Verwandschaft besteht.

Beispiel:

Bei der Wetterstation trifft dies nicht zu.
Die Wetterstation ist keine spezielle Variante von TComPort sondern
die Wetterstation benötigt ein TComPort-Objekt zur Kommunikation mit dem realen Messwertgeber.

Gutes Beispiel. Ich brauch die TComPort Klasse nur zur Kommunikation mit dem Messgerät/Wetterstation. Da reicht es natürlich aus, wenn ich das TComPort als Attribut deklariere und benutze. Zusätzlich brauche ich noch eine Liste um einige Korrekturen vorzunehmen bzw zu formatieren um die als Datei abzuspeichern.

Aber mal angenommen, ich hätte mehrere Wetterstationen mit unterschiedlichen Protokollen wäre es nicht sinnvoll doch zu erben? Ihr fragt euch nun was soll das mit den Protokollen nunja jede write-Methode braucht andere Zeichnen / Kommandos um mit dem entsprechenden Gerät zu kommunizieren.

[Sir Rufo]

Die Klasse sollte selber eine ComPort Instanz besitzen.

Wird von aussen eine ComPort Instanz übergeben, dann sollten von der nur die Einstellungen übernommen werden (Assign).

Das mit dem Vererben und den unterschiedlichen Protokollen kann man durch eine BasisKlasse und einer abstrakten Methode lösen.
In der konkreten Klasse wird diese Methode dann entsprechend dem Protokoll deklariert.

[Coffeecoder]

Als Zusammenfassung kann man behaupten, dass in diesem konkreten Beispiel eigentlich egal ist ob man erbt oder die Klasse ComPort als Attribut deklariert.

Doch muss ich sagen, dass meine Frage trotzdem beantwortet ist und dass ihr mit gut geholfen habt. Dafür danke ich allen :) :thumb:

Ich werde einfach mal in diesem Fall einmal mit Vererbung und einmal als Attribut die Klasse benutzen und sehen was "am besten" ist.

Danke euch :)