more useful options | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
You're still violating data-hiding. It took me over a year (and two separate projects) to realize that the method you're using (which I used extensively) isn't OO programming. All you are doing is associating functions with a hash, then unnecessarily abstracting a function call over every access to that hash.
A quick primer on OO ... the idea is that you have these things and each thing can accomplish a certain set of tasks. These task are very abstract, like walk(), dispense_money(), and the like. Then, there is what asks that thing to do whatever. The asker doesn't know nor does he care to know how the thing gets its stuff done. All that matters is results. (In that sense, OO programming could be called "results-driven programming" ...) A human example would be a manager and an employee. Imperative programming would be like having a manager stand over your shoulder and say "Now, press 'N'. Now press 'o'. Now press 'o'. Now press '!'. ...". This is opposed to Object-Oriented programming where the manager says "Get this task done. You have a week. Tell me when you're done." The second manager doesn't know and doesn't care how you get the job done. He just wants to know that the job is done and done well. What does this have to do with your case? Well, I haven't read the code. Frankly, it sounds like you're doing imperative programming in OO-clothing. It feels clunky, doesn't it? Sorta like you're trying to get a square peg in a round hole. Well, rethink what you're doing. Identify the things in your design (you do have a design, right?) and identify what each thing can do. Then, let them go and do their jobs without your meddling interference! :-) ------ Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. In reply to A quick OO primer...
by dragonchild
|
|