design issue

[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.

[Victor Bazarov]

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

[softwareEngineer]

Thanks.

[Jorgen Grahn]

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愀 call it A) manage the request
> (command) from external systems and another (let愀 call it B) manage

> its own command.
>
> Once A receive one command calls one method of class B.
>

> Now I悲 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 .

[nick_keigh...@hotmail.com]

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

[softwareEngineer]

I think you've right ...

[nick_keigh...@hotmail.com]

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

[nick_keigh...@hotmail.com]

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

[Jorgen Grahn]

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

[Jorgen Grahn]

On Wed, 2012-05-16, nick_keigh...@hotmail.com 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.)

[softwareEngineer]

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]

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.

[nick_keigh...@hotmail.com]

On Thursday, May 17, 2012 7:49:53 AM UTC+1, Jorgen Grahn wrote:
> On Wed, 2012-05-16, nick_keigh...@hotmail.com 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?

[Jorgen Grahn]

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

>> >> I have two component, one (let愀 call it A) manage the request (command)
>> >> from external systems and another (let愀 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.