design issue

Discussion in 'C++' started by softwareEngineer, May 15, 2012.

  1. Hi all,
    my topic is relate on C++ (because the system under maintenance is wrote inC++) but my issue is more on design. Would be great any your feedback/suggestion.
    I have two component, one (let´s call it A) manage the request (command) from external systems and another (let´s call it B) manage its own command.

    Once A receive one command calls one method of class B.
    Now I´d like to expose only one method from B (ProcessCommand) which accept a abstract class (ICommand). So B have to expose one method ProcessCommand, ICommand and all ConcreteCommand (derived by ICommand) that it manage.

    What do you think ? there is a better way to do it ?

    thanks.
    Robbie.
    softwareEngineer, May 15, 2012
    #1
    1. Advertising

  2. On 5/15/2012 10:47 AM, softwareEngineer wrote:
    > Hi all,
    > my topic is relate on C++ (because the system under maintenance is wrote in C++) but my issue is more on design. Would be great any your feedback/suggestion.
    > [..]


    Here is my suggestion: try 'comp.object' newsgroup.

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, May 15, 2012
    #2
    1. Advertising

  3. On Tuesday, 15 May 2012 16:47:22 UTC+2, softwareEngineer wrote:
    > Hi all,
    > my topic is relate on C++ (because the system under maintenance is wrote in C++) but my issue is more on design. Would be great any your feedback/suggestion.
    > I have two component, one (let´s call it A) manage the request (command) from external systems and another (let´s call it B) manage its own command.
    >
    > Once A receive one command calls one method of class B.
    > Now I´d like to expose only one method from B (ProcessCommand) which accept a abstract class (ICommand). So B have to expose one method ProcessCommand, ICommand and all ConcreteCommand (derived by ICommand) that it manage..
    >
    > What do you think ? there is a better way to do it ?
    >
    > thanks.
    > Robbie.


    Thanks.
    softwareEngineer, May 15, 2012
    #3
  4. softwareEngineer

    Jorgen Grahn Guest

    On Tue, 2012-05-15, softwareEngineer wrote:
    > Hi all,


    Please wrap your lines! I have done it for you below.

    > my topic is relate on C++ (because the system under maintenance is
    > wrote in C++) but my issue is more on design. Would be great any your
    > feedback/suggestion.
    >
    > I have two component, one (let´s call it A) manage the request
    > (command) from external systems and another (let´s call it B) manage
    > its own command.
    >
    > Once A receive one command calls one method of class B.
    >
    > Now I´d like to expose only one method from B (ProcessCommand) which
    > accept a abstract class (ICommand). So B have to expose one method
    > ProcessCommand, ICommand and all ConcreteCommand (derived by ICommand)
    > that it manage.
    >
    > What do you think ? there is a better way to do it ?


    I personally prefer not to deal with abstract classes and run-time
    polymorphism unless there is a clear need for it. What is the need in
    this case?

    Specific advice is impossible to give without much more details.

    Remember to design properly for whatever I/O mechanism you're using.
    E.g. if it's a TCP socket you're using, you cannot just pretend that
    it's someone sending you Commands -- at some level you need to think
    of it as a stream of octets which may arrive at thousands per second,
    or once a week, be interrupted or stuck at any time, and so on.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, May 15, 2012
    #4
  5. softwareEngineer

    Guest

    On Tuesday, May 15, 2012 4:06:05 PM UTC+1, Victor Bazarov wrote:

    > Here is my suggestion: try 'comp.object' newsgroup.


    comp.object is virtually dead
    , May 16, 2012
    #5
  6. softwareEngineer

    Guest

    On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:

    > I have two component, one (let´s call it A) manage the request (command) from external systems and another (let´s call it B) manage its own command.


    must we? Must we call them A and B? How about ExternalProcessor and InternalProcessor?

    > Once A receive one command calls one method of class B.
    > Now I´d like to expose only one method from B (ProcessCommand) which accept a abstract class (ICommand). So B have to expose one method ProcessCommand,


    ok

    > ICommand and all ConcreteCommand (derived by ICommand) that it manage.


    why? Surely that is B's business?

    > What do you think ? there is a better way to do it ?


    Well as others have said we don't really have enough details about your app.. That's another reason I don't like A and B and Foo as class names. We have no intuitive idea what they are about.

    But what about this:-

    // InternalProcessor.h

    #ifndef INTERNAL_H
    #define INTERNAL_H

    class ICommand; // no implementaion needed

    class InternalProcessor
    {
    public:
    ProcessCommand(ICommand*);
    };

    #endif

    Or look up the Proxy design pattern
    , May 16, 2012
    #6
  7. On Wednesday, 16 May 2012 13:02:54 UTC+2, wrote:
    > On Tuesday, May 15, 2012 4:06:05 PM UTC+1, Victor Bazarov wrote:
    >
    > > Here is my suggestion: try 'comp.object' newsgroup.

    >
    > comp.object is virtually dead


    I think you've right ...
    softwareEngineer, May 16, 2012
    #7
  8. softwareEngineer

    Guest

    On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:

    I thought I'd posted this already...

    <snip>

    > I have two component, one (let´s call it A) manage the request (command) from external systems and another (let´s call it B) manage its own command.


    lets not! Why A and B? Can't we have someting that conveys a little meanining? How about ExternalCommandProcessor and InternalCommandProcessor?

    > Once A receive one command calls one method of class B.
    > Now I´d like to expose only one method from B (ProcessCommand) which accept a abstract class (ICommand). So B have to expose one method ProcessCommand,


    yes

    > ICommand and all ConcreteCommand (derived by ICommand) that it manage.


    why? Isn't this all B's business? Why can't you do this in the header file:-

    class ICommand; // declaration only

    class InternalCommandProcessor
    {
    public:
    ProcessCommand (ICommand*);

    };

    > What do you think ? there is a better way to do it ?


    read the Proxy design pattern
    , May 16, 2012
    #8
  9. softwareEngineer

    Jorgen Grahn Guest

    On Wed, 2012-05-16, wrote:
    > On Tuesday, May 15, 2012 4:06:05 PM UTC+1, Victor Bazarov wrote:
    >
    >> Here is my suggestion: try 'comp.object' newsgroup.

    >
    > comp.object is virtually dead


    And even if it wasn't they'd focus on object-oriented designs, which
    IMHO is a limitation.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, May 17, 2012
    #9
  10. softwareEngineer

    Jorgen Grahn Guest

    On Wed, 2012-05-16, wrote:
    > On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:
    >
    > I thought I'd posted this already...
    >
    > <snip>
    >
    >> I have two component, one (let´s call it A) manage the request (command)
    >> from external systems and another (let´s call it B) manage its own command.

    >
    > lets not! Why A and B? Can't we have someting that conveys a little
    > meanining? How about ExternalCommandProcessor and
    > InternalCommandProcessor?


    Almost as bad. There's information we don't have access to -- A and B
    already exist, and have some meaning and responsibilities, but we
    haven't been told what they are. We can't make up useful names.

    Perhaps A deals with protocol-specific stuff like sequence numbering,
    demultiplexing, flow control and so on -- but that's just a guess.

    [...]

    >> What do you think ? there is a better way to do it ?

    >
    > read the Proxy design pattern


    Yes; he seems to be influenced by the design pattern line of thinking;
    then going to the source is a good idea. (Personally I don't like
    them very much though.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, May 17, 2012
    #10
  11. On Wednesday, 16 May 2012 17:09:47 UTC+2, wrote:
    > On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:
    >
    > I thought I'd posted this already...
    >
    > <snip>
    >
    > > I have two component, one (let´s call it A) manage the request (command) from external systems and another (let´s call it B) manage its own command.

    >
    > lets not! Why A and B? Can't we have someting that conveys a little meanining? How about ExternalCommandProcessor and InternalCommandProcessor?
    >
    > > Once A receive one command calls one method of class B.
    > > Now I´d like to expose only one method from B (ProcessCommand) which accept a abstract class (ICommand). So B have to expose one method ProcessCommand,

    >
    > yes
    >
    > > ICommand and all ConcreteCommand (derived by ICommand) that it manage.

    >
    > why? Isn't this all B's business? Why can't you do this in the header file:-
    >
    > class ICommand; // declaration only
    >
    > class InternalCommandProcessor
    > {
    > public:
    > ProcessCommand (ICommand*);
    >
    > };
    >
    > > What do you think ? there is a better way to do it ?

    >
    > read the Proxy design pattern

    Thanks for your answer.

    First more detail on what I had before refactoring :
    simplifying I had an exe and 6 dll. The exe used the dll services (methods exposed). The exe is more on low level communications mechanism. So it parse the request (from the network) and send a specific request to a dll that will perform the request. the easiest way would have be to pass the (low level) request from exe with just one method in the dll and a little parser in it. But I'd like to abstract (in the dll) of low level mechanism tipical of the engine (exe) so I thought to encapsulate the low level request in a command and pass it to the dll method.

    Now
    The InternalCommandProcessor is exactly what I've done. But I've even exposed the concrete command which the dll can perform.
    something like :

    class QoSCommand : public ICommand
    {

    }
    softwareEngineer, May 17, 2012
    #11
  12. On Wednesday, 16 May 2012 17:09:47 UTC+2, wrote:
    > On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:
    >
    > I thought I'd posted this already...
    >
    > <snip>
    >
    > > I have two component, one (let´s call it A) manage the request (command) from external systems and another (let´s call it B) manage its own command.

    >
    > lets not! Why A and B? Can't we have someting that conveys a little meanining? How about ExternalCommandProcessor and InternalCommandProcessor?
    >
    > > Once A receive one command calls one method of class B.
    > > Now I´d like to expose only one method from B (ProcessCommand) which accept a abstract class (ICommand). So B have to expose one method ProcessCommand,

    >
    > yes
    >
    > > ICommand and all ConcreteCommand (derived by ICommand) that it manage.

    >
    > why? Isn't this all B's business? Why can't you do this in the header file:-
    >
    > class ICommand; // declaration only
    >
    > class InternalCommandProcessor
    > {
    > public:
    > ProcessCommand (ICommand*);
    >
    > };
    >
    > > What do you think ? there is a better way to do it ?

    >
    > read the Proxy design pattern


    Thanks for your answer.

    First more detail on what I had before refactoring :
    simplifying, I have an exe and 6 dll. The exe uses the dll services (methods
    exposed). The exe is more on low level communications mechanism. So it parse
    the request (from the network) and send a specific request to a dll that
    will perform the request. the easiest way would have be to pass the
    (low level) request from exe with just one method in the dll and a little
    parser in it. But I'd like to abstract (in the dll) to low level mechanism
    tipical of the engine (exe) so I thought to encapsulate the low level request
    in a command and pass it to the dll method (processCommand).

    Now
    The InternalCommandProcessor is exactly what I've done. But I've even exposed
    the concrete commands which the dll can perform.
    something like :

    class ICommand
    {
    public :
    virtual bool execute () = 0;
    }

    class QoSCommand : public ICommand
    {
    private:
    // some member needed for QoS check !
    public :
    void setDelay ();
    void setWindowQoS ();

    virtual bool execute ();
    }

    bool QoSCommand::execute()
    {
    // perform the method which was previously
    // exposed by dll.
    return doCheckQoS ();
    }

    then the processCommand method exposed by the dll :
    bool processCommand (ICommand &command)
    {
    // some other operation ...

    return command.execute();
    }

    My doubt is on exposing the concrete command. what other althernative
    have I ?
    softwareEngineer, May 17, 2012
    #12
  13. On Thursday, 17 May 2012 08:49:53 UTC+2, Jorgen Grahn wrote:
    > On Wed, 2012-05-16, wrote:
    > > On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:
    > >
    > > I thought I'd posted this already...
    > >
    > > <snip>
    > >
    > >> I have two component, one (let´s call it A) manage the request (command)
    > >> from external systems and another (let´s call it B) manage its own command.

    > >
    > > lets not! Why A and B? Can't we have someting that conveys a little
    > > meanining? How about ExternalCommandProcessor and
    > > InternalCommandProcessor?

    >
    > Almost as bad. There's information we don't have access to -- A and B
    > already exist, and have some meaning and responsibilities, but we
    > haven't been told what they are. We can't make up useful names.
    >
    > Perhaps A deals with protocol-specific stuff like sequence numbering,
    > demultiplexing, flow control and so on -- but that's just a guess.
    >
    > [...]
    >
    > >> What do you think ? there is a better way to do it ?

    > >
    > > read the Proxy design pattern

    >
    > Yes; he seems to be influenced by the design pattern line of thinking;
    > then going to the source is a good idea. (Personally I don't like
    > them very much though.)
    >
    > /Jorgen
    >
    > --
    > // Jorgen Grahn <grahn@ Oo o. . .
    > \X/ snipabacken.se> O o .


    Personally I think to design pattern as an elegant solution
    which (sometime) I can apply to my problem and not like
    something cool to absolutely apply.

    bye
    robbie.
    softwareEngineer, May 17, 2012
    #13
  14. softwareEngineer

    Guest

    On Thursday, May 17, 2012 7:49:53 AM UTC+1, Jorgen Grahn wrote:
    > On Wed, 2012-05-16, wrote:
    > > On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:


    > >> I have two component, one (let´s call it A) manage the request (command)
    > >> from external systems and another (let´s call it B) manage its own command.

    > >
    > > lets not! Why A and B? Can't we have someting that conveys a little
    > > meanining? How about ExternalCommandProcessor and
    > > InternalCommandProcessor?

    >
    > Almost as bad. There's information we don't have access to -- A and B
    > already exist, and have some meaning and responsibilities, but we
    > haven't been told what they are. We can't make up useful names.


    well I think A and B are poor names. I really hope the actual code doesn't use them. How do you /know/ A and B have meaning and responsibilities assigned to them?

    Besides we do know that A "manages requests/commands from external systems".. So ProcessExternalCommand:: seems pretty reasonable.

    > Perhaps A deals with protocol-specific stuff like sequence numbering,
    > demultiplexing, flow control and so on -- but that's just a guess.


    maybe. So what?

    > >> What do you think ? there is a better way to do it ?

    > >
    > > read the Proxy design pattern

    >
    > Yes; he seems to be influenced by the design pattern line of thinking;
    > then going to the source is a good idea. (Personally I don't like
    > them very much though.)


    why not? Just curious. Too restrictive? Broken?
    , May 18, 2012
    #14
  15. softwareEngineer

    Jorgen Grahn Guest

    On Fri, 2012-05-18, wrote:
    > On Thursday, May 17, 2012 7:49:53 AM UTC+1, Jorgen Grahn wrote:
    >> On Wed, 2012-05-16, wrote:
    >> > On Tuesday, May 15, 2012 3:47:22 PM UTC+1, softwareEngineer wrote:

    >
    >> >> I have two component, one (let´s call it A) manage the request (command)
    >> >> from external systems and another (let´s call it B) manage its own command.
    >> >
    >> > lets not! Why A and B? Can't we have someting that conveys a little
    >> > meanining? How about ExternalCommandProcessor and
    >> > InternalCommandProcessor?

    >>
    >> Almost as bad. There's information we don't have access to -- A and B
    >> already exist, and have some meaning and responsibilities, but we
    >> haven't been told what they are. We can't make up useful names.

    >
    > well I think A and B are poor names. I really
    > hope the actual code doesn't use them.
    > How do you /know/ A and B have
    > meaning and responsibilities assigned to them?


    I don't understand what you're getting at. It's obvious from his
    posting that A and B only exist as placeholder names in the posting
    itself. And it's obvious from *our* postings that we don't like that.
    What's there to argue about?

    ....
    >> > read the Proxy design pattern

    >>
    >> Yes; he seems to be influenced by the design pattern line of thinking;
    >> then going to the source is a good idea. (Personally I don't like
    >> them very much though.)

    >
    > why not? Just curious. Too restrictive? Broken?


    I don't want to be involved in a heated discussion about that, too.
    I just mentioned it so it wouldn't seem like I was advocating design
    patterns.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, May 18, 2012
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ZackS
    Replies:
    5
    Views:
    6,780
    Just an Illusion
    Jul 9, 2004
  2. SpamProof
    Replies:
    3
    Views:
    636
    SpamProof
    Dec 1, 2003
  3. dave
    Replies:
    5
    Views:
    580
    William Brogden
    Jul 17, 2004
  4. Tim Smith
    Replies:
    2
    Views:
    841
    Tim Smith
    Dec 15, 2004
  5. trint
    Replies:
    1
    Views:
    350
    trint
    Nov 21, 2006
Loading...

Share This Page