Data Hiding - A Need To Know Software Approach

Data encapsulation and data hiding are terms for keeping object properties from public consumption.  This concept is an essential part of object-oriented programming.  We need to be able to have internal processes and values that we can change without impacting users.  It also allows us to limit the impact of changes in large systems.  Thus, we will start our OOP season with a look at this somewhat simple concept.

Data Hiding is more than properties.

One important facet of this topic is that we use encapsulation for more than attributes or properties.  That may not be obvious in the frameworks you use.  Therefore, we need to look at these expanded options for encapsulation.  We also can use this as an opportunity for expanding on object-oriented design. The core point I want to make is that a method and a property are rough equivalents in the OOP world.  We (the consumer) make a request, possibly include parameters, and then expect a result.  When we deal with a property, we say, "give me that property."  A method is roughly "give me that calculated value."  Consider the case where there is no calculation required.  Thus, we have the idea of "getters" and "setters."  These are often simple passthrough functions.

Expanding Complexity

Now we have stumbled on why data encapsulation is useful.  Consider an attribute, a date, for example.  There are numerous Date formats and permutations.  We can include a time (or not), consider day or week (or not), and other options.  Thus, a method of getDate() can quickly evolve from returning a string of "Monday" to "2/3/2019" to "2/3/2019 08:33".  While the caller may want to handle those results differently, they do not want to change their code every time you change the underlying data type.  That means you may start with getDate() returning "Monday" and then can later store it as a date and add a getFullDate() method that returns a YYYY-MM-DD format for that same variable.

Data Hiding in Practice

The best way to think about data encapsulation is using a "need to know" approach.  There is no implicit benefit in exposing an implementation detail like a property type or helper method.  Therefore, please do not provide a public interface unless it is needed for consumers.  Otherwise, you are effectively providing users enough rope to hang themselves.  That will lead to them being unhappy when you are forced to change your internal design.