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

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

[shmia]

Zitat von Coffeecoder:

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 von shmia:

Zitat von Coffeecoder:

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 von Coffeecoder:

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.