   public vs private c++ questions
  Hey fellow programmers. There's something I have been trying to figure out with learning public vs private. Heres my question...I have my class functions as public and the class members as private. Now since I cant directly access the members, I have to go through the class methods..So if I want to set the armor to my player, I would go..wiz0.setArmor(25)and the function is..void Wizard::SetArmor(int armor){if(armor > 0)mArmor = armor;}Now what if I want to display the amount of armor I have? Would I have to create another separate function to display the armor? I feel like I would have to have two or more functions for each thing I want to do. Why create these extra silly functions just to be able to display the armor amount or the characters name when you could just keep everything as private?  Is keeping functions public and members private really that important?   
  If you go with get/set pairs, you haven't bought yourself much over public variables. However, even in the small snippet of code you posted you've shown some of the benefits. Here, you've made it so that the armour member can never be negative.Is it important? If you want to establish and maintain class invariants it is. If the Wizard class is small, and the armour member private, it should be trivial to guarantee that the Wizard's armour is never negative.If the variable is public, any code that has access to a Wizard instance will need to be checked to make sure the invariant is maintained.Yes, this does mean that you'll have to write more code. On the bright side, they are small and can be easily inlined in the class body to reduce the amount of typing needed.   ;  That is what you should do and it's a total pita, but some days you thank your lucky stars you didn't cop out and just access the variables directly.For example, in 97 million places you read the armour directly from the member and it's all good. Program works fine, but the game is lacking something. After a chat with your designer about why the game feels tedious, you want to add a "blitz attack special berzerker" mode whereby for the first 10 seconds of every minute the armour is trebled if you're carrying the "ankh of ownage" pickup. Who you gonna call?It's just better to write accessors. Delegates are even better, but C++ doesn't have them.   ;  Some people will tell you to use a getter and a setter function and make all variables private.  In my opinion, don't do that.  These are generally the rules I follow:Make a setter if you don't want the variable to be retrievable from outsideMake a getter if you don't want the variable to be altered from outsideMake a setter if the data you pass in has to undergo some calculations or checksOther than that, if you have a variable that needs to be set and retrieved, make it public.   ;  That is what you call encapsulation. When you make use of member functions, you will have less trouble updating the internal implementation of your class. For example, in your current Wizard class, the mArmor member may be moved or changed (say you change the internal representation or concept of 'armor' such that it can no longer be represented by mArmor alone) but the purpose of SetArmor() will still be the same, to set an armor value.   ;  Personally found this particular pattern to be so common that it was worth just creating something along the lines of a 'bounded value' type, then just making the thing public.  So many of my functions were just "assert(x); y = x;", a lot like what you see there.  Things that really were effectively public, but resulted in more typing for me [and I hate things that result in more typing for me].Looked something like this [not complete code, but will express the idea]:template <class T, T lowerBound, T upperBound>class BoundedValue{T value;void SetValue(T v){assert(v >= lowerBound && v <= upperBound);value = v;}public:BoundedValue& operator = (T v){SetValue(v);return *this;}operator T() const{return value;}BoundedValue(T v){SetValue(v);}};Helps out a lot actually in doing bound checking.  Got one for lower/upper bounds too.  Pretty handy thing to have in a tool box.  Real simple too.   ;  The issue is actually one in thinking that you need to expose private variables via get/set methods.You don't. In general an object should operate ON its privates, not outsiders. Now, you have there a wizard, who wears armor of some kind.Why do you have a SetArmor method? "Why, to get the armor class of the character." you say... I say: Why not add the armor to the character...Furthermore, there is no reason why the AC cannot be negative (think of curses and other conditions).Or to give an example:namespace ArmorSlot {enum ArmorSlot {NotWearable,Hand,Wrist,Leg,Chest,Head};}class ArmorPiece {public:ArmorSlot::ArmorSlot GetSlot();int GetAC();};class Character {public:void AddArmorPiece(ArmorPiece const& piece);int GetAC() {int sum = 0;std::for_each(armorPieces.begin(), armorPieces.end(), [&sum](ArmorPiece const& piece) { sum += piece.GetAC(); });return sum;}};;  You're thinking about it in the wrong way.Don't think about "how to access the data".Think about what the object can do.If you're a store clerk, for example, you don't look in peoples' wallets to see how much money they have, or change the amount of money they have to be (whatever it was before) - (whatever the cost is of the thing you're selling). Instead, you ask the person to give you the money, and then you hand over the item.So it is with objects. The reason the wizard has a 'mArmor' value is not so that it can be inspected and changed willy-nilly. Its purpose is to represent how protected the wizard is from attacks.What are the circumstances in which that number changes? It changes when the wizard changes armor (or perhaps clothing, or magical protective items...).So, what the wizard can do is equip and unequip things. Then the armoring can be calculated from whatever the wizard is currently wearing. Instead of calculating this every time something is equipped or unequipped, you can calculate it every time the information is needed (e.g. to figure out the result of an attack).Basically, if you are writing the code properly, as soon as you close Wizard.cpp in your editor, you forget what member variables the Wizard class even has in the first place. And you don't have functions whose purpose is to remind you of those variables, either. You instead have functions whose purpose is to represent what a Wizard logically can do.   