Data Hiding - Practical Accessors

We have discussed the accessor levels of our data.  In most environments, the three levels are public, protected, and private.  In this episode, we go deeper into these concepts and a practical approach to data hiding.

The Private Access Level

This level of access should be our default.  It can be considered the critical step in data hiding.  Private hides our data and methods.  I find a physical example often works best for the goal of this approach.  When we purchase a physical device, we prefer fewer buttons and interface widgets over more.  The Apple iPod was a perfect example of this.  There were very few controls, so the interface was easy to understand.  Our software should follow the same principle of less is more.  When we do so, we keep things simple and avoid paralysis from providing too many options.

Protected Access

A well-designed object-oriented system will have helpers and relationships among objects.  Therefore, it requires an object to be able to modify values or have access to internal methods directly.  These are often "administrative" actions that we do not need to provide to the general public.  However, they are needed for classes to embrace all that their definition requires. 

This situation most often shows up in inherited classes.  An object that is a subtype will still need to access core items.  This does not require a change to attributes.  We can keep those private while providing protected access via methods.  That is often the better approach as it allows us to make sweeping changes to a system via core classes without rewriting the children and helpers.

No Data Hiding - Public Access

The most open level of access is public.  This should be rare in most systems and well-defined.  A user should be able to understand the direct and ancillary impact of calling a public method.  Likewise, it should rarely have anything other than a direct impact on an object.  The simple interface is always the best approach.