Re: Mixing OO and DB

From: Robert Martin <>
Date: Sat, 8 Mar 2008 15:59:37 -0600
Message-ID: <2008030815593716807-unclebob_at_objectmentorcom>

On 2008-03-06 01:58:54 -0600, Marshall <> said:

> On Mar 5, 11:32 pm, Robert Martin <> wrote:

>> On 2008-03-05 00:35:16 -0600, Marshall <> said:
>>> On Mar 4, 9:56 pm, Robert Martin <> wrote:
>>>> 1. We don't need a class for each, we need a method for each.
>>> What columns of the Employees table does Employees.find("Bob")
>>> fill in for the Employee class? If the table has ten columns, there
>>> are 1024 possibilities. Which one of them will you pick?
>> Which ever ones we need.  I'm quite certain it will be fewer than 1024.


> Or, we could just use straight SQL and not have to pick. And
> not have to write out all this code. The fact that you might
> not hit the upper bound of 1024 doesn't affect the fact that
> even having to address this issue at all is symptomatic of
> a problem.

So you are saying that it is better to leave complex expressions in place rather than to hide them behind a descriptive name?


>>>> 2. We never need more methods than SQL statements.
>>> If the relationship is so close, then in what sense is any decoupling
>>> taking place?
>> A function has a name.
>> A function can be polymorphically dispatched.

> Oh, so you're going to have to write this plethora of
> methods *many* times each instead of just once.
> I forgot about that point: good one.

I'm going to implement the functions as many times as I need to. That may just be once. More likely I will need test implementations, so many may require two implementations. It's possible that there will be other reasons to provide separate implementations.

The point is, if you need to have the separate implementations, it's better to be able to implement them polymorphically, rather than with flags and if statements.

Robert C. Martin (Uncle Bob)  | email:
Object Mentor Inc.            | blog:
The Agile Transition Experts  | web:
800-338-6716                  |
Received on Sat Mar 08 2008 - 22:59:37 CET

Original text of this message