In a class, the keywords private and public are known as access modifiers and are used to define what parts of a class are visible to code outside of that class. Using public: in a class says “everything from here until the next access modifier is visible”. Using private: “everything from here until the next access modifier is hidden”.
class Sample {
private:
int m_variable1; // private
int m_variable2; // private
public:
int m_variable3; // public
int m_variable4; // public
int m_variable5; // public
private:
int m_variable6; // private
};
If you do not specify an access modifier, the default modifier applied to members of a class is private. So the reason Listing 16.3.3 did not work is because the compiler assumed the variables should be private:
Because the compiler assumed the variables should be private, the code in main (line 10) that tries to access m_x directly results in a compilation error. It is a syntax error for code outside of a class to try to access members of that class that were defined in a private block.
To understand why, we need to remember what object-oriented programming was designed to accomplish. It was designed to help make it easier to write and use code in large programs. Part of how it supports this is by giving us tools to manage the complexity of code.
One form of complexity is the coupling of code. We say that code is tightly coupled when one part depends on all of the details of other parts of the code. Loosely coupled coupled code is the opposite. It is when any given part of the code depends on as few details of other parts as possible.
Say we are working with a Point class. If code outside of the Point class is directly accessing the member variables m_x and m_y, then that code is tightly coupled to the implementation details of the Point class. It depends on knowing that Point stores its data as two double values named m_x and m_y.
First, if we want to change how Point stores its data, we have to find all of the code that is directly accessing m_x and m_y and change that code as well.
Second, the programmer who is working on the code that is using Point objects has to understand all of the details of how Point works. They have to know that Point has member variables named m_x and m_y, what those variables mean, what values are valid for them, etc...
Remember to imagine every object-oriented program as being written by multiple programmers. The programmer who is working on the Point class might be different than the programmer who is working on the code that is using Point objects. By making member variables private, the Point programmer can enforce a boundary between the code that “knows the details” of how Point works and the code that does not know or depend on those details.
It keeps code secret from other programmers and users.
Incorrect! “hiding” is not a great term for what we are really doing. “protecting” might be a better description. The code is still there and can be read by other programmers. They just can’t access it directly.
It makes it easier to change implementation details of a class without breaking code that uses the class.
It allows us to enforce boundaries between code that “knows the details” of a particular type and code that does not know or depend on those details.
