Think about Loose Coupling | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Day 1: There's a driver table that has four columns. (note: that's a lie, but a useful one.) I retrieve rather a lot of data from someplace. It comes in with External Name and Value fields. But we don't want to deal with the 'External_*' values. Instead they need to be translated to their internal equivalents. For instance we could have: and a data row would some in with "GLD_SPT,PX_VALUE" and I need to translate those to "Gold,Price" before sending the data down the pipe line. But I REALLY don't want to be tagging the database for every row as I iterate across the set (which notably does NOT come from a database.) It's remarkably stupid given the volume. No problem, preload. So I preloaded a hash with the following(ish.) and it actually works surprisingly well. For every row of data I get, I smack together a composite key and resolve it to Internal Name. The lookup table is prefetched. All happy nice nice. Day 2: You should've seen this coming because it always happens to you. Yeah ok. But we need Internal_Value now as well....by tomorrow. Ok, "by tomorrow" means add a parallel "%Value_Resolver" with the same composite string key that resolves to Internal_Value. It (of course) prefetches on the same load as the other hash. And... sure. It works. But the whole approach makes me want to disavow it. The right "value" should be a simple list (or sub-hash? seems unnecessary) containing both values. But using a "two strings smacked together" key just seems wrong. I'm just not sure what would ACTUALLY be simpler (for values of 'simpler' approximating "easier for a programmer to understand.") I'm in the peculiar position of being able to spend a (very) little time refactoring this code and cleaning it up a bit. Thoughts? EDIT: Been a while. I forget people can't read my mind for the rest of the context on these things. Hopefully this is a bit more clear. In reply to A question of style: Composite keys to multiple values by Voronich
|
|