Data hiding is part of the process of removing complexity from programs.
Any program in a business environment that does anything useful, can easily have 500 lines to 20 thousand lines of code. This means things can get complex real fast.
Without using sound engineering principles most programs would become unmanageable.
Data hiding is the term used for one of the good habits that ensure that it is easier for a human being, to change and amend and support, and most importantly understand complex programming code.
Data hiding is “management by exception” for programmers,it allows us to only focus on and find, the area of the code that we wish to review.
This is not some esoteric principle that is only useful to engineers. Business programmers, macro writers and all programmers can benefit from it.
For example an accounting consolidation macro will be more useful flexible and get more done if the macro writer employs this technique.
If you don’t employ this technique your macros and programs will be unstable, your code will also be very hard to maintain, and most likely when you leave your department or organisation your program will cease to be used because it will be too difficult to maintain. Not great for the cv don’t you think?
If you do use this technique you will justifiably feel proud because you have written some awesome applications which deliver business value and will continue to be used in the business for a very long time giving you Kudos 😉
Data Hiding In Practice.
- Break you program down into chunks ordered by the activity each part of the code is processing. For example in a complex excel macro an activity might be . . .
(a) See if a certain Word document is available.(b) If so then launch Microsoft Word.(c) If Word opened Ok then get Word to open specified Word document.(e) Process Word document.
(f) Save and close word document
(g) Close Microsoft Word and return control to Microsoft Excel.
- The above items (a) through (g) would then be placed in their own subroutine. This subroutine or function could for example be called ProcessWordDocument. This immediately makes the code much clear to read as now 20 lines or so of detail have been replaced by just one line in the calling document called “ProcessWordDocument”.
- Now look at all the variables that are used within this routine. If any of those variables are only used within the routine and nowhere else then make them private to that routine so they cannot be seen by any other part of the program. This is as important as the previous step. This protects you from the spaghetti code problem where making a change in one part of the program breaks something else in another part of the program.
- Now look at the variables that are used within this routine which are also used elsewhere in the program, what you must now do and this is valid for 9 out of 10 situations or more is take these variables and pass them as arguments to the subroutine or function.
Congratulations you have now employed “Data Hiding” in your program.
You have a routine with a descriptive name, you know what the inputs to the routine are (The argument list), you know what it’s local variables are (they are declared within the routine),
and most importantly you can make changes within the routine with confidence that you are not going to break another part of the program. If you have any questions or if I need to explain part of this better please leave a comment to help me to improve this and future articles.
Chris Zarebski says
Extremely useful information containing very clear guidance on data hiding in practice.
Seems applicable to both waterfall and Agile techniques.
Chris Brown says
Thanks.
When would I use public instead of passing as an argument?
Sean Johnson says
Hi Chris
Always pass an argument whenever possible, I use public for the name of the application, Custom Error messages and in some cases an object when it needs to be kept “live” regardless of whether code is running at that particular moment.
Think pressing various buttons to kick off Excel routines, but you want a particular object to hold all it’s settings.
But for all other cases keep them local and pass arguments.