Chris Theis wrote:
"DeMarcus" <no****@tellus.orb> wrote in message
news:40**************@tellus.orb...
Hi,
I have an object, let's call it HydraulicPress
class HydraulicPress
{
public:
void setIron( Iron* iron ) const;
Iron* getIron( void ) const;
void pressIron( void ) const;
private:
mutable Iron* iron;
};
Notice the const at setIron()! That's because I want to be able to use
a HydraulicPress as a const object, meanwhile it operates on a different
object Iron.
Somehow I don't get the sense of this. Could you elaborate why this is
necessary? IMHO the set method should not be const, whereas the get method
should be. Furthermore you should be aware that your get method exposes the
internals to your data member which is most probably not a very good idea,
unless you have a good reason to do so.
I can't omit the get/set-methods since the press and iron
will be tight coupled for a while.
Is this bad design? Is there anyone who recognize this design problem
and could recommend some similar design pattern or way of thinking?
Does your hydraulic press need to have a member object which is set via the
get/set methods. Can't you pass the iron, which is currently processed in
the pressIron function. Furthermore you might consider enabling a more
general design (and also naming) as the press might be required & able to
process other materials but iron.
HTH
Chris
The whole thing is that the press and the iron are very tight coupled.
The iron does not need to know anything about the press though,
meanwhile pressing the iron on the other hand won't really change the
press in a "real world" sense. One could see the press as a machine
that everybody can use pressing iron, but nobody (except for some) have
the authority to change the settings like pressure and so on.
I know that it may be a stupid argument, that's why I was looking for
some known pattern for this behaviour so I didn't have to bother you
with the underlying problem. But now it seems it's time to reveal it.
Let's say we have a worker:
class Worker
{
public:
void workWith( const Tool& tool );
// A HydraulicPress inherits from Tool
};
Then I want to do this
{
Worker worker;
Iron iron;
worker.workWith( HydraulicPress( &iron ) );
// Or maybe
worker.workWith( Hammer( &iron ) );
}
I want to get away from creating a HydraulicPress until
it's really needed, which makes the code easy read. But
since passing objects like this making the HydraulicPress
needed to be const I was thinking of having it like a "tool"
that only changes other things than itself.
I mean, I can solve it with some kind of
void workWith( Tool* tool );
worker.workWith( HydraulicPress( &iron ).pointer_to_this() );
but that's even uglier than creating the press in advance
and pass it like this:
HydraulicPress press( &iron );
worker.workWith( press );
Eventhough I'm solving it today like this last solution
I'm still curious about the "tool" thinking concept. Maybe
it undermines all of what object oriented thinking stands
for, so all suggestions of better solutions are very welcome,
I'm a perfectionist you know. :)
Best Regards
Daniel Marcus