Hi Sergio,

I think I understand why you think it is too convoluted.. It does look like
it, but bear with me.. :)

In the end there is a trade off between complexity and flexibility. In your
case you chose one way. I would have chosen a different. It really depends
on the amount of flexibility needed later (and sometimes this is not easy to
determine when you are writing the code).

Please Note, I don't think you are wrong in using pointers like this. I'm
just trying to demonstrate an alternative that may be useful in another
project or just as a mental exercise ;)

I would agree for the simple Light/Switch case that the pointer solution you
use is simpler. However, lets extend the example to handle an apparently
simple extra requirement:

Staying with your electrical analogue, Lets say that we now have a motor
that moves something. It has a "position" that can be set.

Now say we want to have 3 switches, "left", "mid", and "right".

With the pointer method, we would need to implement one of two things:

1. Add functions to the motor class for "left" "mid" and "right".
2. Allow the Switch to store a parameter to pass to a general "move"
function.

Option 1 is doable, but really is adding extraneous stuff to the motor
class, do you keep extending this interface each time a new position is
needed. This is not very elegant, and arguably will cause a maintenance
nightmare in the future.

Option 2 means that a special version of a switch is needed just for motors.
Alternatively switches could be extended to take an argument and return it
when invoking the function pointers. However then all the code needs to be
changes on all the object currently using the switch mechanism. Also this
would probable need to be handled as a void* so arbitrary data can be
passed. Now the issue is you have designed out type safety in your target
class interfaces, not a beneficial thing. There are also going to be issues
with memory ownership and freeing.

With the command pattern, to implement this new functionality is simple.
There are no changes to the Switch class..

class Motor
{
        void Move(int position);
        // etc.
};

class MoveMotorCommand : public Command
{
public:
        // when constructed, we will need a target
        MoveMotorCommand ( Motor *pTarget, int NewPosition );

        virtual void Execute();
private:
        Motor *m_pTarget;
        int m_NewPosition;

};

MoveMotorCommand::MoveMotorCommand( Motor *pTarget, int NewPosition )
{
        m_pTarget = pTarget;
        m_NewPosition = NewPosition;
}

MoveMotorCommand::Execute()
{
        pTarget->Move( m_NewPosition );
}

Then you can construct as many different switches with different motor
positions as you like:

Motor     TheMotor;
Switch  MoveLeftSwitch;
Switch  MoveRightSwitch;
Switch  MoveMidSwitch;
Command *pCmd;

pCmd = new MoveMotorCommand( &TheMotor, 0 );
MoveLeftSwitch.AttachCommand( pCmd );

pCmd = new MoveMotorCommand( &TheMotor, 128 );
MoveRightSwitch.AttachCommand( pCmd );

pCmd = new MoveMotorCommand( &TheMotor, 256 );
MoveMidSwitch.AttachCommand( pCmd );

MoveMidSwitch.Invoke(); // when pressed

Or perhaps you want to implement a switch that turns on a number of lights..
or turns on a light and moves a motor.. You could implement a "macro"
command. You would attach arbitrary other commands to this macro command. It
would add them to an ordered list then when executed, it would execute each
one in turn.

It really does depend on your needs. A GUI is a prime example of where this
can really be helpful. The same mechanism can be used for menus, tool
buttons, and a command parser. As an added benefit, it is possible to
implement special commands that don't really have a "target" object but
alter global state or create a new window or document etc.. All with the
same Command infrastructure.

Basically, it only looks convoluted until you need to implement some extra
functionality, then it makes it really easy and neat.

Should we move this to [OT]?

Cheers,
Ash.

---
Ashley Roll
Digital Nemesis Pty Ltd
www.digitalnemesis.com
Mobile: +61 (0)417 705 718

> Sorry Ash, too convoluted for my liking. I prefer to use
> something like
> this:

[ snip example of pointers to member functions used as call-backs ]

> Regards
> Sergio Masci

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics