Real World Benefits of Encapsulation
I, as most if not all of you do, realize that to do any new development and NOT encapsulate my code would border on absurdity and I would be painting myself into a very narrow corner with regard to maintenance and future project expansion. This post, however, is focused on those projects where you are thrown headlong into an existing codebase that is not based, even loosely, on any kind of object oriented principles, has little to no rhyme nor reason to its architecture, and yet you are tasked with making functional modifications to it without breaking it. A little like playing "pick up sticks", right? Good luck with that! But, by leveraging encapsulation, I was able to accomplish just such a task with relative ease.
For those who may not know, encapsulation is a term that means exactly what it says: containment and separation. Remember those plastic easter eggs that you put things inside as a kid? Whatever you put in there, be it a toy, candy, grasshopper, or whatever, immediately became encapsulated, separated from and unaffected by anything outside of itself (barring direct sunlight, but we'll assume your code will never be subjected to that).
It isn't difficult to port such a definition over to the programmer's world, as we soon learn that by encapsulating specific types of functionality, we can re-use and even share code, thus preventing us from having to waste time re-creating work. In the real world, however, as is often the case, theory doesn't always mesh well with reality. Due to time constraints, lack of experience, laziness, or the inability or lack of authority to modify certain aspects of existing codebases, we very often do not implement encapsulation as we could and should. In a recent project of mine involving an older codebase, the absolute benefits of encapsulation became more than apparent, so I thought I would share the experience.
The task was to modify the import process in the administrative area of a large, "pre-Object Oriented" CMS (which was now living on a ColdFusion 7, "Obect Oriented-friendly" server). In order to minimize the invasiveness of the surgery I was about to perform, I wrote a CFC/class to handle all of the major work, the plan being to isolate the individual switch statement in the thousand line template responsible for the old import process and inject my modifications there and there only. The import process was no simple task, either, and it took a LOT of trial and error to get my code solidified to account for all possible anomolies. But, by encapsulating all of the new functionality in a CFC, I was able to write a quick and dirty test template that utilized my CFC to perform the test imports in isolation from the rest of this app, thus ensuring that all of my code mods, hacks, dumps, and random outputs had NO impact whatsoever on the live app. Once I had my test imports running successfully, complete with statistics being compiled and code written to properly output those stats, all I had to do was drop the relevant portions of my test template into the live app, make sure I had a fast and bullet proof rollback strategy in case something went awry (ALWAYS have a rollback strategy...never trust your own code), and run one final test with my CFC implanted in the live app. Yes, the app I had to modify had no test or qa server; I had to operate directly on the live patient, with no anesthetic.
So, even though you may be often called upon to perform mods to existing, older codebases, if the app lives in an environment conducive to Object Oriented approaches (or even if it doesn't! Don't forget about the ability to encapsulate via Includes if you must!), your path of least potential fallout, self-documentation, and future modifications made easy, is to heavily leverage encapsulation.
For those who may not know, encapsulation is a term that means exactly what it says: containment and separation. Remember those plastic easter eggs that you put things inside as a kid? Whatever you put in there, be it a toy, candy, grasshopper, or whatever, immediately became encapsulated, separated from and unaffected by anything outside of itself (barring direct sunlight, but we'll assume your code will never be subjected to that).
It isn't difficult to port such a definition over to the programmer's world, as we soon learn that by encapsulating specific types of functionality, we can re-use and even share code, thus preventing us from having to waste time re-creating work. In the real world, however, as is often the case, theory doesn't always mesh well with reality. Due to time constraints, lack of experience, laziness, or the inability or lack of authority to modify certain aspects of existing codebases, we very often do not implement encapsulation as we could and should. In a recent project of mine involving an older codebase, the absolute benefits of encapsulation became more than apparent, so I thought I would share the experience.
The task was to modify the import process in the administrative area of a large, "pre-Object Oriented" CMS (which was now living on a ColdFusion 7, "Obect Oriented-friendly" server). In order to minimize the invasiveness of the surgery I was about to perform, I wrote a CFC/class to handle all of the major work, the plan being to isolate the individual switch statement in the thousand line template responsible for the old import process and inject my modifications there and there only. The import process was no simple task, either, and it took a LOT of trial and error to get my code solidified to account for all possible anomolies. But, by encapsulating all of the new functionality in a CFC, I was able to write a quick and dirty test template that utilized my CFC to perform the test imports in isolation from the rest of this app, thus ensuring that all of my code mods, hacks, dumps, and random outputs had NO impact whatsoever on the live app. Once I had my test imports running successfully, complete with statistics being compiled and code written to properly output those stats, all I had to do was drop the relevant portions of my test template into the live app, make sure I had a fast and bullet proof rollback strategy in case something went awry (ALWAYS have a rollback strategy...never trust your own code), and run one final test with my CFC implanted in the live app. Yes, the app I had to modify had no test or qa server; I had to operate directly on the live patient, with no anesthetic.
So, even though you may be often called upon to perform mods to existing, older codebases, if the app lives in an environment conducive to Object Oriented approaches (or even if it doesn't! Don't forget about the ability to encapsulate via Includes if you must!), your path of least potential fallout, self-documentation, and future modifications made easy, is to heavily leverage encapsulation.