I just read Tim Ottinger’s post about Tuple Madness. Coincidentally yesterday afternoon I wondered out loud whether Ruby’s rich collection classes encouraged more than the usual amount of what I call inside-out code – where a client object queries another object for its internal data and manipulates that data into the required form.
This works well in the small, but can quickly lead to similar manipulations happening in multiple client classes. Also unless you’re careful, it can harm readability – e.g. where the meaning of a bit of data depends on its position within an array.
As time marches on, I feel more and more like a bear of very little brain who can keep less and less code in his head at any one time. As a defence against this I try to…
- write or extract small classes with clear and simple responsibilities
- limit low-level access to the internal data of the class
- write simple unit tests clearly expressing the intent of the code.
I hope these tactics don’t just help me, but help other developers who later need to understand and modify the code I’ve written.
Tim has a nice summary…
I don’t think that “magic tuples” are always evil, only that they’re no substitute for proper objects and meaningful data structures.