Re: Mixing OO and DB

On 2008-03-08 16:57:43 -0600, Marshall <marshall.spight_at_gmail.com> said:

> On Mar 8, 1:59 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:

>> On 2008-03-06 01:58:54 -0600, Marshall <marshall.spi..._at_gmail.com> said:
>> 
>>>>> 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?

Hiding for clarification's sake is worthwhile. I agree that if the hiding doesn't clarify anything, it shouldn't be done. Most hidings are clarifying however.

> Do you
> write a method with a descriptive name to encapsulate
> all your regular expressions?

I usually put them in well named variables. I then hide call to match within a well named function.

> Also, the specific issue we were just discussing is the
> 2^n possible combinations of attributes when querying
> a table with n attributes. (Which only describes the
> simplest case of querying a single table; with joins
> there are many more combinations.) I don't want to have
> to create a separate class for each combination I want
> to use. What would I do in situations where I am writing
> SQL dynamically? Prefigure all the possible outcomes
> and write a class for each?

We aren't talking about writing classes for each query. We are talking about writing *functions* for the queries you need. If you need to create SQL dyamically, then write a function that understands how to do that, and pass in the appropriate arguments.

>> 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.

Odds are, if you are writing thorough tests, it will. And if not, at least you'll have added a bit of clarity to the code by giving each different kind of query a name.

-- 
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                  |