Re: Mixing OO and DB

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?

It can be. Hiding for hiding's sake is unnecessary. Do you write a method with a descriptive name to encapsulate all your regular expressions?

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?

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

I would agree: if one needs separate implementations, it's better to be able to implement them polymorphically.

I would not agree that the situation we are discussing needs separate implementations.

Marshall Received on Sat Mar 08 2008 - 23:57:43 CET