473,320 Members | 2,122 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

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

Jul 22 '05 #1
12 1440

"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()!
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;
};
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl



Jul 22 '05 #2

"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
Jul 22 '05 #3


Peter van Merkerk 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()!

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;
};
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl



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

~ Daniel


Jul 22 '05 #4
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; ^^^^^ 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.
Jul 22 '05 #5


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

Jul 22 '05 #6
On Mon, 09 Feb 2004 16:49:56 +0100, DeMarcus <no****@tellus.orb> wrote:
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)?

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. :)


Jul 22 '05 #7
DeMarcus wrote:


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

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #8
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. 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'.
Jul 22 '05 #9
DeMarcus wrote:
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);
};

Jul 22 '05 #10

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:

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



Jul 22 '05 #11
DeMarcus wrote:
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

--
Quidquid latine dictum sit, altum viditur.
Jul 22 '05 #12

Thanks!

Daniel
Martin Eisenberg wrote:
DeMarcus wrote:

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


Jul 22 '05 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

19
by: Christian Engström | last post by:
If you have a function that returns something by value, the gcc compiler (version 3.2.3 on Windows XP with MinGW) converts the returned value from the type you specify in the code, to the const...
16
by: Peter Ammon | last post by:
Often times, I'll have some malloc()'d data in a struct that need not change throughout the lifetime of the instance of the struct. Therefore, the field within the struct is declared a pointer to...
18
by: DaveLessnau | last post by:
I'm trying to learn C on my own and, apparently, my brain went on vacation somewhere. I just can't figure out how to parse the following function call: "void fillDeck( Card * const wDeck, const...
2
by: Lorenzo Castelli | last post by:
This is an old problem of mine. Basically I have an abstract base class which represents a generic iterator over a collection of elements, and various derived classes that implement the...
3
by: LuB | last post by:
I'm writing a Win32 application - and more specifically, doing event programming. I want the application to be const compliant but I'm faced with a bit of a conundrum. Physically, many of my...
16
by: recover | last post by:
#include <string> #include <iostream> using namespace std; class TConst { private: string con; string uncon; public:
0
by: wellingj | last post by:
A little back ground on what I'm trying to do: I'm making a generic weighted graph class (vertexes and edges althought I don't call them that) to implement some pathfinding algorithms like A* and D*....
6
by: Fabian Wein | last post by:
Hi, is there a way to call a const function from non const function? I have a non-const List GetList(); and want my
21
by: Christian Meier | last post by:
Hello NG I have the following code: file1.h: static const int iValue = 5; <EOF>
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.