   Accessors of a class within a class
  Hiwell, the subject says it all.  If my class GAME (instance myGame) has a private class army (instance myArmy), it seems I can't get at it's accessors via the army accessor:myGame.myArmy.getMapX()as the compiler says, this is because I'm trying to access a private member.  So should I make myArmy a public member, and rely on its own encapsulation to keep it safe?  I get the feeling this would work but be a bad habit to pick up...   
  You'll probably need just one more getter to get the private army instance:myGame.getArmy().getMapX();Edit: I don't fancy classes having too many getters and setters, though. If the class has a complicated internal state, it should provide methods that would work more automatically (without passing every detail of the state outside and expecting outside code to manage the object), or it just holds some simple data (e.g a pair of coordinates) in which case there is no great need to hide the data at all.[Edited by - visitor on September 12, 2007 1:24:52 AM];  the army class could have a get member which then calls the army accessor:MapX Game::getArmyMapX(){ return myArmy.getMapX(); };   ;  Just make myGame.army public since it is already encapsulated. Accessors that call accessors just to get a simple XYZ value is worse than having 0 encapsulation imho, from both a readability and performance standpoint.   ;  To phrase the problem in a different way: why does the calling code only have access to a Game instance? Can it not take a direct reference to an Army instance instead/aswell?   ;  It's because your army is defined as private. Any variables declared as private cannot be directly accessed from outside of the class. You either need to create  a get method as described above or make your army a public variable.   ;Quote:Original post by shotgunnutterthe army class could have a get member which then calls the army accessor:MapX Game::getArmyMapX(){ return myArmy.getMapX(); };MapX &Game::getArmyMapX(){ return myArmy.getMapX(); };Note the &.Quote:So should I make myArmy a public member, and rely on its own encapsulation to keep it safe? I get the feeling this would work but be a bad habit to pick up...Yes it is.What you'll almost certainly want, is to pass whatever you want to do to myGame, and let myGame perform the actions on myArmy.class MyGame{public:  void fight( Foo &attacker, Bar &defender ) {    x = myArmy.getMapX();    y = myArmy.getMapX();    // do rest of stuff with myArmy.  }private:  MyArmy myArmy;};  I had a little fiddle while waiting for your replies (that's what I generally do.: get stuck, post, keep fiddling, check back after a day or so) and ended up changing the ARMY inside GAME to a pointer to an army, which will probably work better since there will be a varying amount of them in future (I'll have to brave vector.h to get that sorted - wish me luck).That meant I could get at what I needed another way:game.getArmy()->getMapX()Which protected my encapsulation.Just checking that's a reasonable thing to do..?   ;  Assuming you found you needed a pointer because otherwise Game::getArmy would return a copy... that's not needed, because references provide a cleaner syntax.I wonder, however, what exactly is there outside Game that is controlling (individual members of) armies inside Game. I think encapsulation is not so much about declaring members private and then granting everybody access to them via getters/setters so that the implementation of the class's functionality ends up outside of it, but rather about a class providing an interface for its functionality and doing (most) work internally as a black box (you don't even need to know what members it has, as is not quite the case with getters/setters).   ;Quote:Original post by tonywattsI had a little fiddle while waiting for your replies (that's what I generally do.: get stuck, post, keep fiddling, check back after a day or so) and ended up changing the ARMY inside GAME to a pointer to an army, which will probably work better since there will be a varying amount of them in future (I'll have to brave vector.h to get that sorted - wish me luck).That meant I could get at what I needed another way:*** Source Snippet Removed ***Which protected my encapsulation.Just checking that's a reasonable thing to do..?It is almost exactly the same as what you were doing before. Can you please describe fully what you need the map x value for? Especially since you will be replacing the single instance with a collection at some time, this will have to change.A couple of examples of "things you might be doing" that come to my mind are rendering, collision detection, picking (selecting an army using the mouse maybe) or game logic (hopefully not something like myArmy.setMapX(myArmy.getMapX() + 1) [smile]).I still think that the calling code could either be passed a reference to the army instance, or possibly could use a functor passed to the collection in some form to iterate over the available army instances, to do whatever it needs to do.There is an analogy between toys and objects that some find useful:Quote:Source.    * You can play with yourself.    * You can play with your own toys (but you can't take them apart),    * You can play with toys that were given to you.    * And you can play with toys you've made yourself.This helps contain the action an object can do. I would say that your current design goes against this and that you should reconsider.But keep in mind that if your game is simple enough, you can get away with a lot without making the source unmaintainable. If this is not the case however, I would change it.   