Re: Mixing OO and DB

From: topmind <topmind_at_technologist.com>
Date: Thu, 21 Feb 2008 12:56:14 -0800 (PST)
Message-ID: <3ded9ab0-915b-488f-b908-592fe2f8dbde_at_b29g2000hsa.googlegroups.com>


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?

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.
>
> Either position is absurd on the face of it.

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

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.

>
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Thu Feb 21 2008 - 21:56:14 CET

Original text of this message