C++ Kommunikationsklassen Umsetzung?

[Werner (Gast)]

Hallo zusammen,

ich möchte mir zur Kommunikation über eine serielle Schnittstelle ein 
Kommunikationsobjekt bauen:

class ComBase {
protected:
  void send(void *data);
  void receive(void *data);
};

class ComMaster: public ComBase  {
  void sendRequest(void) {
    //Requestframe bauen
    //...
    send(&frame);
  }
};

class ComSlave: public ComBase {
  void sendReply(void) {
    //Replyframe bauen
    //...
    send(&frame);
  }
};

//Auf Masterseite
ComMaster com;
//Auf Slaveseite
ComSlave com;

Soweit so gut, nun möchte ich aber optional an die Schnittstelle ein 
Funkmodul anschließen und dazu eine ComRadio Klasse schreiben, die die 
Methoden send und receive überschreibt, und darin die Daten für das 
Funkmodul einpacket.

class ComRadio: public ComBase {
  void send(void *data); //überschreibt ComBase
  void receive(void *data); //überschreibt ComBase
};

Wie kann ich nun einen RadioSlave bzw. einen RadioMaster instanziieren?
Ich müsste fallweise die Klasse ComRadio zwischen ComBase und ComSlave 
bzw. ComMaster schieben. Wie könnte man das umsetzen?

Werner

[René H. (Gast)]

Werner schrieb:
> Ich müsste fallweise die Klasse ComRadio zwischen ComBase und ComSlave
> bzw. ComMaster schieben. Wie könnte man das umsetzen?

Ich habe das Problem vermutlich nicht verstanden. Was spricht gegen 
einer Subklasse von ComMaster resp. ComSlave?

Grüsse,
René

[Rolf M. (rmagnus)]

Meines Erachtens ist die Klassenhierarchie nicht die richtige.
ComMaster und ComSlave sollten nicht von ComBase ableiten. Es sind zwei 
verschiedene Dinge. ComBase (bzw. davon abgeleitete Klassen) 
repräsentiert die Schnittstelle, während ComMaster und ComSlave ein 
darüberliegendes Protokoll abbilden.

[Wilhelm M. (wimalopaan)]

Werner schrieb:
> Hallo zusammen,
>
> ich möchte mir zur Kommunikation über eine serielle Schnittstelle ein
> Kommunikationsobjekt bauen:
>
>

> class ComBase {
> protected:
>   void send(void *data);
>   void receive(void *data);
> };
>

>

Ich denke auch, das ComMAster bzw. ComSlave jeweils die entsprechende 
Seite eines Protokolls realisieren. Die sollten dann jeweils ein 
Exemplar von ComBase bzw. eines davon abgeleiteten Typs verwenden.

Falls ComBase eine Schnittstelle sein sollte oder generell als 
Basisklasse dienen soll, so müssen die Elementfunktionen, die 
überschrieben werden sollen, als virtual deklariert und bei einem 
Interface als rein-virtuell (=0) und public, und der dtor muss virtual 
sein.

Zusätzlich würde ich bei send einen Input-Buffer (alos const data*) 
verwenden bzw. gänzlich auf rohe Arrays zugunsten von std::vector / 
std::array verzichten (sofern verfügbar, ggf. eigene Realisierungen wie 
etwa ein FixedVector (ohne Heap-Alloc).


Vielleicht kann der TO mehr Infos liefern?

[Thomas W. (diddl)]

Entweder als virtuelle Funktionen, - oder als Template.


Wenn du für das Template Konzept ein gut durchdachtes Design verwendest, 
dann kannst du das Funmodul auf unterschiedliche Arten verbinden, zb. 
auch über I2C oder SPI.


Bei schmaler Hardware, wie zb. Atmegas würde ich das Template Konzept 
bevorzugen. Bei den großen ist es vermutlich einfacher mit virtuellen 
Funktionen

[dulnik (Gast)]

Rolf M. schrieb:
> Meines Erachtens ist die Klassenhierarchie nicht die richtige.
> ComMaster und ComSlave sollten nicht von ComBase ableiten. Es sind zwei
> verschiedene Dinge. ComBase (bzw. davon abgeleitete Klassen)
> repräsentiert die Schnittstelle, während ComMaster und ComSlave ein
> darüberliegendes Protokoll abbilden.

Genau so ist es. Das gleiche gilt für ComRadio.

ComRadio ist ein Protokoll und BENUTZT die serielle Schnittstelle. Oder 
besser gesagt kann die serielle Schnittstelle benutzen neben vielen 
anderen IST aber keine.

[dulnik (Gast)]

dulnik schrieb:
> Rolf M. schrieb:
>> Meines Erachtens ist die Klassenhierarchie nicht die richtige.
>> ComMaster und ComSlave sollten nicht von ComBase ableiten. Es sind zwei
>> verschiedene Dinge. ComBase (bzw. davon abgeleitete Klassen)
>> repräsentiert die Schnittstelle, während ComMaster und ComSlave ein
>> darüberliegendes Protokoll abbilden.
>
> Genau so ist es. Das gleiche gilt für ComRadio.
>
> ComRadio ist ein Protokoll und BENUTZT die serielle Schnittstelle. Oder
> besser gesagt kann die serielle Schnittstelle benutzen neben vielen
> anderen IST aber keine.

Gabe den Punt vor "IST" vesgessen... :-)

[Nop (Gast)]

Einer der Vorteile von OOP ist halt, daß man sich den Kopf über 
Scheinprobleme wie is-a vs. has-a zerbrechen kann, wenn einem die 
eigentliche Problemstellung zu langweilig ist. ;-)

[Werner (Gast)]

>ComRadio ist ein Protokoll

wobei aber ComRadio auf das "ursprüngliche" Protokoll aus ComSlave und 
ComMaster aufsetzen soll, aber um solche Frames zu übertragen muss bei 
den Funkmodulen eben noch eine Schicht außen rum :-(

Vielleicht dann vielleicht so:

ComBase
|
+-ComMaster //Protokoll
|
+-ComSlave //Protokoll

ComHal
|
+-ComRS232
|
+-ComRadio

Das ComBase HAT dann einen Nachkommen von ComHal. Aber wenn ComHal etwas 
empfängt, wie bekommt das der ComMaster oder -Slave mit?

Werner