By Sean Johnson on January 9, 2012
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.