Re: Mixing OO and DB

On Mar 4, 9:56 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
> On 2008-03-04 14:01:56 -0600, Marshall <marshall.spi..._at_gmail.com> said:
>
>
>
> > On Mar 4, 10:10 am, Gene Wirchenko <ge..._at_ocis.net> wrote:
> >> Robert Martin <uncle..._at_objectmentor.com> wrote:
>
> >>> get_accountant("Bob");
> >>> or
> >>> find_by_name_and_department("Bob", "Accounting");
>
> >>> I'm sure you can think of some others that would read nicer than the SQL.
>
> >> Now throw another column into the mix. How many methods are you
> >> going to end up with? What will you have gained?
>
> > Nice point.
>
> > Now let's consider what all the combinations are. If we have
> > a single table with ten columns, then we have 1024 possible
> > column lists, so if we want a class for each such we need
> > a thousand classes.
>
> Two points.
>
> 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?

> 2. We never need more methods than SQL statements.

If the relationship is so close, then in what sense is any decoupling taking place? Every new thing you want to do means a new method. That's a lot of code to write for something that buys you nothing whatsoever. And if you're going to say that it buys you the ability to swap in or out different backends, you already have that with jdbc.

Marshall Received on Wed Mar 05 2008 - 07:35:16 CET