Think of a Person class. You may want to have the persons date of birth (DoB) in the class. This DoB should not be changeable from the outside of the object but is required to calculate the current age of the person when asked.
A class is a 'blueprint' for an object, the actual member data is associated with the object.
Person Lorence30(/* parameters including DoB */)
I now have a Lorence30 object. If the DoB was public anyone could change the value for that object. This is not a very good situation as I should not be able to change your DoB.
It's like you have something in your mind, some of that you can tell the others but some you don't.
OOP is likely object in real world. They have their data, but they'll decide that which one they're gonna tell the world to know.
Do you think you can pick memory from your friend by yourself?
Concept.
Something you can spot like skin, face, etc. Like public variables in class that defined. the others you have to use their method(to tell you) to know it.
And you might not want the other to change yours.
It primarily comes down to "encapsulation". Essentially, "You should only access what you need".
Imagine you have a coffee machine, now a coffee machine is quite abstract and all YOU know is that you press a button and you get some coffee, right? The inner workings of the machine is hidden/private to you because you don't need to know how the coffee machine works, for you to get some coffee.
It's the integrity protection of data. Why would the coffee maker designers give you access to inner workings of the coffee machine when YOU don't need to access it, it's not a requirement to use the machine. If you COULD access the inner workings, you may accidentally change something and break the coffee machine. It's the exact same with code, you need to protect some data from accidental modification.
It's like all the inner parts of the machine are "private" but the coffee button is "public".
Do you think you can pick memory from your friend by yourself?
Concept.
I thought that's what friends are for.
Grey Wolf wrote:
Person Lorence30(/* parameters including DoB */)
I now have a Lorence30 object. If the DoB was public anyone could change the value for that object. This is not a very good situation as I should not be able to change your DoB.
Note that private/public applies to classes, not objects. One instance of Person could modify the DoB of another instance of Person even if DoB is private.
@grey wolf ah I get it now I just thought that im the only one who will use.my own program..but youre telling me tthat the user might changed that public class which is supposed to be private..
To take the date of birth example a little further, consider that dob could be stored as a julian date or as year, month and day int values, a struct, or even as an object of a DATE class. The other parts of your program don't need to know or care how you choose to implement dob in your person class. That's why it should be private. You make access to dob available through public getter and setter functions.
This makes maintenance of your program easier. If you decide to change how dob is stored, only the internals of the getter and setter need to change. You don't have to go looking through your entire program to find every reference to dob. As Sausage said. this is what encapsulation is about.
For example, your person class can have a bool person::set_dob (int year, int month, int day)
function. It the responsibility of the setter function to edit the arguments to make sure that the dob object inside the person class is valid. i.e. If you try and call the setter with a month of 13, set_dob will return false indicating the call failed and dob was not changed.
Note that this setter for dob does not assume any particular internal representation. It simply provides a suitable interface for setting dob.