Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)


Robert Martin wrote:
On 2006-05-30 04:09:34 -0500, frebe73@xxxxxxxxx said:

The problem is that some persons here are truly hard-core RDBMS
fanatics and and absolutely unable to understand that there's a life
outside RDBMS. RDBMS are really great for some things, and just suck for
some other things.

Maybe the problem also is that some persons here are truly hard-core OO
fanatics and absolutely unable to understand that there's a life
outside OO. OO are really great for some things, and just suck for some
other things.

I won't argue that OO has not been over-hyped. Certainly it has.
However, the principles of OO design are really just principles of good
software design. OO langauges simply gives us some good tools to help
us managine coupling and cohesion better.

I have not found a way to use "coupling and cohesion" as an objective
metric. It seems to depend on one's personal, internal view of
software, change-patterns, and life rather than a "hard" metric that
settles debates like these. My C&C complaints can be found at:

http://c2.com/cgi/wiki?CouplingAndCohesion


I have certainly found systems that should NEVER use an RDBMS. But I
have never found a system that could not benefit from a good OO
language.

A good OO designer is not a fanatic about OO, S/he is a disciplined
software designer that is able to use the tools of OO.

A good software designer can use both OO and RDB tools as, and when,
needed. However, RDB tools are mechanisms that can be deferred both in
time and space to be considered later and partitioned into a small
segment of the code. OO tools are used throughout the design and
implementation process and cannot be deferred either in time or space.

This sounds like the "RDBMS is a low-level tool/service" argument. I
have to disagree. One can treat it merely as a filing system, but can
also treat it as a sophisticated modeling tool.

In declarative programming the implementation is what is considered
"low level", not the other way around. One can create a kind of domain-
or app-specific declarative "language" of a sort with tables (or at
least attributes).

For an analogy, consider a programming language interpreter. It takes
your input file and turns it into a data structure, and then operates
on the attributes in that data structure. The implementation can be
considered lower-level detail. A data structure may have an Add
operation and two numeric operands hanging off of it. We don't have to
worry much about how Add is implemented when looking at this data
structure, we just concentrate on the fact that it is an Add node.

Declarative programming is kind of like that: you focus on what
attributes you fill in or create to have an activity carried out rather
than on how it is carried out. Some have characterized it as "turning
programming into data entry", which has some truth to it.

Now I agree that many existing tools and vendors don't make this very
easy to do, and it is not taught as a technique. The vendors tilt
toward behavior-oriented solutions that OO encourages or the "big-iron"
Oracle view of DBs such that declarative (data-centric) modeling is a
bit tough to do in the current environment.

I won't claim that declarative approaches based on tables are
objectively better than the behavioral tilt of OOP. They both "run". I
just know that they fit the way I think better. I can sift and change
presentation of declarative info much easier than I can with behavioral
code. It is tough to "query" programming code.

And, relational seems to offer more consistency. OOP results in
"structures" that are not significantly different from the 1960's
navigational structuring messes that motivated Dr. Codd to invent
relational. Navigational is the Go To of structuring in my opinion. If
there is a consistent pattern that helps one think and reason about OO,
nobody has documented it, at least not with a consensus.

Relational is based on set theory, OOP on hierarchies and pointers. In
my book, sets win because hierarchies don't fit real world change well,
and pointers have no known discipline to them. "GOF Patterns" have been
one suggestion, but there is little consistent guidence about where and
when to use them. In relational thinking patterns tend to be a specific
viewpoint, not a thing you hard-wire into code or software.
Normalization rules tend to dictate the shape of things and less so the
whims of designers.




--
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx

-T-

.

Relevant Pages

  • Re: Forth and OO design?
    ... Jeff M. wrote: ... Good OO programming is the most resilient of all methodologies. ... The data structure midi-event was right in the middle. ... what is the most central object in your design? ...
    (comp.lang.forth)
  • Re: mfc pitfalls
    ... In most MFC apps, you are writing code in that kind ... virtual methods usually work better than callbacks for most ... no syntax in the design for function pointers. ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)
  • Re: mfc pitfalls
    ... I see no callbacks in MFC. ... but I see no callbacks. ... premises of one of them as a basis of design or implementation in one of the others. ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)
  • Re: SENIOR A.I. SOFTWARE ENGINEER POSITION - $90-120K - Dallas
    ... May design and build prototype applications. ... Expert C and C++ programming experience. ... Java / J2EE Architecture ... Understands standard software modeling techniques ...
    (comp.ai.philosophy)
  • Re: mfc pitfalls
    ... There are design criteria, ... Data flow (flowcharts) is one of the UML diagrams ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)