Re: Object equals Relation

>
> Have you read the third manifesto? A must-read on this subject, but
> hardly the last word -- the authors are too lacking in practical
> knowledge of OO languages to finish the matter. (Several cases of "OO
> cannot do this" claims which are easily rebutted with "can do and do
> quite easily with a good OO language".).

I don't really question the idea that relational and OO can be merged (somehow). It is not a matter of what OO and relational *can* do, but is about providing specific and consistent roles.

The "elements" of tables are "instantly readable" items such as numbers, strings, and dates. No funny binary gunk or goofy protocol references, etc. (Sure, you can do that, but it starts to work against the model's power if you get carried away.)

Some might say these are "limitations". However, sticking with the rules provides a certain rigor and consistency. I compare it to the difference between Goto's and nested blocks (AKA, "structured"). Goto's are clearly a superset of nested blocks since you can emulate nested blocks with them if you stick to certain patterns. However, there is more consistency and predictability between developers with nested blocks. Thus, limits are not necessarily a "bad" things. There must be some common and consistent "check-points" which things must pass through under pre-defined conditions, or you end up with a mess.

This is what I find with OO designs: no consistency between developers and no "checkpoints" of communication or interfaces on a larger scale. OO designs are just a huge glob of nodes (classes) with complex relationships that must be understood one-at-a-time. An ER graph is made up of relatively *simple* things: tables with columns. Yet simple things can be combined to create complex relationships using a compact and consistent rigor: relational algebra. Compare this with the roll-your-own relationship managers common in OO. It heavily reminds me of the roll-your-own flow protocols of the Goto days (which I witnessed the tail end of).

GOF patterns are similar to "conventions" that one may use to organize Goto's. I tended to develop certain Goto patterns to keep my sanity back then. I am surprised books didn't come out with names like "Patterns of Flow Control with Goto's", by the Gang of Five.

Nobody has been able to describe the "benefits" of nested blocks with rigorous mathematical precision after all these years. It generally appears to be about psychology. Inter-developer consistency is the best way I have found to describe the benefits.

I outlined my general approach to developing applications in my "3-graph model" write-up. In about 5 pages I describe the high-level approach I use for almost every project. Although there may be minor disagreements among p/r practicioners (such as how to represent 1-to-zero-or-1 relationships), most non-OO designs I encounter fit the same pattern that I outlined. I can walk into many p/r shops, study the schema, look at a list of major task modules, and have a reasonably good feel for what is going on in a few hours.

There appears to be nothing equivalent to it in the OO world. The closest I have seen fits with the "self-handling nouns" (SHN) of Simula tradition. However, this model is insufficient for my domain because of its limited multi-perspective techniques and dynamic (frequently changing) noun participation in business rules. Beyond SHN, there is no consistency in the OO world. Every self-proclaimed OO guru has *different* techniques, the same way that every Goto "expert" had their own little flow patterns and techniques.

Patterns are often a symptom, not a solution, just like the Goto days. They are an (futile) attempt to reign in run-away complexity.

The organizational techniques beyond (above) the class granularity is hardly more well documented and agreed upon than Goto patterns.

-T-
oop.ismad.com
http://geocities.com/tablizer/bizmod.htm (3-graph model) Received on Thu Jun 13 2002 - 18:05:13 CEST