If it is not a good idea, Why isn't it? && suggest a better way to represent network packets in a simulation.Code:namespace a { class A {.........}; } namespace b { class A : public a::A {...}; } namespace c { class A : public b::A {...}; } //and so on..for a few more times.
Last edited by manasij7479; 07-24-2011 at 07:14 AM.
On the face of it, it strikes me as rather clumsy. The art in design is trying to simplify things, and what you're doing seems to be doing the opposite.
I thought that having the same name for the class that is basically the same thing (each level only adding/subtracting an amount of data to/from the object) would simplify things.Originally Posted by grumpy
Could you pull out a less clumsy way of doing this ?
Not from what you've described, no. If you have three distinct classes with the same name, and each are "basically the same thing", I'm wondering why you would have distinct classes. If it doesn't make sense to have distinct classes, the spreading across namespaces makes even less sense.
Why not have one class that does the "thing"?
I meant, all of those classes would have (almost ) same data containers, and would basically be used to transfer data. But the way they are accessed and used would have to be vastly different.For example, the bottommost one would probably be in charge of serialization(possibly binary), and the top one would have the Standard algorithms used on them.
I would say yes, it's bad practice.
If they do the same thing (or close to it) you should try to consolidate them. And if you still need different namespaces to change the behavior, you could just store minimal data in them, which gets passed to the class. Basically very similar to what you're already doing, only much more readable.
If they do very different things, then they shouldn't even be sharing the same name in the first place!
Can you elaborate a bit ?And if you still need different namespaces to change the behavior, you could just store minimal data in them, which gets passed to the class.
Suppose I have a class(or classes) having a string as a data member.
and there is (are) read() functions. One of them, again as an example, uses stringstreams to parse the string; whereas another read() reads the data as a binary stream.
What would your approach mean in that case?
Last edited by manasij7479; 07-24-2011 at 09:07 AM.
I'm going to be stubborn after everybody saying it's bad practice saying: you can't really know.
It may be fine, in my opinion. Though it is unlikely it has been used in such a context.
Let me give an example. Let's say you design a C++ chat-application like Pidgin, allowing you to talk on many different protocols. Every protocol will have the same set of classes (ServerConnection, Conversation, etc). Each of these classes should be in a namespace to indicate the protocol, except for the base class (which will have pure virtual functions).
So in your case namespace A would for instance be "namespace ProtocolGeneric" (or whatever). B might be "ProtocolMsn", of which all classes will inherit from ProtocolGeneric's classes. Now, you have some nice binding together of classes per protocol, and still the inheritence allowing you to write nice functions like:
The only "odd" thing is A in namespace c inheriting from A in namespace b rather than from namespace a. This, too, might be fine: let's say one protocol is a pure extension of another protocol. For instance let's say hypothetical protocol X is based on the Irc protocol but has many more features. In my opinion it would be fine to inherit from the Irc protocol in that case.Code:void doSomething(ProtocolGeneric::Conversation &conversation) { conversation.sendMessage(...); }
Maybe some people disagree with me on this design of such a chat application, but I think it would be a nice design (though I haven't given it more than a few minutes thought for this post). My point is though, that these questions can not be answered without knowing more about the context and what you're doing.
My answer: Bad practice? Probably. But who knows?
Representing data packets in a network, as a simulation. (The namespaces being the layers and the class being a Packet class).knowing more about the context and what you're doing
That is why I've made the inheritance hierarchal instead of something like a tree.
Last edited by manasij7479; 07-24-2011 at 09:38 AM.
I found out that I'd be easier to get rid of the inheritance and then do what I was originally doing.Thank you very much...Your example gave me that wonderful idea.
