[EMAIL PROTECTED] wrote:
Wise OOP design is how I'd handle all that state. Then I'd go back
to writing nice little methods for my classes. :)
It seems rather a waste to create an entire class that you only
instantiate and invoke in one place, just to hold the state that used to
be in local variables. That wouldn't really seem to clarify anything to
me, honestly.
When the state actually has some independent meaning, sure, that makes
sense. Nowadays, I tend to have a whole lot of functions like
newHashtable = do_the_next_step(currentHashtable);
But when you start getting into complex SQL querying code, neither the
SQL nor the code that handles it tends to break down into convenient
chunks of functionality.
When the spec is "iterate over this directory tree, and for all the
files not marked bad, extract the headers, insert the headers into a
'headers' table if they're not already there or give me back the row of
the table the headers are in if they are already there, then insert the
body and indicate which header it went with, incrementing the count on
the appropriate header, and if the body conversion failed or you read
back the body and it isn't the same, mark the original file as bad,
otherwise move it to a new directory, keeping track of the number of new
headers, body, failed files, and already-seen files and heaers for
reporting", there isn't really a good OO type of breakdown there. To the
extent there is, you wind up multiplying the number of SQL queries by
some factor to account for it.
I don't see that turning that into a class that's only used in that one
routine is more clear than
foreach file $files {
# Extract the headers
...
# See if the headers are already there
... If so, increment seen_headers
# If not, insert them
... increment new_headers
And so on.
}
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
