Valid tive C ++: Clause 22: declare member variables as private

(1) Why not use public member variables?

(1) first, from the perspective of syntax consistency, the only way the customer can access the object is through the member function, and the customer does not have to consider whether to remember to use parentheses ().

(2) second, using functions gives us more precise control over the handling of member variables. If we make the member variable public, everyone can read and write it!

However, if we use a function to obtain or set its value, we can implement "no access", "read-only access", and "read/write access ", we can even implement "Write-only access ".

Class AccessLevels {public: // member noAccess does not have any access action, so access is not allowed! Int getReadOnlay () const {return readOnly;} // set this data member to read-only access! Void setReadWrite (int value) {readWrite = value;} // This function sets write access for this data member! Int getReadWrite () const {return readWrite;} // This function sets readable access for this data member! Void setWriteOnly (int value) {writeOnly = value;} // This function sets write access for this data member! Private: int noAccess; int readOnly; int readWrite; int writeOnly ;};

It is quite necessary to divide access control in such a way, because many member variables should be hidden. Every member variable requires a getter function and a setter function.

(3) encapsulation. If you use a function to access a member variable, you can replace the member variable with a calculation later. The customer does not know that the internal implementation of the class has changed.

Member variables are hidden behind function interfaces and can provide elasticity for "all possible implementations. For example, this can easily notify other objects when member variables are read or written, verify the constraints of the class and the prerequisite and post-event status of the function, and execute synchronization control in a multi-threaded environment. .. And so on.

Encapsulation is very important. If the customer hides the member variable (that is,) encapsulation, it reserves the right to implement future changes. Public means no encapsulation. No encapsulation means no change.

(2)

Protected member variables lack encapsulation like public member variables: The encapsulation of member variables is inversely proportional to the number of code destroyed when the content of member variables changes, assume that a public member variable is removed. All customer codes that use it will be damaged, which is an unknown large number. Therefore, public member functions are completely unencapsulated. Suppose a protected member variable, we cancel it, and all the derived classes that use it will be destroyed, which is often an unknown large number.

Remember:

(1) Remember to declare the member variables as private. This allows the customer to access data consistency, subscribe to access control, promise constraints to be guaranteed, and provide class authors for full elasticity.
(2) protected is not more encapsulated than public.