«

On Wednesday, 16 May 2012 17:09:47 UTC+2, 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?
>
> > 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
{

}

On Wednesday, 16 May 2012 17:09:47 UTC+2, 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?
>
> > 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 ?

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.

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?

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 .