Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Phlip <phlipcpp_at_yahoo.com>
Date: Sun, 04 Jun 2006 20:39:47 GMT
Message-ID: <nyHgg.45953$Lm5.8026@newssvr12.news.prodigy.com>


Marshall wrote:

> The thing is that every time you narrow the interface, you reduce the
> amount of the dbms's power that is available to the rest of the
> application, instead forcing the app into less well suited avenues,
> merely because they are pre-existing, or because they are
> convenient to the ORM layer.

You narrow the interface to what the application needs. When it needs more, you widen a little. The point is you can control your own application-specific code, so it must follow a style different than generic library code.

> The only way not to reduce it is to have the narrow interface
> expand each and every time the rest of the application has any
> additional need of data management services. In which case,
> what was the point of the narrow interface? It simply becomes
> a lot of extra boilerplate code, and doesn't change the abstration
> between the rest of the app and the dbms.

Write simple application-specific code so all of it easy to change in unexpected ways. Change is _easy_ when interfaces are narrow. Don't fear change.

A library provider has fewer options at change time, because they can't compete with their own last version. So they have to provide wide stable interfaces the first time. That's okay to emulate as a role model - if you are publishing a generic library.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
Received on Sun Jun 04 2006 - 15:39:47 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US