Accessing another class's setter method

Question

I have a GameWorld class which inherits CCLayer and returns a CCScene. My GameWorld has a synthesized property, "score." The score is incremented every 2 seconds - so the longer you play the game, the higher it goes.

Great!

Now I call my GameObject, which inherits CCNode and returns a sprite, to be added as a child to the layer. Every GameObject has a "cost" property.

But whenever you add a new sprite, your score goes down according to the cost.

So how can I set my (int) score in the GameWorld, FROM the GameObject, which contains the (int) cost that will decrement the score?

In other words, it's easy to set/get the GameWorld score from within the class, but my GameObject class can't see GameWorld. Is there a way to expose the setter method for a class's property to another class?

Thanks!

score 0 · Answer 1 · answered Nov 12 '11 at 20:58

0

If the GameWorld holds instances of GameObjects, then just do it within GameWorld.

self.score -= anObject.cost;

Otherwise, there has to be some class which maintains a reference to GameWorld. Do it there.

aWorld.score -= anObject.cost

answered Nov 12 '11 at 20:58

Patrick Perini

22,555
12
59
88

score 0 · Answer 2 · answered Nov 12 '11 at 21:00

To set the property of the other class object register it as that other object's property observer or create a weak reference between those two objects.

For instance consider adding a @property (nonatomic, assign) GameWorld* gameWorld; to your GameObject class. Then when you create the two set gameObject's property gameWorld.

GameWorld *gameWorld = //init;
GameObject *gameObject = //init;
gameObject.gameWorld = gameWorld;

Then you can access gameWorld object and all of its properties from your GameObject class.

score 0 · Answer 3 · edited May 23 '17 at 11:55

0

Turn your GameWorld class into a "temporary" singleton (in lack of a better name for this pattern). This works well for scenes in Cocos2D, and other nodes (layers) that are guaranteed to remain in the node hierachy longer than their siblings/children.

static GameWorld* instance;

-(id) init
{
    if ((self = [super init]))
    {
        instance = self;
    }
    return self;
}

-(void) dealloc
{
    instance = nil;
    [super dealloc];
}

+(GameWorld*) sharedGameWorld
{
    return instance;
}

You can then access your game world instance from any object in that world simply like this:

[GameWorld sharedGameWorld].score += 10;

Personally I think this beats passing around weak references, because the tendency to retain is there. And when you do retain the GameWorld in one of the objects that the GameWorld contains, then you have a retain cycle and thus will leak the entire scene.

edited May 23 '17 at 11:55

Community

1
1

answered Nov 12 '11 at 21:13

CodeSmile

64,284
20
132
217

I'm doing something like this. While I don't want to create too many singletons, an object like GameWorld seems like a good candidate for one. Why have you called this a 'temporary' singleton? It looks normal. – Danyal Aytekin Nov 13 '11 at 07:45
Temporary because the singleton only exists while your GameWorld exists. It may not be available in your menu screens, for example. "Normal" Singletons are available throughout the lifetime of your app, although strictly speaking that isn't what the pattern is about. – CodeSmile Nov 13 '11 at 22:10

Accessing another class's setter method

3 Answers3