Item 22: data members should be declared as private valid C ++ notes

Item 22: data members should be declared as private valid C ++ notes

Item 22: Declare data members private

Data member declarations are private and provide consistent interface syntax, fine-grained access control, easy to maintain unchanged classes, and more flexible implementations of the authors. And we will see,protectedNot comparablepublicMore conducive to encapsulation.

Syntax consistency

You must have encountered such confusion. Should you add parentheses?

Obj. length // or obj. length ()? Obj. size // or obj. size ()?

It is always difficult to remember how to obtain this attribute.getter? Or directly? If we declare all the data as private, we can use brackets in the call syntax.

Access Control

Provide getter and setter for data members to implement more precise data access control, for example, implementing a read-only attribute:

class readOnly{  int data;public:  int get() const { return data; }}

In fact, the concept of accessors (also called attributes) is provided in C #. Each data member can define a set of accessors (including setter and getter ), parentheses are not required for accessors:

Public class readWrite {private string _ Name; public string Name {set {this. _ Name = value;} get {return this. _ Name ;}} ReadWrite rw; // The set Method rw will be called. name = alice;

Maintainability

Encapsulating all the data can facilitate future class maintenance. For example, you can change the internal implementation without affecting existing customers. For exampleSpeedDataCollectionAn average value is required:

class SpeedDataCollection{public:  void add(int speed);  double average() const;};

average()There are two ways to achieve this: Maintain the attribute of the current average, each timeaddThis attribute is adjusted.average(). The choice between the two implementation methods is actually a trade-off between the CPU and memory. If a system with a limited memory, you may need to select the latter, but if you need to call it frequentlyaverage()And the memory is not a problem, you can choose the former.

The change in your implementation method will not affect your customers. However, ifavarage()It is not a method but a common data member. For every change in your implementation method, the customer must re-implement, re-compile, re-debug, and test their code.

Let's take a look at protected.

Since a total of data members will corrupt the encapsulation, its changes will affect the customer code. SoprotectedWhat about it?

The essence of object-oriented is encapsulation. We can roughly think that the encapsulation of a data member is inversely proportional to the number of code that will be destroyed by its changes. For exampleaverageIf it ispublicMember, and its changes will affect all the customer code that used it. The number of them is as large as unknown (unknowably large amount ). If yesprotectedAlthough the customer cannot directly use it, a large number of classes can be defined to inherit from it. Therefore, the number of codes affected by its modifications is also unknowably large.

protectedAndpublicThe encapsulation is the same! If you have written shared or protected data members, you cannot modify them without affecting the customer code!