design issue

[softwareEngineer]

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.

 

[Victor Bazarov]

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

 

[softwareEngineer]

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.

 

[Jorgen Grahn]

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

 

[Guest]

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

comp.object is virtually dead

 

[Guest]

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

 

[softwareEngineer]

comp.object is virtually dead

I think you've right ...

 

[Guest]

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

I thought I'd posted this already...

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

 

[Jorgen Grahn]

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]

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

I thought I'd posted this already...



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.

[...]

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

 

[softwareEngineer]

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

I thought I'd posted this already...



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


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*);

};


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]

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

I thought I'd posted this already...



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


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*);

};


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]

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

I thought I'd posted this already...



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.

[...]

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

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.

 

[Guest]

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?

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?

 

[Jorgen Grahn]

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?

....

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