Odtnhj

Given the following class:

class ToggleOutput 

 public:
 uint32_t count;
 ToggleOutput(PARAMETERS) //I've just removed stuff to reduce the code
 
 // The code when setting things up
 

 void Update() // public method to toggle a state
 
 // this method will check if a time period has elapsed
 // if the time period has elapsed, toggle an output
 // Each time the output is toggled on then count gets incremented

 count += 1;
 
;

Later on in the code, several instances of ToggleOutput get created

ToggleOutput outPut_1(PARAMETERS); // Again, PARAMETERS are just the stuff 
ToggleOutput outPut_2(PARAMETERS); // I've cut out for brevity.
ToggleOutput outPut_3(PARAMETERS);
ToggleOutput outPut_4(PARAMETERS); 

during execution, I want to do stuff, based on the value of the class member variable, count. eg

if (outPut_1.count >= SOMEVALUE)
 do_some_stuff();

I have been told that this is not acceptable. To follow the 'tenets of OOP', class methods should be impletmented to interact with class variables from outside of the class, eg the above code would need to become

if (outPut1.getCount() >= SOMEVALUE)

and the class variable count would need to be made private.

Is this true? Or is it acceptable to allow direct access to class variables if required

Or is it acceptable to allow direct access to class variables if required

A lot of research into good software engineering and programmer productivity indicates that it's typically good to hide the details of how something is implemented. If person A writes a class, then s/he has certain assumptions about how the class should work. If person B wants to use the class, then s/he often has different assumptions about how the class should work (especially if person A did not document the code well, or even at all, as is the case all too often). Then person B is likely to misuse the data in the class, which can break how the class methods work, and lead to errors that are difficult to debug, at least for person B.

In addition, by hiding the details of the class implementation, person A has the freedom to complete rework the implementation, perhaps removing the variable count and replacing it with something else. This can occur because person A figures out a better way to implement count, or because count was in there only as a debugging tool and is not necessary to the actual working of ToggleOutput, etc.

Programmers don't write code only for themselves. In general, they write code for other people, that will be maintained for other people. "Other people" includes you five years from now, when you look at how you implemented something and ask yourself, What on earth was I thinking? By keeping the details of the implementation hidden (including data) you have the freedom to change that, and client classes/software don't need to worry about it as long as the interface remains the same.

Basically, member access is a rule you impose to the developers.

It's something you put in place to prevent yourself or another developer using your class from modifying properties that are supposed to be managed only by the class itself and nobody else.

It has nothing to do with security (well, not necessarily anyway), it's more a matter of semantics. If it's not supposed to be modified externally, it should be private.

And why should you care? Well, it helps you keep your code coherent and organized, which is specially important if you are working with a development team or with code that you intent to distribute.

And if you have to document your class, you only have to do so for stuff that is public, as far as the class user is concerned nothing else matters.