カプセル化とメッセージオブジェクト

Question

MediatorやObserverパターンなどの内部メッセージシステムを開発する場合、渡されたメッセージオブジェクトをカプセル化する最良の方法は何ですか？

いくつかのサービスに新しいJobを実行するように指示する次のメッセージオブジェクトを考えてみましょう。メッセージには、実行する必要があるJobが含まれています。

bool JobService::handleMessage(Message* msg) 
{ 
    switch(msg.getType()) 
    { 
    case MESSAGE_JOB: 
     runJob((dynamic_cast<NewJobMessage*>(msg))->m_Job); 
     return true; 
    case default: 
     return false; 
    } 
} 

これは、すべての罰金とダンディようだが、NewJobMessageもそれかかわらず、ジョブ・クラスについて決して知らないために持っている：今、メッセージは以下のサービスhandleMessage機能で取り扱うことができ

#define MESSAGE_JOB = 1 
class NewJobMessage: public Message 
{ 
    virtual int getType() { return MESSAGE_JOB; } 
    Job* m_Job; 
} 

それを意味のある方法で使用します。それは単にそれを運ぶだけです。

メッセージをデータに結合しないように他の方法を使用することをお勧めしますか？私はvoid*を使ってキャストしようと思っていましたが、それはハッキーだと思われ、他の人が自分のコードを解読すると混乱するかもしれません。

Answer 1

void *の教科書のケースが適切です。実際の弱点はvoid *ですが、実行時の型チェックがありますが、getType()メソッドは大きなものです。

それを理解しないようにするには、構造を単純にしてください。

// No need to inherit from this. 
struct Message { 
    int type; 
    void * data; 
}; 

限り、あなたは、これが混乱するべきではない組織的にコードとして、型指定されていないデータがstandard approach for message queuesです。

Answer 2

これらのメッセージがどのように渡されているか、どのくらい行くことができるかは言及していませんでしたが、一般的にネイティブオブジェクトを渡すことについてSTRONGLYにアドバイスします。それは苦痛と道に苦しむためのレシピです。これはメンテナンスとデバッグの悪夢、セキュリティアタックベクトル、設計結合問題です。このシステムが後で拡張されるときには悪化します（常にそうであるため）。

だから、これに対処するいくつかの方法があります。

• は、CDRを使用して情報やジョブ情報をエンコードするためにいくつかのような方法をエンコードします。レシーバは、同じ言語、システム、またはバイトサイズ/オーダーでない場合でも、CDRを元に戻して情報を戻します。コーディングするのはちょっと面倒ですが、計算上またはスペース上の費用がかかりません。
• あなたの好みや経験、データの情報の種類に応じて、JSONやXMLのようなより高いレベルへのリクエストをマーシャルしてください。これは通常、第三者の図書館の援助ではかなり簡単ですが、テキストとの変換やテキストの変換は少し高価です。また、問題を診断し、通過中のものを調べる方がずっと簡単です。

これらの要求を処理して転送する必要がある速度が非常に高く、処理が追いつかない場合を除いて、私はJSONに傾いています。現代のC++ライブラリの助けを借りてJSONを処理するのはかなり簡単です。