Philosophy

[Roedy Green]

I have just rewritten my Arraylist utility Merge class. I noticed
that I had many methods that were all theme and variations. Surely
somewhere in there is a bug that won't surface until an embarrassing
later moment.

Then I remembered my Forth background. You avoid theme and variation
code. You somehow encapsulate it, test the heck out of your tool,
then solve you problem with a high level tool. If a tool is heavily
used in a variety of contexts, bugs will rapidly surface.

So I went back and noticed a general pattern --- the generic ArrayList
combiner. You match two sorted lists then either include or exclude
the matched/unmatched primaries and secondaries.

There are 16 possible combinations of things you might want to do.

Even the true true true true case is useful -- to combine two sorted
lists into one big one more quickly than you could sort the whole
thing.

I gave the common patterns I am using convenience names, like
"allBut", "combine", "update",


Oddly the generic code is actually easier to understand that the
various special cases were. It is certainly easier to proofread.

 

[Chris Uppal]

Oddly the generic code is actually easier to understand that the
various special cases were. It is certainly easier to proofread.

One of the fundamental, but not widely recognised, problem-solving techniques
(in any domain): "generalise the problem, solve that, apply the general
solution to the case at hand".

Or, I think equivalently: when faced with a problem, first build a machine* for
solving problems of that type, then use the machine for the problem you started
with.

There's a danger of it leading to over-engineering, of course, but I think that
much that is good in Computer Science can be seen as an application of the
principle. (Some well-designed [class] libraries, special-purpose scripting
languages, and so on.)

(BTW a still more generic approach to your specific problem would be a
special-purpose Iterator that took two other Iterators as input and wrapped
them in a new Iterator that followed the configured include/exclude rules. Or
maybe it should take a collection of input Iterators... You see what I mean
by over-engineering ;-)

-- chris

[*] "machine" in the loosest possible sense.