more useful options | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
As a firm believer in object-oriented programming, I feel that this is an excellent post. The idea is that you create a module to encapsulate some piece of data and then "hide it" from the user of that module. That module will then be able to maintain and modify that data as per your request through the use of its interface.
I like to think of it this way: Imagine you go to a bakery and there are three doughnuts and you'd like to take two. You have two options: 1. Reach into the display, grab two, and run. (Praying that the baker doesn't have a gun and a military background...) 2. Ask the baker politely for the two doughnuts. The results are much as you'd expect, if you simply grab the doughnuts and run, the baker might lose track of how many doughnuts he was supposed to have...or did have..or will have...or...or...and just shoot himself. Of course, if you ask the baker politely, he can calmly give you the two doughnuts, modify his internal counter, and go on with his baking-filled life. In case you haven't figured it out yet, this sad attempt at an allgory depicts a module (the baker) and a user (you). You can either use the module's interface and ask nicely for what you want, or you can just grab it on your own and pray that the module doesn't crumble before you. Messing with data that's "hidden" is only asking for trouble - just like what Ovid ran into. After all, the data must be hidden for a reason. If the baker doesn't understand your questions (doesn't have the proper interface), you'll just have to build a better baker. ;-) I sure do hope my ramblings make sense to someone... - Sherlock In reply to Re: Thou Shall Not Covet thy Object's Internals
by Sherlock
|
|