Re: Mixing OO and DB

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Tue, 4 Mar 2008 23:50:45 -0600
Message-ID: <2008030423504510672-unclebob_at_objectmentorcom>


On 2008-03-04 12:10:44 -0600, Gene Wirchenko <genew_at_ocis.net> said:

> Robert Martin <unclebob_at_objectmentor.com> wrote:
> 
>> On 2008-03-03 00:08:43 -0600, Gene Wirchenko <genew_at_ocis.net> said:
>> 

>>> Robert Martin <unclebob_at_objectmentor.com> wrote:
>>>
>>> [snip]
>>>
>>>> Not if they are explanatory.  Employee.find("Bob") is a lot easier to
>>>> understand than Select * from Employee_Table where Name = 'Bob';  In
>>>> any case, once you have the method, you can polymorphically replace it
>>>> with test methods etc.

>>>
>>> Bah! It is just syntactic sugar and not very sweet at that.
>>>
>>> Now try finding Bob who works in Accounting:
>>> select * from employee_table
>>> where name='Bob' and dept='Accounting';
>>>
>>> Your go.
>> 
>> 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.

OK, that's one more function.

> How many methods are you going to end up with?

One for each query intention.

How many different SQL statements will *you* wind up with?

> What will you have gained?

A simpler to read abstraction that hides the more complex implementation and can be polymorphically replaced with a stub implementation for the purpose of testing (among other things).

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |
Received on Wed Mar 05 2008 - 06:50:45 CET

Original text of this message