Is this bad const design?

[DeMarcus]

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

 

[Peter van Merkerk]

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()!

Since setIron() changes the state of the HydraulicPress object it should
not be const.

That's because I want to be able to use
a HydraulicPress as a const object

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?

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

The const function getIron() returns a non-const pointer. In general it is
not a good idea to expose internal data members like this.

Is this bad design?

I am inclined to believe so.

Is there anyone who recognize this design problem
and could recommend some similar design pattern or way of thinking?

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;
};

 

[Chris Theis]

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

 

[DeMarcus]

Since setIron() changes the state of the HydraulicPress object it should
not be const.




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?




The const function getIron() returns a non-const pointer. In general it is
not a good idea to expose internal data members like this.




I am inclined to believe so.




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;
};

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

~ Daniel

 

[Chris Mantoulidis]

Hi,

I have an object, let's call it HydraulicPress

class HydraulicPress
{
public:

void setIron( Iron* iron ) const;

^^^^^ What the..

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.

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

I can't omit the get/set-methods since the press and iron
will be tight coupled for a while.

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
}

Is this bad design? Is there anyone who recognize this design problem
and could recommend some similar design pattern or way of thinking?

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

 

[DeMarcus]

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.




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

 

[Alf P. Steinbach]

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.

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.

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 ) );
}

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

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() );

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

but that's even uglier than creating the press in advance
and pass it like this:

HydraulicPress press( &iron );
worker.workWith( press );

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

 

[Karl Heinz Buchegger]

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.

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 ) );

 

[E. Robert Tisdale]

I have an object, let's call it HydraulicPress

class HydraulicPress { private:
mutable Iron* pIron;
public:

void setIron(Iron* iron) const;
Iron* getIron(void) const;

void pressIron(void) const;

This is a no-op.

};

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?

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);
};

 

[Eric Entressangle]

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

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]

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

 

[Martin Eisenberg]

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.

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


Martin

 

[DeMarcus]

Thanks!

Daniel

DeMarcus wrote:




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


Martin