C++ Kommunikationsklassen Umsetzung?

Gast #4861512
Hallo zusammen,

ich möchte mir zur Kommunikation über eine serielle Schnittstelle ein 
Kommunikationsobjekt bauen:
1
class ComBase {
2
protected:
3
  void send(void *data);
4
  void receive(void *data);
5
};
6

7
class ComMaster: public ComBase  {
8
  void sendRequest(void) {
9
    //Requestframe bauen
10
    //...
11
    send(&frame);
12
  }
13
};
14

15
class ComSlave: public ComBase {
16
  void sendReply(void) {
17
    //Replyframe bauen
18
    //...
19
    send(&frame);
20
  }
21
};
22

23
//Auf Masterseite
24
ComMaster com;
25
//Auf Slaveseite
26
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.
1
class ComRadio: public ComBase {
2
  void send(void *data); //überschreibt ComBase
3
  void receive(void *data); //überschreibt ComBase
4
};

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
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é
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.
Werner schrieb:
> Hallo zusammen,
>
> ich möchte mir zur Kommunikation über eine serielle Schnittstelle ein
> Kommunikationsobjekt bauen:
>
>
1
> class ComBase {
2
> protected:
3
>   void send(void *data);
4
>   void receive(void *data);
5
> };
6
>
>

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?
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
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.
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... :-)
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. ;-)
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

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 9 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.