Re: Mixing OO and DB

On Feb 21, 1:18 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> topmind wrote:
> > Robert Martin wrote:
>
> >>On 2008-02-20 10:20:47 -0600, topmind <topm..._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?
>
> > No. Most non-trivial software has tons of dependencies.
>
> >>Or are you
> >>suggesting that the indirection of OO is not effective at managing
> >>such dependencies.
>
[snip]
>
> > 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.

A good question to ask is if any dependencies found are part of the domain (such as the relationship between employee and a paycheck) or is a product of "computing space". If the first, then they will probably exist *somewhere* regardless of the paradigm/technique used because the domain itself needs them linked. The second kind needs to be evaluated on a case-by-case basis. Often there are tradeoffs such that adding them one place removes them from another, and visa verse.

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

-T- Received on Fri Feb 22 2008 - 00:42:19 CET