I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction.
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
11  1482 
Angus wrote:
I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction.
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
No.
If the base class is aware of all message types and can know what
function to call for each of them, you don't need the derived types
at all. Just let the single message class do its job.
Here is the scenario where you'd need derived classes and polymorphic
behaviour:
Your "processor" class knows nothing about the types, but it can
register itself in the message dispatcher registry. When registering
the "processor" says what type of message it processes. The
dispatcher then creates a map of instances for each type:
map<message_typ e, processor_base* registry;
and any time a message comes the dispatcher gets the type and calls
the processor using the pointer it obtains by looking up the message
type in the registry.
The difference here is (a) the processors are not known ahead of
time, they come from some plug-ins that may or may not exist, and
(b) the number of message types is not necessarily static, it can
change from run to run, when new processors are developed to serve
new message types.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
On Sep 19, 1:11 am, Angus <anguscom...@gm ail.comwrote:
I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction.
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
Hi, Angus
I think you've made a reasonable approach. What I'm understanding
about your development is the system deals with a number of different
types of messages. That way would allow you to extend the system when
more different types of messages should be supported by the system.
Since I haven't fully understand what you are really doing, I believe
the tasks and actions between different types would be significant. If
this is right then, of course, you should make an abstract class for
all the message classes.
Cheers,
On Sep 18, 11:38 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:
Angus wrote:
I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction.
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
No.
If the base class is aware of all message types and can know what
function to call for each of them, you don't need the derived types
at all. Just let the single message class do its job.
Here is the scenario where you'd need derived classes and polymorphic
behaviour:
Your "processor" class knows nothing about the types, but it can
register itself in the message dispatcher registry. When registering
the "processor" says what type of message it processes. The
dispatcher then creates a map of instances for each type:
map<message_typ e, processor_base* registry;
and any time a message comes the dispatcher gets the type and calls
the processor using the pointer it obtains by looking up the message
type in the registry.
The difference here is (a) the processors are not known ahead of
time, they come from some plug-ins that may or may not exist, and
(b) the number of message types is not necessarily static, it can
change from run to run, when new processors are developed to serve
new message types.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
This is very similar to how we do message processing in our servers.
The "pattern" is essentially a factory. I came across the idea of
registering the processors from the Modern C++ Design book.
On Sep 19, 1:38 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:
Angus wrote:
I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction.
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
No.
If the base class is aware of all message types and can know what
function to call for each of them, you don't need the derived types
at all. Just let the single message class do its job.
Here is the scenario where you'd need derived classes and polymorphic
behaviour:
Your "processor" class knows nothing about the types, but it can
register itself in the message dispatcher registry. When registering
the "processor" says what type of message it processes. The
dispatcher then creates a map of instances for each type:
map<message_typ e, processor_base* registry;
and any time a message comes the dispatcher gets the type and calls
the processor using the pointer it obtains by looking up the message
type in the registry.
The difference here is (a) the processors are not known ahead of
time, they come from some plug-ins that may or may not exist, and
(b) the number of message types is not necessarily static, it can
change from run to run, when new processors are developed to serve
new message types.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Hi Victor,
Wow, I envy your deep level of understanding of C++ programming
language and compare to your knowledge, I'm just a novice. I have a
question about your approach though. What if the messages have
different member variables, making and using an abstract class would
be a better idea? For instance, there are two different types of
message class ImageLoadingMes sage and TextLoadingMess age. Let say
ImageLoadingMes sage contains sender's information as well as pixel
range information like X and Y whereas TextLoadingMess age contains,
again sender's information, and the actual text data. In this case,
isn't that making a super class for the two would be an ideal way of
doing so?
Cheers,
On Sep 19, 1:50 am, "AnonMail2...@g mail.com" <AnonMail2...@g mail.com>
wrote:
On Sep 18, 11:38 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:
Angus wrote:
I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction.
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
No.
If the base class is aware of all message types and can know what
function to call for each of them, you don't need the derived types
at all. Just let the single message class do its job.
Here is the scenario where you'd need derived classes and polymorphic
behaviour:
Your "processor" class knows nothing about the types, but it can
register itself in the message dispatcher registry. When registering
the "processor" says what type of message it processes. The
dispatcher then creates a map of instances for each type:
map<message_typ e, processor_base* registry;
and any time a message comes the dispatcher gets the type and calls
the processor using the pointer it obtains by looking up the message
type in the registry.
The difference here is (a) the processors are not known ahead of
time, they come from some plug-ins that may or may not exist, and
(b) the number of message types is not necessarily static, it can
change from run to run, when new processors are developed to serve
new message types.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
This is very similar to how we do message processing in our servers.
The "pattern" is essentially a factory. I came across the idea of
registering the processors from the Modern C++ Design book.
Oh... I missed the part saying "message processing in servers"... =)
Angus wrote:
I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction.
The base class works out what the type of message is and then calls
then your base class have to know all message types and remember whom to
dispatch the message. What if a new message type is needed (Maybe you
say that's not the case here). Then I guess you have to borrow *switch*
polymorphic has a usage of avoiding switch/if statement, as they are not
maintainable.
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
--
Thanks
Barry
Alexander Dong Back Kim wrote:
[..] What if the messages have
different member variables, making and using an abstract class would
be a better idea?
Maybe. There was not enough information to conclude anything.
For instance, there are two different types of
message class ImageLoadingMes sage and TextLoadingMess age. Let say
ImageLoadingMes sage contains sender's information as well as pixel
range information like X and Y whereas TextLoadingMess age contains,
again sender's information, and the actual text data. In this case,
isn't that making a super class for the two would be an ideal way of
doing so?
Creating a hierarchy of classes makes sense in may instances. What
you're describing seems to fit this particular scheme:
class AbstractMessage {
enum type { Type0, Type1, .... , TypeN };
type m_type;
virtual ResultType process_type0() { return 0; }
virtual ResultType process_type1() { return 0; }
...
virtual ResultType process_typeN() { return 0; }
protected:
AbstractMessage (type t) : m_type(t) {}
virtual ~AbstractMessag e() {}
public:
ResultType process() {
switch (m_type) {
case Type0:
return process_type0() ;
case Type1:
return process_type1() ;
...
case TypeN:
return process_typeN() ;
}
};
class MessageType0 : public AbstractMessage {
ResultType process_type0() { /* use m_str */ return 1; }
std::string m_str;
public:
MessageType0(st d::string const & str)
: AbstractMessage (Type0), m_str(str) {}
};
class MessageType1 : public AbstractMessage {
ResultType process_type1() { /* use m_a, m_b */ return 1; }
int m_a, m_b;
public:
MessageType1(in t a, int b)
: AbstractMessage (Type1), m_a(a), m_b(b) {}
};
I call it *slightly inelegant*.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Alexander Dong Back Kim wrote:
On Sep 19, 1:38 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:
>Angus wrote:
>>I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformAction .
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
No.
If the base class is aware of all message types and can know what
function to call for each of them, you don't need the derived types
at all. Just let the single message class do its job.
Here is the scenario where you'd need derived classes and polymorphic
behaviour:
Your "processor" class knows nothing about the types, but it can
register itself in the message dispatcher registry. When registering
the "processor" says what type of message it processes. The
dispatcher then creates a map of instances for each type:
map<message_typ e, processor_base* registry;
and any time a message comes the dispatcher gets the type and calls
the processor using the pointer it obtains by looking up the message
type in the registry.
The difference here is (a) the processors are not known ahead of
time, they come from some plug-ins that may or may not exist, and
(b) the number of message types is not necessarily static, it can
change from run to run, when new processors are developed to serve
new message types.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Hi Victor,
Wow, I envy your deep level of understanding of C++ programming
language and compare to your knowledge, I'm just a novice. I have a
question about your approach though. What if the messages have
different member variables, making and using an abstract class would
be a better idea? For instance, there are two different types of
Yes,
when we don't have C++, in a thread entry function
void thrd_func(void* );
it uses void* for abstraction.
why not have an abstract class for messages.
message class ImageLoadingMes sage and TextLoadingMess age. Let say
ImageLoadingMes sage contains sender's information as well as pixel
range information like X and Y whereas TextLoadingMess age contains,
again sender's information, and the actual text data. In this case,
isn't that making a super class for the two would be an ideal way of
doing so?
You can provide some helper functions in the super class if the derived
class have some common operations. Actually not sure what you mean.
The thrd_func example again,
the derived class should know how to deal with the abstract data
(pointer/reference) just like thrd_func knows how to deal with the pointer.
--
Thanks
Barry
On Sep 19, 2:11 am, Barry <dhb2...@gmail. comwrote:
Alexander Dong Back Kim wrote:
On Sep 19, 1:38 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:
Angus wrote:
I am developing a server which receives a range of different
messages. There are about 12 different message types so I thought
that a good idea would be to devise a class for each message type.
Then in my base class I for example have a pure virtual function
called eg PerformAction. Then in each message class I implement
PerformActio n.
The base class works out what the type of message is and then calls
the correct inherited class function. Eg if the function were a blah
message which simply responds with the message "Blah" then the base
class would call the Blah class PerformAction function which would
maybe create a blah message response.
Does this seem like a reasonable design in this scenario?
No.
If the base class is aware of all message types and can know what
function to call for each of them, you don't need the derived types
at all. Just let the single message class do its job.
Here is the scenario where you'd need derived classes and polymorphic
behaviour:
Your "processor" class knows nothing about the types, but it can
register itself in the message dispatcher registry. When registering
the "processor" says what type of message it processes. The
dispatcher then creates a map of instances for each type:
map<message_typ e, processor_base* registry;
and any time a message comes the dispatcher gets the type and calls
the processor using the pointer it obtains by looking up the message
type in the registry.
The difference here is (a) the processors are not known ahead of
time, they come from some plug-ins that may or may not exist, and
(b) the number of message types is not necessarily static, it can
change from run to run, when new processors are developed to serve
new message types.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Hi Victor,
Wow, I envy your deep level of understanding of C++ programming
language and compare to your knowledge, I'm just a novice. I have a
question about your approach though. What if the messages have
different member variables, making and using an abstract class would
be a better idea? For instance, there are two different types of
Yes,
when we don't have C++, in a thread entry function
void thrd_func(void* );
it uses void* for abstraction.
why not have an abstract class for messages.
message class ImageLoadingMes sage and TextLoadingMess age. Let say
ImageLoadingMes sage contains sender's information as well as pixel
range information like X and Y whereas TextLoadingMess age contains,
again sender's information, and the actual text data. In this case,
isn't that making a super class for the two would be an ideal way of
doing so?
You can provide some helper functions in the super class if the derived
class have some common operations. Actually not sure what you mean.
The thrd_func example again,
the derived class should know how to deal with the abstract data
(pointer/reference) just like thrd_func knows how to deal with the pointer.
--
Thanks
Barry
Thank you very much Barry and Victor =) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Myster Ious |
last post by:
Polymorphism replaces switch statements, making the code more
compact/readable/maintainable/OO whatever, fine!
What I understand, that needs to be done at the programming level, is
this:
a switch-case has a variable (most probably an enumeration) &
associated symbols or integral value. Selection is made, base on what
symbol/value the variable holds. So
|
by: Dave Theese |
last post by:
Please consider this code:
class base {};
class derived: public base {};
base *ptr = new derived;
cout << typeid(*base).name << endl;
In this case, I see output of "class base" rather than "class derived".
This is somewhat expected I suppose since my base class does not have any
|
by: Dave |
last post by:
What is the expected output of this program and why???
#include <iostream>
using namespace std;
class base
{
|
by: Aryeh M. Friedman |
last post by:
If I have something like this:
class NumberException {
};
class Number {
public:
...
virtual unsigned long getValue() {throw(NumberException);};
...
|
by: Karel Miklav |
last post by:
In lots of places in a programm I need to identify type of received
messages, so I create them as virtual classes and use RTTI to find their
type later. But these are simple messages, often without content, and I
hate how I make their base class: by adding a dummy virtual function.
Is there another way?
--
Regards,
| | |
by: Ben Pope |
last post by:
Hi all,
This is not something I've played around with much, but I'm designing
some factories and I want a function like this:
template<class T>
T* Creator() {
return new T;
}
|
by: jacek.dziedzic |
last post by:
Hello!
Suppose I have a class base, with virtual methods and a virtual
destructor and a bunch of classes,
derived1, derived2, ... which publicly derive from base. I then have a
pointer
base* foo;
which a complicated code allocates as one of derived's and sets up.
|
by: Arindam |
last post by:
#include <cstdio>
struct Test {
void bar() {
foo();
}
private:
virtual void foo() {
printf("Test\n");
}
|
by: tonytech08 |
last post by:
What I like about the C++ object model: that the data portion of the
class
IS the object (dereferencing an object gets you the data of a POD
object).
What I don't like about the C++ object model: that most OO features
are not
available for class object design without loss of POD-ness.
So, I'm more than leaning toward "bad" because of the limitations and
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
