The Object of My Affection

Return with us now to the thrilling days of yesteryear. If you're old enough, you remember that as the intro to "Lone Ranger" episodes. One might also see that as the devolution of application development. So, here goes.

Recall the Holub Mantra (my description), this "Bank of Allen" tale. The signature observation:

The maintenance manager is happily sleeping in the back office instead of running around changing ROMs.

Holub is talking about regular application development, independent of datastore. But the principle applies in spades to databased applications.

The development of the relational model was driven by maths, specifically predicate logic. It was not, as many infer, data reduction; which does come as part of the package. But the whole point is data integrity. The primary way to ensure data integrity is to limit the number of hands who can mess with it. As Holub points out, if one models an ATM network based on object capabilities, the datastore is the controller of the data. That is how it must be. In time, Holub gave in to the innterTubes meme, alas. That might have been defensible back before highspeed connectivity, but not now.

If there is just one point of control, then there's just that one point of modification and maintenance. That's why the manager doesn't have to run around changing ROMs. But the driving point of object oriented design and programming is that an object encompasses both data and function, aka methods. What has happened, especially in the java world, was the re-invention of the language, called either javBOL or COBava. Same old procedure/data protocol from the 50s. Swell.

Every now and again, one sees a crack in the wall of reactionaries. Here's a recent example. The author doesn't reach the logical end of the argument, but does show more insight than usual.

Too often, though, business logic is built and added late in the process, forcing it into whatever nooks and crannies are available. While this duct-tape approach sometimes works, it makes the resulting system difficult to maintain when the business logic is spread across many moving parts in the data architecture.

The standard response from the COBava folks is, "it's impossible to design an application in the first place, so let's just build it like a Frankenstein monster." Or, parts is parts. Remember, all code logic comes down to data compares. Period.