3.2 Direct data member access?

Although you can access public data members in C++, it is now considered a bad practice to permit direct access to a data member from an ADT perspective. There are several reasons for this argument.

In our example, let's say that in the first implementation, the password is only used when a student record is in use. Consequently, it seems to make sense to make password just a data member of the ADT Student. Any code that wants to read and rewrite the password can do so using string functions.

To be more exact, this is the first implementation attempt:

 // the following belongs to a .h file
struct Student
{
  // ...
  char password[20];
  // ...
};

// the following belongs to the "user" code:

// ...
  struct Student s;

  // ...
  strncpy(s.password, newpasswd, sizeof(s.password));
  // ...

Using this approach, direct access to data member password can be scattered all over the place, with calls to string functions to access the data member.

What if we want the password to be maintained by a system-wide password management method, like the Linux password file (assume each student has an account in the system). This proposed change means the following:

there is no need to maintain the password as a part of a student record
when a password is changed, the command passwd should be called
in order to match an input string with a password, another command should be called

In other words, all the direct access to data member password need to be changed! The means massive changes to the program that can lead to lots of potential problems.

What is the solution to this problem?

Never permit direct data member access to begin with. Even for something as simple as firstname and lastname, define operations like ``set firstname'' and ``get firstname''. This way, if we do want to change how the attributes are stored, there will be no impact to the rest of the program.

The conclusion is to use ``get...'' and ``set...' operations to handle even the most innocent looking data members.