Forum: PC-Programmierung Programmstruktur zur Verarbeitung verschiedener Netzwerknachrichten


von Klaus (Gast)


Lesenswert?

Hallo!


Ich überlege gerade die grundsätzliche Programmstruktur (Klassenstruktur 
etc. ) für mein Programm.

Ws geht darum, dass ich verschiedene Netzwerknachrichten (als Bytestrom 
) bekomme und diese gerne komfortabel in meinem Programm 
weiterverarbeiten möchte. Ich suche dafür eine elegante C++ Lösung.

In C würde ich ein Datentyp definieren der als Union für jeden 
Nachrichtentyp ein Struct enhält. So dass ich bequem auf die Nutzdaten 
jedes Nachrichtentyps zugreifen kann.

Wie würde man das elegant in C++ lösen? Oder würde man das genau so 
machen?

von tobi (Gast)


Lesenswert?

Zur Not auch mit Unions.

von Klaus (Gast)


Lesenswert?

Ja zur Not. Aber normalerweise hält C++ ja für fast alle C-Konzepte eine 
alternative mit gewissen Vorteilen bereit ;)

Und da ich in C++ Programmiere würde ich ungerne in C-Syle zurück 
fallen, wenn es eine elegantere alternative gibt.

von Ahem (Gast)


Lesenswert?

Wenn man das mal von einer etwas abstrakteren Ebene aus betrachtet, so 
sind structs die Beschreibung von Datenstrukturen im Speicher und unions 
das Mittel um mehrere solcher Beschreibungen sozusagen simultan auf 
einen einzigen Speicherbereich zu legen.

In C++ gibt es genauso structs und unions wie in C. Hingegen gibt es 
kein anderes Sprachmittel, das genau dieses leistet und es wäre auch 
redundant ein weiteres vorzuhalten (wenn es nicht weitere Möglichkeiten 
bieten würde).

Würde sich jedoch aus irgendwelchen Gründen der Zwang ergeben auf 
structs und unions zu verzichten, bliebe noch, nach genauem Studium des 
Layouts von instanziierten Individuen einer Klasse, der Weg, mehrere 
Klassen mit unterschiedlichen Mitgliedsvariablen zu erzeugen und Zeiger 
auf diese zu verwenden, die alle auf den selben Speicherbereich zeigen.
Weiter, bliebe der, mehr traditionelle, Weg, den Datenstrom beim Eingang 
zu parsen und die Felder entsprechend zu verarbeiten.

Es bliebe zu berücksichtigen, das sich die Mitglieder von structs mit 
einem pragma packen liessen, was nicht eigentlich C sondern eine 
spezielle Compilereigenschaft wäre (und bei den mir bekannten 
tatsächlich ist). Ob es eine analoge Compileranweisung für Mitglieder 
von C++-Klassen gibt ist mir nicht bekannt.

Im allgemeinen ist die einzige "natürliche" Oberklasse des Inhalts eines 
ansonsten sehr heterogenen Datenstrom eben der Datenstrom. Aber sogar 
eine sehr grosse Ähnlichkeit der Datensätze würde zwar die Bildung von 
mehreren miteinander verwandten Klassen nahelegen; dennoch für eine 
Implementierung nicht zwangsweise bedeuten, das hier Speicherbereiche 
beschrieben werden.
Wahrscheinlich würde man vielmehr (abgesehen von identischen linken 
Seiten) unterschiedliche Parser für den verbleibenden Datenstrom 
implementieren.
Eine andere Alternative wäre die Definition von Containern die viele 
kleine Klassen für jeweils ein Element des Datenstroms enthalten, die 
jeweils ihren eigenen Teilabschnitt des Datenstroms parsen.

Mein Fazit ist, das es keine "elegantere" Möglichkeit gibt wenn die 
Grundidee beibehalten werden soll. Wobei zu fragen bliebe, was den 
"Eleganz" in Deinen Augen ist. (Womit ich meine, das es eine objektive 
Beschreibung dieses Kriteriums geben muss, damit man ein entsprechendes 
Konstrukt wählen kann).

Der Vorteil von struct/unions ist, das man nur jeweils einmal die 
Struktur beschreibt und bei Änderungen der Reihenfolge etc. nur die 
Struktur ändert, jedoch an der Verarbeitung nichts ändern muss. Werden 
aber Parser implementiert muss man, da der Ablauf die Grammatik 
beschreibt, sehr aufpassen und bei Änderungen noch viel mehr.

von Klaus W. (mfgkw)


Lesenswert?

Das hängt natürlich auch irgendwie davon ab, wie man die
verschiedenen Nachrichten unterscheiden kann.

Wenn es noch nicht anderweitig festgelegt ist und man noch Einfluß
darauf hat, kann man das ja nutzen.

Ich würde vermutlich eine Nachricht so aufbauen, daß am Anfang zur
Sicherheit eine bestimmte Kennung kommt (um absoluten Unfug
blocken zu können), dann bei Bedarf eine Längenangabe für den Rest
der Nachricht (dadurch kann der Empfänger ggf.  seinen
Empfangspuffer anpassen und den Rest in einem Rutsch lesen).

Anschließend soll dann eine Kennung kommen, die den Typ der
Nachricht exakt definiert.

Für jede Art von Nachricht baut man sich eine entsprechende
Klasse, die sinnvollerweise von einer passenden Basisklasse
abgeleitet (z.B. ABC_Message) ist. Wahrscheinlich wird man von
dieser Basisklasse nie ein Objekt schaffen, also virtuell machen
(ABC = abstract base class).

Eine Methode dieser Klasse (factory method, virtueller
Konstruktor, z.B. create()) wird von den Ableitungen
jeweils überschrieben, um ein Objekt des richtigen Typs zu
erzeugen.

Eine weitere statische Methode der Basisklasse dient dazu, anhand
einer eindeutigen ID jeder abgeleiteten Klasse (Klasse, nicht
Objekt!) ein zugehöriges Muster der abgeleiteten Klasse speichern
zu können. Ich nenne sie mal register_prototyp(), weil sie einen
Prototypen registriert.

Für jede abgeleitete Klasse muß ein solches Muster (ein
Prototyp) bei der Basisklasse angemeldet werden.
Das kann durch ein statisches Element bei Programmstart passieren;
dann muß man aber aufpassen, dass die Reihenfolge aller statischen
Elemente stimmt.
Es ist auch denkbar, alles was zu einer solchen abgeleiteten
Klasse gehört, in eine DLL auszulagern (die in ihrer
Initialisierungsfunktion dann das Anmelden übernimmt). Dann kann
ein bereits kompiliertes (!) Programm beim Kunden ohne neues
Übersetzen und Linken um neue Nachrichtentypen erweitert werden,
indem man passende DLLs ergänzt (falls die über Namen, z.B. aus
Konfigurationsdateien geladen werden können).

Ab dann kann eine weitere statische Methode der Basisklasse anhand
einer Klassen-ID über das zugehörige Musterobjekt die
create()-Methode der richtigen Klasse aufrufen, die dann den
Bytestrom bekommt und daraus ein ordentliches Objekt baut.

Ich habe das mal zu einem möglichst kleinen vollständigen Beispiel
zusammengeschraubt...
Es geht dabei um die abstrakte Basisklasse ABC_Message und zwei
davon abgeleitete Nachrichtentypen (die sich nicht so richtig
unterscheiden, aber egal): MessageTyp1 und MessageTyp2.

Erst das Testprogramm, das ist noch am übersichtlichsten:
1
// Time-stamp: "03.06.09 12:33 testmessage.cpp klaus<bei>wachtler.de"
2
//
3
// kleines Testprogramm zur Nachrichtenerzeugung
4
//
5
// Linux/gcc:
6
// g++ -Wall -I. testmessage.cpp ABC_Message.cpp -o testmessage && ./testmessage
7
8
#include <iostream>
9
10
11
#include <ABC_Message.h>
12
#include <MessageTyp1.h>
13
#include <MessageTyp2.h>
14
15
16
17
#ifndef __PRETTY_FUNCTION__
18
#define __PRETTY_FUNCTION__  __FUNCTION__
19
#endif /* ifndef __PRETTY_FUNCTION__ */
20
21
22
23
int main( int nargs, char **args )
24
{
25
26
  try
27
  {
28
    // Klassen amelden:
29
    ABC_Message::register_prototyp( "Typ1", new MessageTyp1 );
30
    ABC_Message::register_prototyp( "Typ2", new MessageTyp2 );
31
32
    // Objekte anhand eines Strings erzeugen:
33
    ABC_Message *pErsteNachricht
34
      = ABC_Message::createMessageObject( "Typ1\nHallo, ich bin der erste" );
35
    ABC_Message *pZweiteNachricht
36
      = ABC_Message::createMessageObject( "Typ2\nHallo, ich bin der zweite" );
37
38
    // Verwenden:
39
    if( pErsteNachricht )
40
    {
41
      pErsteNachricht->zeigdich();
42
    }
43
    if( pZweiteNachricht )
44
    {
45
      pZweiteNachricht->zeigdich();
46
    }
47
  }
48
  catch( std::exception &Fehler )
49
  {
50
    std::cerr << "Fehler: <"
51
              << Fehler.what()
52
              << "> in "
53
              << __PRETTY_FUNCTION__
54
              << "\n";
55
  }
56
  catch( ... )
57
  {
58
    std::cerr << "unbekannter Fehler in "
59
              << __PRETTY_FUNCTION__
60
              << "\n";
61
  }
62
}

Zuerst werden mit einer statischen Methode
ABC_Message::register_prototyp() zwei Klassen "angemeldet",
nämlich MessageTyp1 und MessageTyp2 mit je einem Namen. Dieser
Name ist der, der dann auch später im Datenstrom als Kennung
auftauchen soll, anhand dessen die Objekte erzeugt werden sollen.

Dann werden zwei solche Objekte erzeugt, indem ein passender
String an ABC_Message::createMessageObject() übergeben wird.  Ich
habe das jetzt so festgelegt, daß in dem String erst die Id kommen
muss, dann ein Zeilenvorschub und dann die restlichen Daten.  Mit
diesen restlichen Daten hat ABC_Message nichts zu tun, sondern
nimmt anhand der Id den Prototypen vom passenden Typ, der beim
Anmelden übergeben wurde, und ruft darüber den zugehörigen
virtuellen Konstruktor der passenden Klasse auf, dem werden dann
die Daten nach dem LF übergeben und er muß dann irgendwie daraus
das Objekt bauen.
Macht natürlich nur Sinn, wenn er dann wiederum mit den
Initialisierungsdaten nach dem LF etwas sinnvolles anfangen kann.
Daraus bekommt man je einen Zeiger auf ein neues Objekt, und kann
es irgendwie verwenden.
Als Beispiel habe ich einfach eine Methode zeigdich() eingebaut;
im echten Leben würde da vermutlich mehr kommen.

Die Basisklasse ABC_Message enthält eine statische Map, in der die
Zuordnung zwischen den IDs und den Prototypen abgelegt ist, sowie
die Methoden zum Registrieren der Klassen und Erzeugen der
Nachrichtenobjekte:
1
// Time-stamp: "03.06.09 12:30 ABC_Message.h klaus<bei>wachtler.de"
2
//
3
// virtuelle Basisklasse, von der die Nachrichtentypen abgeleitet sind
4
5
#ifndef __ABC_Message_h__
6
#define __ABC_Message_h__
7
8
#include <deriveexception.h>
9
#include <cstring>
10
#include <stdexcept>
11
#include <map>
12
13
14
DERIVEEXCEPTION( ErrMessage, std::runtime_error, "Fehler mit Messageerzeugung" );
15
DERIVEEXCEPTION( ErrMessageParseError, ErrMessage, "falsche Initialisierungsdaten" );
16
DERIVEEXCEPTION( ErrMessageUnknownID, ErrMessage, "unbekannte ID" );
17
18
class ABC_Message
19
{
20
public:
21
22
  // Konstruktor
23
  ABC_Message()
24
  {
25
  }
26
27
  // Destruktor
28
  virtual ~ABC_Message()
29
  {
30
  }
31
32
  // und alle Methoden, die von der Nachricht so verlangt werden und
33
  // folglich implementiert werden müssen...
34
  virtual void zeigdich() = 0;
35
36
37
  // szData muss die Daten zum Erzeugen des Objekts enthalten, und
38
  // zwar zuerst eine gültige ID, gefolgt von einem \n, dann die
39
  // restlichen Daten, aus denen das jeweilige create ein Objekt bauen
40
  // kann.
41
  static ABC_Message *createMessageObject( const char *szData )
42
    throw( ErrMessageUnknownID )
43
  {
44
    // ID extrahieren und Prototyp suchen:
45
    const char *pLF;
46
47
    if( ( pLF = std::strchr( szData, '\n' ) )
48
        &&
49
        pLF>szData
50
        )
51
    {
52
      std::string sId = std::string( szData, pLF-szData );
53
      std::map< std::string, const ABC_Message* >::const_iterator  itIdPrototyp;
54
      if( ( itIdPrototyp = map_Id_Prototyp.find( sId ) ) != map_Id_Prototyp.end() )
55
      {
56
        // ID gefunden, also darüber ein Objekt mit den übergebenen
57
        // Daten erzeugen:
58
        return itIdPrototyp->second->create( pLF+1 );
59
      }
60
      else
61
      {
62
        throw ErrMessageUnknownID( std::string( "<" ) + sId + ">" );
63
      }
64
    }
65
    else
66
    {
67
      // szData ungültig
68
      throw ErrMessageParseError( std::string( "<" ) + szData + ">" );
69
    }
70
  }
71
72
  static void register_prototyp( const std::string &id, const ABC_Message *pProtoyp )
73
  {
74
    map_Id_Prototyp.insert( std::make_pair( id, pProtoyp ) );
75
  }
76
77
protected:
78
79
  // erzeugt ein neues Objekt anhand eines C-Strings; im Fehlerfall
80
  // wird NULL geliefert:
81
  virtual ABC_Message *create( const char *szContent ) const throw() = 0;
82
83
84
private:
85
86
  // bildet Klassen-IDs auf Prototypen der Klasse ab
87
  static std::map< std::string, const ABC_Message* >    map_Id_Prototyp;
88
89
90
}; // class ABC_Message...
91
92
93
#endif /* ifndef __ABC_Message_h__ */
94
95
// Local Variables:
96
// mode:C++
97
// End:

Die beim Anmelden erzeugten Prototypen werden in dieser Form
übrigens erst bei Programmende gelöscht. Dazu muss der Destruktor
virtuell sein, weil in der Map ja eigentlich nur ABC_Message*
abgelegt sind, in Wirklichkeit aber davon abgeleitete Objekte
zerstört werden müssen!

Weiterhin funktioniert das so nur, wenn es keine Kollisionen durch
Threads gibt.
Falls das zu befürchten ist, muß man natürlich die Zugriffe auf
die Map mit Semaphoren irgendwie abdichten.

Die eigentlichen Nachrichten können natürlich auch indirekt von
ABC_Message abgeleitet sein, so daß ganze Hierarchien gebaut werden
können.

Weil die Klasse noch ein static Element enthält (die Map), muß
diese in einer CPP-Datei definiert werden:
1
// Time-stamp: "03.06.09 12:03 ABC_Message.cpp klaus<bei>wachtler.de"
2
//
3
// statische Elemente für ABC_Message
4
5
#include <ABC_Message.h>
6
7
std::map< std::string, const ABC_Message* >   ABC_Message::map_Id_Prototyp;



Hier die beiden abgeleiteten NAchritentypen:
1
// Time-stamp: "03.06.09 12:22 MessageTyp1.h klaus<bei>wachtler.de"
2
//
3
// Nachricht Typ 1
4
5
#ifndef __Message_Typ1_h__
6
#define __Message_Typ1_h__
7
8
#include <ABC_Message.h>
9
#include <string>
10
#include <iostream>
11
12
13
class MessageTyp1 : public ABC_Message
14
{
15
 public:
16
17
  MessageTyp1()
18
    : sWerbinich( "" )
19
  {
20
  }
21
22
  MessageTyp1( const char *szContent )
23
    : sWerbinich( std::string( szContent ) )
24
  {
25
  }
26
27
  virtual ~MessageTyp1()
28
  {
29
  }
30
31
 protected:
32
33
  // erzeugt Objekt mit Daten:
34
  virtual ABC_Message *create( const char *szContent ) const throw()
35
  {
36
    // TODO: Daten korrekt verwenden (parsen etc.), um Objekt sinnvoll
37
    // zu bauen!
38
    return new MessageTyp1( szContent );
39
  }
40
41
  void zeigdich()
42
  {
43
    std::cout << "ich bin ein MessageTyp1: " << sWerbinich << std::endl;
44
  }
45
46
 private:
47
48
  std::string  sWerbinich;
49
50
}; // class MessageTyp1
51
52
#endif /* ifndef __Message_Typ1_h__ */
53
54
// Local Variables:
55
// mode:C++
56
// End:

1
// Time-stamp: "03.06.09 12:30 MessageTyp2.h klaus<bei>wachtler.de"
2
//
3
// Nachricht Typ 2
4
5
#ifndef __Message_Typ2_h__
6
#define __Message_Typ2_h__
7
8
#include <ABC_Message.h>
9
#include <string>
10
#include <iostream>
11
12
13
class MessageTyp2 : public ABC_Message
14
{
15
 public:
16
17
  MessageTyp2()
18
    : sWerbinich( "" )
19
  {
20
  }
21
22
  MessageTyp2( const char *szContent )
23
    : sWerbinich( std::string( szContent ) )
24
  {
25
  }
26
27
  virtual ~MessageTyp2()
28
  {
29
  }
30
31
 protected:
32
33
  // erzeugt Objekt mit Daten:
34
  virtual ABC_Message *create( const char *szContent ) const throw()
35
  {
36
    // TODO: Daten korrekt verwenden (parsen etc.), um Objekt sinnvoll
37
    // zu bauen!
38
    return new MessageTyp2( szContent );
39
  }
40
41
  void zeigdich()
42
  {
43
    std::cout << "ich bin ein MessageTyp2: " << sWerbinich << std::endl;
44
  }
45
46
 private:
47
48
  std::string  sWerbinich;
49
50
}; // class MessageTyp2
51
52
#endif /* ifndef __Message_Typ2_h__ */
53
54
// Local Variables:
55
// mode:C++
56
// End:


Nur aus Faulheit habe ich eine zusätzliche Headerdatei verwendet,
die eigentlich hier nicht hingehört, aber zum Übersetzen der
obigen Beispiele nötig ist:
1
//////////////////////////////////////////////////////////////////////////
2
//
3
// Time-stamp: "03.06.09 12:22 deriveexception.h klaus<bei>wachtler.de"
4
//
5
//////////////////////////////////////////////////////////////////////////
6
//
7
// Mit dem Makro DERIVEEXCEPTION kann man eine exception von einer
8
// anderen (std::runtime_error, std::logic_error und alle davon
9
// abgeleiteten) ableiten und einen erklärenden Text hinzufügen.
10
// Durch mehrfache Verwendung von DERIVEEXCEPTION lassen sich ganze
11
// Hierarchien aufbauen.
12
//
13
// Ein Aufruf von DERIVEEXCEPTION erzeugt also eine neue class.
14
//
15
// Beispiel:
16
// DERIVEEXCEPTION( Feld_err, runtime_error, "Feldgrenzenüberschreitung" );
17
// DERIVEEXCEPTION( FeldOben_err, Feld_err, "(oben)" );
18
// DERIVEEXCEPTION( FeldUnten_err, Feld_err, "(unten)" );
19
// baut diese Klassenhierarchie unterhalb von runtime_error:
20
// runtime_error
21
//   |
22
//   +--Feld_err
23
//       |
24
//       +--FeldOben_err
25
//       |
26
//       +--FeldUnten_err
27
//
28
// Der in einer so gebildeten Ausnahme enthaltene Text (what())
29
// besteht aus allen Texten der Ableitungskette, jweils mit \n
30
// getrennt.
31
// FeldUnten_err::what() würde also
32
// "Feldgrenzenüberschreitung\n(unten)" liefern.
33
// Beim Erzeugen einer Ausnahme kann im ctor ein weiterer Text
34
// angegeben werden, der ebenfalls angehängt wird.
35
// Mit
36
//  throw FeldUnten_err( "schade!" );
37
// wirft man eine Ausnahme, die mit what den Text
38
// "Feldgrenzenüberschreitung\n(unten)\nschade!" liefert.
39
//
40
// DERIVEEXCEPTION kann auch innerhalb einer class verwendet werden,
41
// und erzeugt dementsprechend eine Unterklasse in der umgebenden.
42
// class MeinTollerContainer
43
// {
44
//    DERIVEEXCEPTION( Unsinn_err, runtime_error, "Unsinn in ..." );
45
// };
46
// Die erzeugte Klasse für Ausnahmen ist dann
47
// MeinTollerContainer::Unsinn_err.
48
//
49
//////////////////////////////////////////////////////////////////////////
50
//
51
// Geschichte:
52
//////////////
53
//
54
// 19.11.2004 kw          für YABA übernommen und kommentiert
55
//
56
//
57
// 24.01.2005 kw          Umbau auf anyware::string anstatt
58
//                        std::string
59
//
60
// 03.06.2009 kw          gekuerzt
61
//
62
// 
63
//
64
// 
65
//
66
// 
67
//
68
//////////////////////////////////////////////////////////////////////////
69
//
70
// Benoetigt:
71
/////////////
72
//
73
// -
74
//
75
//////////////////////////////////////////////////////////////////////////
76
//
77
// Umgebung:
78
////////////
79
//
80
// ANSI-C++
81
//
82
//////////////////////////////////////////////////////////////////////////
83
84
85
#ifndef _DERIVEEXCEPTION_H_
86
#define _DERIVEEXCEPTION_H_
87
88
#include <string>
89
typedef std::string   string;
90
91
#include <stdexcept>
92
93
#ifndef DERIVEEXCEPTION
94
#define DERIVEEXCEPTION( NAME, BASENAME, TEXT )                         \
95
  class NAME : public BASENAME                                          \
96
    {                                                                   \
97
    public:                                                             \
98
      NAME( const string &_what = string( #NAME ) )                     \
99
        : BASENAME( string( TEXT ) + string( "\n" ) + _what )           \
100
        {}                                                              \
101
      explicit NAME( const char *_what )                                \
102
        : BASENAME( string( TEXT ) + string( "\n" ) + _what )           \
103
        {}                                                              \
104
    }
105
106
107
108
#endif /* DERIVEEXCEPTION */
109
110
#endif /* _DERIVEEXCEPTION_H_ */
111
112
// Local Variables:
113
// mode:C++
114
// End:

Übersetzt wird das Ganze unter Linux (g++ 4.3.2) mit:
1
g++ -Wall -I. testmessage.cpp ABC_Message.cpp -o testmessage && ./testmessage

Programmausgabe:
1
ich bin ein MessageTyp1: Hallo, ich bin der erste
2
ich bin ein MessageTyp2: Hallo, ich bin der zweite


Mit dem MS-Compiler habe ich es nicht getestet. Im Prinzip sollte
es gehen, aber ich glaube, der kommt mit den throw-Deklarationen
nicht klar. Im Zweifelsfall einfach weglassen.

Sowohl Sender als auch Empfänger im Netzwerk können intern bei
Bedarf mit denselben Nachrichtentypen arbeiten, müssen es aber
nicht.

von Klaus W. (mfgkw)


Lesenswert?

Noch als Anmerkung zur ursprünglichen Frage:

Das Ersatzkonzept für die union ist in C++ hier die Ableitung von
einer Basisklasse unter Einsatz virtueller Methoden.

Das funktioniert so, daß man einen Zeiger haben kann, der formal
auf ein Objekt der Basisklasse zeigt, aber auch auf ein Objekt
einer beliebigen davon abgeleiteten Klasse zeigen darf.
Ruft man über einen solchen Zeiger eine Methode auf, dann gibt
es zwei Möglichkeiten:
- die Methode ist nicht als virtual deklariert, dann wird für
  das abgeleitete Objekt leider die Methode der Basisklasse aufgerufen
- die Methode ist virtual, dann wird auch tatsächlich die Methode
  aus der abgeleiteten Klasse verwendet, die zu dem Objekt gehört.
Mit virtual braucht der Aufrufer also gar nicht die abgeleitete
Klasse kennen, kann aber trotzdem über einen Zeiger eine Methode
daraus aufrufen.
Indem man also Zeiger auf verschiedene Datentypen hat, wird erst
zur Laufzeit die Methode ausgesucht, die wirklich zu dem
betreffenden Objekt gehört.
Das ist deutlich eleganter als eine union.

(Mit Referenzen statt Zeigern analog...)

von Klaus (Gast)


Lesenswert?

auf die Knie fall

wow, danke dir!  Das bringt mich doch steil vorran :)

Das muss ich nun erstmal im Detail durcharbeiten ;)

von Klaus W. (mfgkw)


Lesenswert?

Klaus Wachtler schrieb:
> ...
> Für jede Art von Nachricht baut man sich eine entsprechende
> Klasse, die sinnvollerweise von einer passenden Basisklasse
> abgeleitet (z.B. ABC_Message) ist. Wahrscheinlich wird man von
> dieser Basisklasse nie ein Objekt schaffen, also virtuell machen
> (ABC = abstract base class).
> ...

Sorry, das soll nicht heißen "virtuell machen" sondern "abstrakt 
machen".

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.