Is this bad const design?

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

Best Regards
Daniel Marcus

"DeMarcus" <nobody@tellus.orb> wrote in message
news:4027711C.2090803@tellus.orb...[color=blue]
>
> 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()![/color]

Since setIron() changes the state of the HydraulicPress object it should
not be const.
[color=blue]
> That's because I want to be able to use
> a HydraulicPress as a const object[/color]

Why do you want use it as a const object, while at the same time you want
to change the state of that object? Shouldn't the object be non-const?
[color=blue]
>, meanwhile it operates on a different
> object Iron. I can't omit the get/set-methods since the press and iron
> will be tight coupled for a while.[/color]

The const function getIron() returns a non-const pointer. In general it is
not a good idea to expose internal data members like this.
[color=blue]
> Is this bad design?[/color]

I am inclined to believe so.
[color=blue]
> Is there anyone who recognize this design problem
> and could recommend some similar design pattern or way of thinking?[/color]

Why does iron have to be a parameter of the HydraulicPress class? Why not
pass iron as a parameter to the pressIron() function?

class HydraulicPress
{
public:
void pressIron(Iron& iron) const;
};

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl

"DeMarcus" <nobody@tellus.orb> wrote in message
news:4027711C.2090803@tellus.orb...[color=blue]
>
> 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.[/color]

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.
[color=blue]
> 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?
>[/color]

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

Peter van Merkerk wrote:[color=blue]
> "DeMarcus" <nobody@tellus.orb> wrote in message
> news:4027711C.2090803@tellus.orb...
>[color=green]
>>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()![/color]
>
>
> Since setIron() changes the state of the HydraulicPress object it should
> not be const.
>
>[color=green]
>>That's because I want to be able to use
>>a HydraulicPress as a const object[/color]
>
>
> Why do you want use it as a const object, while at the same time you want
> to change the state of that object? Shouldn't the object be non-const?
>
>[color=green]
>>, meanwhile it operates on a different
>>object Iron. I can't omit the get/set-methods since the press and iron
>>will be tight coupled for a while.[/color]
>
>
> The const function getIron() returns a non-const pointer. In general it is
> not a good idea to expose internal data members like this.
>
>[color=green]
>>Is this bad design?[/color]
>
>
> I am inclined to believe so.
>
>[color=green]
>>Is there anyone who recognize this design problem
>>and could recommend some similar design pattern or way of thinking?[/color]
>
>
> Why does iron have to be a parameter of the HydraulicPress class? Why not
> pass iron as a parameter to the pressIron() function?
>
> class HydraulicPress
> {
> public:
> void pressIron(Iron& iron) const;
> };
>
>
> --
> Peter van Merkerk
> peter.van.merkerk(at)dse.nl
>
>
>
>
>
>
>[/color]

Yes, you're right in all parts. That's why I'm so confused.
Please read more in my response to Chris Theis.

~ Daniel

DeMarcus <nobody@tellus.orb> wrote in message news:<4027711C.2090803@tellus.orb>...[color=blue]
> Hi,
>
> I have an object, let's call it HydraulicPress
>
> class HydraulicPress
> {
> public:
>
> void setIron( Iron* iron ) const;[/color]
^^^^^ What the..
[color=blue]
> 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.[/color]

Er so you want to assign the value of the parameter to the private
variable (say it in simple english heh). First of all if you're going
to write to the class and still have that const there I guarantee (or
guess) that it won't work. However if you don't include the const I am
99% sure it WILL work ;)
[color=blue]
> I can't omit the get/set-methods since the press and iron
> will be tight coupled for a while.[/color]

Who told you to omit them?
BTW: try making an assign operator for it ;)

Iron * operator = (Iron *iron1, const Iron *iron2) {
//... code
return Iron1; //or w/e you want
}
[color=blue]
> Is this bad design? Is there anyone who recognize this design problem
> and could recommend some similar design pattern or way of thinking?[/color]

No generally it's not bad design and deside what I suggested above, I
think your design is good.

Chris Theis wrote:[color=blue]
> "DeMarcus" <nobody@tellus.orb> wrote in message
> news:4027711C.2090803@tellus.orb...
>[color=green]
>>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.[/color]
>
>
> 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.
>
>[color=green]
>>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?
>>[/color]
>
>
> 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
>
>[/color]

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

On Mon, 09 Feb 2004 16:49:56 +0100, DeMarcus <nobody@tellus.orb> wrote:[color=blue]
>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.[/color]

The press should only be available as a const object to those who should
not be able to change it. It should be available as a non-const object
to those who should be able to change it. Having the modifier functions
non-const then ensures that only those who are allowed to can call them.

[color=blue]
>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 ) );
>}[/color]

Just do it the way you do it above. What's the problem?

[color=blue]
>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() );[/color]

No, that is undefined behavior. The temporary HydraulicPress object
can have been destroyed by the time 'workWith' is executed.

[color=blue]
>but that's even uglier than creating the press in advance
>and pass it like this:
>
>HydraulicPress press( &iron );
>worker.workWith( press );[/color]

What's ugly about that?

But do _reconsider_

void workWith( Tool const& aTool )

which you had at the beginning.

What's the problem you see with that (I see no problem)?

[color=blue]
>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. :)[/color]

DeMarcus wrote:[color=blue]
>
>
> 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.[/color]

Just an idea.

OK. So what about a 3-rd class. It's purpose is to represent the coupling
of the tool with the material it works with. In lack of a good name
I just call it a Task.

class Task
{
public:
Task( const Tool& tool, Material& material ) :
m_Tool( tool ), m_Material( material )
{}

...

private:
const Tool& m_Tool;
Material& m_Material;
};

It creates a relation between Tool and a Material, where the
tool can stay constant.

You would use it

HydraulicPress press;
Iron iron;

worker.workWith( Task( press, iron ) );

--
Karl Heinz Buchegger
kbuchegg@gascad.at

DeMarcus <nobody@tellus.orb> wrote in message news:<4027711C.2090803@tellus.orb>...[color=blue]
> 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. 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?
>
>
> Best Regards
> Daniel Marcus[/color]

I'm not sure to understand your problem.
But I think this is a strange idea to declare 'setIron' method as
'const', since it means that you won't be able to modify any object
attribute, and especially 'iron'.

DeMarcus wrote:
[color=blue]
> I have an object, let's call it HydraulicPress
>
> class HydraulicPress {[/color]
private:[color=blue]
> mutable Iron* pIron;
> public:
>
> void setIron(Iron* iron) const;
> Iron* getIron(void) const;
>
> void pressIron(void) const;[/color]

This is a no-op.
[color=blue]
>
> };
>
> 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. 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?[/color]

class HydraulicPress {
private:
// representation
mutable Iron* pIron;
public:
// functions
const
Iron& iron(void) const { // instead of getIron
return *pIron;
}
Iron& iron(void) { // instead of setIron
return *pIron;
}
HydraulicPress& pressIron(void);
};

Thanks for all answers.
I've been searching the net and I think I'm looking
for some kind of Adapter design pattern. All tips
of where to find loads of design patterns are very
welcome.

Best Regards
Daniel Marcus

DeMarcus wrote:[color=blue]
>
> 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. 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?
>
>
> Best Regards
> Daniel Marcus
>
>
>
>
>[/color]

DeMarcus wrote:
[color=blue]
> Thanks for all answers.
> I've been searching the net and I think I'm looking
> for some kind of Adapter design pattern. All tips
> of where to find loads of design patterns are very
> welcome.[/color]

Start here:
http://hillside.net/patterns/onlinepatterncatalog.htm

Martin

--
Quidquid latine dictum sit, altum viditur.

Thanks!

Daniel

Martin Eisenberg wrote:[color=blue]
> DeMarcus wrote:
>
>[color=green]
>>Thanks for all answers.
>>I've been searching the net and I think I'm looking
>>for some kind of Adapter design pattern. All tips
>>of where to find loads of design patterns are very
>>welcome.[/color]
>
>
> Start here:
> http://hillside.net/patterns/onlinepatterncatalog.htm
>
>
> Martin
>[/color]