Software design is often about finding the correct balance between the available implementation methods. Trading memory for time (low-mem/slow recalculation vs

Software design is often about finding the correct balance between the available implementation methods. Trading memory for time (low-mem/slow recalculation vs higher-mem/fast precomputed-table) is the usual example. Software design involves a similar trade-off where simple (but repetitive) code can be traded for a smaller (and maybe more complex abstraction). It's not about "cleverness" (though that can be a strong warning sign), but instead if the abstraction involved is correct, useful, and appropriate. > My code in Listing 4 is not based on those assumptions. Yes. It's based on the new assumption that it might be necessary to "add that pair to the list of cases" in the future. > I choose not to read into requirements more than needed. Except for the new abstraction that attempts to allow for other word replacements not mentioned in the original specification. While I agree that hard-coding assumptions is usually a bad idea, soft-coding[1] can also be a problem. > FP > OO That's the Expression Problem[2], which always involves yet another trade-off. Some types of modifications are easier under FP, others are easier under OO. [1] http://thedailywtf.com/articles/Soft_Coding http://thedailywtf.com/articles/Soft_Coding [2] http://c2.com/cgi/wiki?ExpressionProblem http://c2.com/cgi/wiki?ExpressionProblem