From: topmind on

On Jan 25, 4:49 pm, Robert Martin <uncle...(a)> wrote:
> On 2007-01-23 23:04:15 -0600, "topmind" <topm...(a)> said:
> >> One way is not better than the other; but BOTH ways are better than just one.
> > But there are no clear, consensus criteria for when to use one over the
> > other.
> You don't use one OVER the other, you use the two to complement each other.

OO does not compliment relational. Trivial OO is simpler redone as
procedural instead, and complex OO is best moved to tables to manage
the interelationships of structures and ideas and domain noun
classification systems.

> > People's selection seems to be a personal preference.
> Actually, there is a rather large body of knowledge published about how
> to use the two together. Consider, for example, Fowler's "Patterns of
> Enterprise Application Architecture" for starters.

I have looked at Fowler's works, and found a lot of suspicous designs.
He hates RDBMS almost as much as you. If you found a sure-shot example,
please bring it up.

> You may be vocal [....] but you are in a profoundly parochial minority.

1. Being popular is not the same as being good. Examples bound (cough
M1crosoft cough). Another example: Hard-core OO fans tend to prefer
Smalltalk over Java and Python, but popularity does not agree.

2. OO gets a lot more LIP SERVICE than actual use. A good many OO
proponents complain that a lot of production Java code is "procedural
cross-dressing as OO". OO is kind of like vegatibles: the doctors keep
saying they are good for you and one will claim to eat them, but most
ignore them in practice. (The analogy ends there: unlike OO, vegitables
are good for you.)

> --
> Robert C. Martin (Uncle Bob) | email: uncle...(a)


From: topmind on

Robert Martin wrote:
> On 2007-01-24 06:10:30 -0600, frebe73(a) said:

> (sigh). *information* hiding means hiding the *implementation* of data
> and behavior. BTW, I think "information hiding" was coined by Dave
> Parnas in 1971 long before OO was popular.
> (

Again again again, a RDMBS is *not* an "implementation" anymore than
Java or C# is. You OO'ers keep claiming that RDBMS are "only low-level
persistence", but it is simply not the case. Maybe to OO programs they
are because OO programs want to take structure-handling work away from
the database and reinvent it themselves (in an inconsistent and 60's
zombie navigational pointer-like way.)

> --
> Robert C. Martin (Uncle Bob) | email: unclebob(a)


From: Patrick May on
"topmind" <topmind(a)> writes:
> On Jan 23, 2:38 pm, Robert Martin <uncle...(a)> wrote:
>> Very little "additional" code. Indeed, it might even be less code
>> since all the SQL is concentrated in one place rather than spread
>> out and duplicated.
> Where have I proposed duplicating SQL? One can put it into shared
> functions, or perhaps use DB views. I still claim a p/r version
> would be significantly less code. I suppose I'll have to code it up
> to prove it to you.

I, for one, would be very interested in seeing this. It would
clarify a lot of the discussion points. If you do provide such code,
please recognize that using Open Source or otherwise readily available
languages and RDBMSs will be much more useful than implementing in a
proprietary environment.

I look forward to seeing your implementation.



S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm(a) | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Robert Martin on
On 2007-01-25 22:23:23 -0600, JXStern <JXSternChangeX2R(a)> said:

> On Tue, 23 Jan 2007 15:43:12 -0600, Robert Martin
> <unclebob(a)> wrote:
>>> I deny any such claim even makes sense, other than making Agile a
>>> wrapper you can throw anything at all into.
>> My point was that "Agile" makes no judgements on whether a parcticular
>> tool is "good" or "bad" (i.e. pro/con). Rather it makes judgements
>> about how and when tools should be used.
> I deny that it makes even a little bit of sense to say that Agile
> offers any judgement on when and whether to use RDBMS. You're
> overloading the term "Agile" to link unrelated advice in random
> directions.

Not at all. One of the fundamental rules of Agile is YAGNI, "You
Aren't Going to Need It." In short, this rule says that you should not
include support for something just because you think you are going to
need it. Only provide support for what you need right now.

We used this advice in the development of FitNesse (
Early on we were pretty sure we'd need some kind of database; but since
the early features of the system didn't require persitence, we didn't
select or implement a database.

Later in the development we started needing the ability for simple
queries, but we still didn't need persistence. Since the queries were
simple (just name lookups) we created a data lookup interface and
implemented it with a hashmap.

Still later we started needing longer term persistence, but nothing
very elaborate, so we reimplemented the data lookup interface with a
flat file system.

We've never needed anything more than that. We didn't know this when
we started. We thought we'd need an RDBMS back end; but that just
never turned out to be the case.

I have also written other applications in which the decision to go to
an RDBMS was made very early, because the features clearly required it.
Not features for the future, but features for right now.

So, Agile DOES provide guidance about when and where to use tools like RDMBSs.

Robert C. Martin (Uncle Bob)��| email: unclebob(a)
Object Mentor Inc.� � � � � ��| blog:��
The Agile Transition Experts��| web:���
800-338-6716� � � � � � � � ��|

From: Robert Martin on
On 2007-01-25 22:42:58 -0600, "topmind" <topmind(a)> said:

> At least I entertain the possibility that tables are a subjective
> preference.

Then you should also entertain the possibility that objects and RDBs
can be used synergistically.

Robert C. Martin (Uncle Bob)��| email: unclebob(a)
Object Mentor Inc.� � � � � ��| blog:��
The Agile Transition Experts��| web:���
800-338-6716� � � � � � � � ��|