Hierarchy of objects, object "deep down below" needs to access one high up

[lars.uffmann]

Hey everyone!

I am (still) working on a project that I took over from former
students, so don't blame me for the criminal approach on coding *g*

The problem I have is fairly easy and while I have solutions, none of
them seems really "clean" to me and I was wondering if someone here
maybe had a better idea:

class geometry { ... }
class geometry2d : public geometry { ... }
class geometry3d : public geometry { ... }

class obj1 {
public:
int doSomething();
}

int obj1::doSomething()
{
// need to access Geometry2d from the main() function here somehow
}

class application {
private:
obj1* Obj1;
}

class environment {
public:
int run() { ... }
private:
application* Application;
}

int main (void) {
geometry2d* Geometry2d = new geometry2d();
environment* Environment = new environment();
Environment->run();
}

I hope I didn't make any grave syntax mistakes in the "sketch" of the
problem.
What it boils down to, is a bunch of objects that have a different
object pointer as a private property, this object is usually created in
their constructor. And then, some objects which are deep down that
chain, need to access the geometry object that was created in the main
function.
The current solution in the code was to implement a geometry argument
in each and every one of the object constructors and "pass it down" (as
I call it) from the main function. Now I find it pretty annoying to
have a bunch of constructor calls with that silly object argument just
because 5 levels lower, some mini-object needs to access it. It works,
but I don't like it.

Since the objects don't have the option of accessing a "parent" class
(project isn't designed that way), I was considering making the only
instance of the environment object a global variable, and storing the
needed geometry object pointer as a public property of the environment
class. I still like this solution better than the current one, but it
occured to me that object member functions accessing a global variable
isn't exactly clean programming style.

Does anyone have an idea that will eliminate the passing down of an
argument that isn't needed in most of the objects that pass it further
down, but will also avoid accessing a global object pointer from within
member functions?

Or can I get some people to assure me that using a global pointer to
the highest level object is "okay" programming here? *g*

Best Regards,

Lars

[mlimber]

[e-mail] wrote:

Hey everyone!

I am (still) working on a project that I took over from former
students, so don't blame me for the criminal approach on coding *g*

The problem I have is fairly easy and while I have solutions, none of
them seems really "clean" to me and I was wondering if someone here
maybe had a better idea:

class geometry { ... }
class geometry2d : public geometry { ... }
class geometry3d : public geometry { ... }

class obj1 {
public:
int doSomething();
}

int obj1::doSomething()
{
// need to access Geometry2d from the main() function here somehow
}

class application {
private:
obj1* Obj1;
}

class environment {
public:
int run() { ... }
private:
application* Application;
}

int main (void) {
geometry2d* Geometry2d = new geometry2d();
environment* Environment = new environment();
Environment->run();
}

I hope I didn't make any grave syntax mistakes in the "sketch" of the
problem.
What it boils down to, is a bunch of objects that have a different
object pointer as a private property, this object is usually created in
their constructor. And then, some objects which are deep down that
chain, need to access the geometry object that was created in the main
function.
The current solution in the code was to implement a geometry argument
in each and every one of the object constructors and "pass it down" (as
I call it) from the main function. Now I find it pretty annoying to
have a bunch of constructor calls with that silly object argument just
because 5 levels lower, some mini-object needs to access it. It works,
but I don't like it.

Since the objects don't have the option of accessing a "parent" class
(project isn't designed that way), I was considering making the only
instance of the environment object a global variable, and storing the
needed geometry object pointer as a public property of the environment
class. I still like this solution better than the current one, but it
occured to me that object member functions accessing a global variable
isn't exactly clean programming style.

Does anyone have an idea that will eliminate the passing down of an
argument that isn't needed in most of the objects that pass it further
down, but will also avoid accessing a global object pointer from within
member functions?

Or can I get some people to assure me that using a global pointer to
the highest level object is "okay" programming here? *g*

Best Regards,

Lars

Global variables are undesirable. Also, data members should generally
be private or protected (cf.
http://www.parashift.com/c++-faq-lit....html#faq-19.8)
to promote encapsulation, and since your one-line constructors avoid
the unnecessary coupling between objects, the constructors seem like
the better way to go, slightly annoying though it might be. One other
thing to consider is that if your geometry2d (or environment or
whatever) object is unique throughout the system, you should consider
using the Singleton pattern (see _Design Patterns_ by Gamma et al. and
chapter 6 of _Modern C++ Design_ by Alexandrescu).

Cheers! --M

[lars.uffmann]

Sorry for the late reply, I got carried away with my computer gaming
addiction, and didn't get anything done on this project. Thank you for
your opinion, I think I'll go with passing down the parameter as you
suggested, even though it is annoying :)

Reading through parashift info now though, and it seems I'll not get
around buying some literature on standards if I want to get my
programming skills up-to-date again *g*. The way you mentioned that
book, it seems to be some sort of bible for C++ :)

Regards,

Lars

[Alan Chen]

Is this a scenegraph application? If so, one of the ways that
scenegraphs solve the problem of carrying "global" data to the nodes is
by using the visitor pattern. The visitor interacts with the nodes by
traversing a graph of node objects. You could look at
http://www.openscenegraph.org as a reference.

[mlimber]

la**********@rwth-aachen.de wrote:

Sorry for the late reply, I got carried away with my computer gaming
addiction,
I'll refrain from moral pronouncements. ;-)
and didn't get anything done on this project. Thank you for
your opinion, I think I'll go with passing down the parameter as you
suggested, even though it is annoying :)

Reading through parashift info now though, and it seems I'll not get
around buying some literature on standards if I want to get my
programming skills up-to-date again *g*. The way you mentioned that
book, it seems to be some sort of bible for C++ :)

_Design Patterns_ is a sort of Holy Writ for OO software today. _Modern
C++ Design_ is partly an application of _Design Patterns_ in C++ and
partly a tutorial on how to work wonders in the language, particularly
using templates. I'd say the former book is essential for anyone
working in an OO language (C++, Java, C#, etc.). The latter book is
very helpful, especially if you want to understand and use the Boost
and/or Loki libraries well, and I refer to it fairly often.

Cheers! --M