Qual è uno schema appropriato per gestire una coda di eventi di rete in C ++?

Question

Qual è uno schema appropriato per gestire una coda di eventi di rete in C ++?

#1 da (3 voti)

2

Sto scrivendo un'applicazione che invia e riceve messaggi attraverso la rete e li spinge in una coda std::deque . e sto cercando il modello di programmazione appropriato per gestire tutti i diversi tipi possibili di messaggi che potrebbe ricevere.

Ogni tipo di messaggio avrà un insieme di dati completamente diverso. Ad esempio:

Connessione riuscita
scollegamento
Un altro peer connesso
- Nome peer
- Indirizzo peer
- Altro stato peer
Stato dell'oggetto sincronizzazione
- posizione delta
- rotazione delta
- altro stato dell'oggetto
Meta Event A
- Alcuni dati
Meta Event B
- Alcuni dati

Etc.

La mia reazione iniziale è creare una classe base Message e quindi creare sottoclassi ObjectSyncMessage , MetaEventAMessage , PeerConnectedMessage , ecc. perché ogni messaggio richiede variabili membro completamente diverse rispetto agli altri eventi.

Mi blocco quando vado ad elaborare la coda dei messaggi. Tutto ciò che ho letto dice di evitare l'uso di un interruttore e di determinare a quale classe appartiene un messaggio (vedi qui ).

C'è un modo migliore per affrontare questo problema? Non penso di volere che i messaggi stessi agiscano sullo stato del resto della mia applicazione, ma piuttosto fungono da sacchetti di dati e mi permettono di gestire lo stato della mia applicazione nella classe che funziona attraverso la coda.

c++ design-patterns networking message-queue

posta Matt Reyer 25.02.2016 - 05:40

fonte

1 risposta

Leggi altre domande sui tag c++ design-patterns networking message-queue

Come faccio a decidere se creare un tipo di dati di input / output come array o classe? Come vengono memorizzati gli oggetti in unordered_sets?

score 3 · Accepted Answer

Durante l'elaborazione dei messaggi nella coda, probabilmente si desidera chiamare una funzione di elaborazione specifica per il tipo più derivato del messaggio che si sta guardando. L'unico posto in cui tale informazione è naturalmente disponibile è nel messaggio stesso.

Un pattern di progettazione che è utile qui è il Pattern visitatori . Ciò porta a una progettazione in cui le specifiche classi di messaggi sanno come elaborarsi, chiamando una funzione specifica per quel tipo di messaggio su un oggetto MessageHandler .

class Message;
class ObjectSyncMessage;
class PeerConnectedMessage;

class IMessageHandler {
public:
  void HandleGenericMessage(Message*);
  void HandleObjectSyncMessage(ObjectSyncMessage*);
  void HandlePeerConnectedMessage(PeerConnectedMessage*);
};

class Message {
public:
  virtual void Handle(IMessageHandler* handler)
  {
    handler->HandleGenericMessage(this);
  }
  //... other methods
};

class ObjectSyncMessage : public Message {
public:
  // override of base-class function
  virtual void Handle(IMessageHandler* handler)
  {
    handler->HandleObjectSyncMessage(this);
  }
  //... other methods
};

class PeerConnectedMessage : public Message {
public:
  // override of base-class function
  virtual void Handle(IMessageHandler* handler)
  {
    handler->HandlePeerConnectedMessage(this);
  }
  //... other methods
};

// in the queue handling function:
Message* aMessage = // read from queue
aMessage->Handle(aMessageHandler);