Once And Only Once Does Not Imply Golden Hammer

This page is created in order to counteract a fallacy being perpetuated by certain individuals... namely, that use of two or more existing mechanisms to do something is a violation of OnceAndOnlyOnce (which, taken to its logical extreme, implies that we should all wield a GoldenHammer). It has been asserted:

• That use of "eval" functionality (executing dynamic strings discovered possibly at runtime, and possibly sucked out of a RelationalDatabase) duplicates the functionality provided by such things as closures and lambdas. (For that matter, what about plain vanilla functions?). {See DynamicStringsVsFunctional}

• Use of data structures which can be simulated (albeat poorly!) with a RelationalDatabase duplicates the functionality provided by a RelationalDatabase. {AreTablesGeneralPurposeStructures}

Unfortunately for Top, that isn't what OnceAndOnlyOnce is about. OnceAndOnlyOnce has to do with avoiding redundancy in what the programmer specifies to the compiler (or interpreter). In the world of databases, it's about keeping your tables in ThirdNormalForm or better. In the world of code, it's about ReFactoring common behavior into classes, generic functions, or other polymorphic language features; it's about not duplicating code (or data) all over the place.

In short, it's about DontRepeatYourself. It's about the new code that you write--programmers are wasting effort (and inviting errors due to inconsistency) if they do the same thing more than once. . It's not about selecting among pre-existing mechanisms, and having to choose only one option. If something already exists, using it is not a violation of OnceAndOnlyOnce, even if its functionality overlaps with something else that already exists.

Now, if the application programmer was engaging in GreenSpunning and inventing his own tools, Top might have a point. But we're not talking about that sort of thing at all; we're discussing the reuse of pre-existing tools and abstractions. And when something already exists, there is no harm in choosing more than one such tool for different parts of a problem. That isn't a violation of OnceAndOnlyOnce; it's just good engineering practice.

Well, OnceAndOnlyOnce can apply to lots of things. It may not always indicate a catastrophic technical failure, but rather a smell. It could be a big smell or a small smell. The simplest-but-powerful tools are tools whose features are generally orthogonal each other. A compact tool kit would not include two hammers of similar size, for example. Databases and "complex data structures" fight over similar territory. So does string substitution and FP concepts such as closures and higher-order-functions. This overlap is not necessarily fatal, but takes points off of the "clean design" category. How many points? Well, that is where the debate lays. The trick is to have a high power-to-feature ratio. Overlaps of the kinds descussed here reduces that ratio. This does not mean that we burn everything with such smells, but rather think long and hard about them. -- top

---

CategoryOnceAndOnlyOnce?, CategoryFactoring?