Re: Mixing OO and DB

topmind wrote:

> Robert Martin wrote:
>

>>On 2008-02-20 10:20:47 -0600, topmind <topmind_at_technologist.com> said:
>>
>>>On Feb 20, 6:03�am, Robert Martin <uncle..._at_objectmentor.com> wrote:
>>>
>>>>On 2008-02-19 12:40:27 -0600, topmind <topm..._at_technologist.com> said:
>>>>
>>>>>>Yet even in the most data driven application there will still be
>>>>>>behavior, and there will be code that implements that behavior, and
>>>>>>there will be dependencies between the elements of the source code that
>>>
>>>>>>need to be managed.
>>>>
>>>>>Yes, but behavior tends to be "neutered" in data-driven apps such that
>>>>>OO's change-handling techniques are less useful there.
>>>>
>>>><<quasi-political metaphor elided>>
>>>>
>>>>That's not the point. �The point is that wherever there is code there
>>>>are dependencies that need to be managed, and OO is a useful tool that
>>>>helps with that management.
>>>
>>>I'll believe it when I see semi-realistic code examples for data-
>>>driven apps.
>>
>>Are you suggesting that the source code that implements data driven
>>applications doesn't have dependencies that need managing?

>>Or are you
>>suggesting that the indirection of  OO is not effective at managing
>>such dependencies.

I don't know about Topmind, but hell yes I am saying exactly that.

>>Either position is absurd on the face of it.

Bullshit. You are a moron.

> If OO can be good at managing dependencies of data-driven
> applications, then I have not seen a good coded biz example of it.

OOP strives to hide dependencies. Denial is not an effective management tool. It's dysfunctional.

> Generally OOP and tables fight over what manages non-trivial
> variations-on-a-theme. It is usually a "violation" of repetition
> factoring to let them both do it because we don't want feature mapping
> (Thing A gets feature X) to be duplicated in both code and tables.
Received on Thu Feb 21 2008 - 22:18:33 CET