It does sound like you've made it overly complex. Obviously, the idea is not really "there is a variable named totalSave
" since the user could care less about where you store it, and from the rest of your post, you actually don't care about how you store it.
That said, in order to make this a bit more concrete, let's think about a "total score" state that numerous parts of the program might add to. There are a couple of approaches you might take. In any case, you likely have some object somewhere that is keeping track of the score. We'll call it the Game
object, but it could be a Level
or whatever.
So there are three big schools of thought: you can pass this Game
object around to everyone, you can have a Game
singleton, or you can use notifications. Each of these approaches has advantages, and any one you pick is probably fine for a simple program (personally, for a very simple program, I'd use a singleton).
In the first scheme, at some point in the program you create a Game
object that has some addToScore:
method. You assign this object as a property on every other object that needs to update the score. Each of those calls [self.game addToScore:value]
. This approach makes unit testing a bit simpler, but can be a bit tedious to implement.
In the second scheme, you have some shared singleton +[Game sharedGame]
. When you want to update the score, call [[Game sharedGame] addToScore:value]
. This is generally the easiet to implement.
In the third scheme, you have some object (Game
) that uses NSNotificationCenter
to observe some notification. When you want to update the score, you just post a notification that includes the amount to add in its user dictionary. This is great for keeping things extremely decoupled, but again can be a little tedious in the more usual case.
But as @Chuck notes, you're probably over-thinking this, and you may want to go back and work through some of the tutorials to get a better sense of how these things usually work. The kind of situation you're describing is not very complicated.