Question about class relationships

[win8051]

http://cubeupload.com/files/ea1a29uml01.jpg
The UML diagram in the image above shows everything related to my problem. As you can see, there are two classes, "App" and "Item".
On runtime one object(let's call it "x") of the class "App" is created, which in turn creates several objects of the class "Item". The items, however, don't even know that x exists, because it's a one-way relationship.
x handles things like the player score and calls the member function "OnTouchedByPlayer" of an item when the player touches it.
The item that was touched should then add points to the player's score, however this is not possible since the item doesn't know about x.

Of course I could pass x by reference to "OnTouchedByPlayer", but that doesn't seem like a good solution.
I'm not very experienced with C++, so I'm kind of stuck, and I'd like to know how this is usually done.

Oh, and another question:
There's only one instance/object(Is there a difference?) of "App" created throughout the runtime of the application, and it exists as long as the application is running. Doesn't that mean it would be more reasonable to use a namespace instead of a class?
That would essentially solve my first problem, but a namespace doesn't have things like private and public members, so I'm not sure if that'd be a good idea.

Thanks in advance.

[Disch]

The item that was touched should then add points to the player's score, however this is not possible since the item doesn't know about x.

This would be a bad design for this very reason. Item can't add a value to something it knows nothing about. And there's no reason for Item to know anything about App here.

A more practical solution would be to have Item report the score in some kind of getter function (perhaps int GetScore(); and then have App do something like

playerscore += item.GetScore();

Of course I could pass x by reference to "OnTouchedByPlayer", but that doesn't seem like a good solution.

I'm glad you recognized this. It's not a good solution. You should try to favor functions that return values instead of functions that have "out" param passed by reference. Passed-by-reference out params are more awkward to use, especially if there are subtle type differences.


Basically the way I see it working is that Item should only focus on being an Item. Getting the item (and tallying it's score) is not part of being an item, it's part of being a player, so the player should be the one doing it. It would be best to keep Item completely ignorant of the player if possible. Even having a function "OnTouchedByPlayer" is bad because it, in a sense, assumes the existence of a player.

There's only one instance/object(Is there a difference?) of "App" created throughout the runtime of the application, and it exists as long as the application is running.

No there's no difference between instance/object. They're synonymous here.

But that second sentence is an assumption that may not always be true....

Doesn't that mean it would be more reasonable to use a namespace instead of a class?

No. As mentioned above, the fact that there's only one object may not always be true. Just because it's true now doesn't mean you should write your program under that assumption. It's best to keep things modular so that if/when things change in the future, you still have that option open.

If you write your program assuming there is only 1 App, then if you need to add a second App later you're hosed and have to tear up and rewrite your whole program.

Stay flexible.