Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Grandfather, I like it. And I'm glad to use classes where I can. However, it seems to me that compartmentalizing off a part of the program into a class doesn't actually help me understand how to better write the necessary functions -- the only difference now is they're "instance methods" and every time they access one of the object's variables they need a "$self->{}" to do it. That is to say, the following two things look quite similar to me:
So, getting back to the original posted question, perhaps I wasn't specific enough. Here's two specific questions:
(1) If you say "yes" to the first one, then what does that buy me? Instead of setting an FSL somewhere, I'm returning values, and so need to create an FSL to hold the value anyway! Ex:
...and now I'm back to my file containing a bunch of FSLs, only now they're scattered around the file (in front of function calls) instead of all listed at the top of the file. (2) If you say yes to the 2nd one: my functions need to know lots of things sometimes. I might have to pass in a bunch of arguments to tell it everything it needs to know. It seems ugly to have a function take more than a few arguments. How do you deal with this situation? In reply to Re^2: What are the core points of good procedural software design? (functions, code structuring)
by Anonymous Monk
|
|