Is the following a bad practice in coding?

This is a discussion on Is the following a bad practice in coding? within the C++ Programming forums, part of the General Programming Boards category; Code: namespace a { class A {.........}; } namespace b { class A : public a::A {...}; } namespace c ...

  1. #1
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498

    Is the following a bad practice in coding?

    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.
    If it is not a good idea, Why isn't it? && suggest a better way to represent network packets in a simulation.
    Last edited by manasij7479; 07-24-2011 at 07:14 AM.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,341
    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.
    Right 98% of the time, and don't care about the other 3%.

  3. #3
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by grumpy View Post
    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.

    Could you pull out a less clumsy way of doing this ?
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,341
    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"?
    Right 98% of the time, and don't care about the other 3%.

  5. #5
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    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.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  6. #6
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,636
    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!

  7. #7
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    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.
    Can you elaborate a bit ?
    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.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  8. #8
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    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:
    Code:
    void doSomething(ProtocolGeneric::Conversation &conversation)
    {
      conversation.sendMessage(...);
    }
    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.

    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?

  9. #9
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    knowing more about the context and what you're doing
    Representing data packets in a network, as a simulation. (The namespaces being the layers and the class being a Packet class).
    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.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  10. #10
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by EVOEx View Post
    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:
    Code:
    void doSomething(ProtocolGeneric::Conversation &conversation){  conversation.sendMessage(...);}
    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.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?
    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.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Practice
    By Fox101 in forum C++ Programming
    Replies: 4
    Last Post: 04-25-2008, 01:18 PM
  2. Practice
    By RunDosRun in forum C++ Programming
    Replies: 3
    Last Post: 12-24-2007, 11:35 AM
  3. Practice
    By 00Sven in forum C Programming
    Replies: 1
    Last Post: 03-13-2006, 03:13 PM
  4. just practice
    By Fizz in forum C++ Programming
    Replies: 4
    Last Post: 05-27-2004, 07:24 AM
  5. Practice
    By Octorok101 in forum C++ Programming
    Replies: 1
    Last Post: 07-02-2002, 03:14 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21