Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 02 Jun 2006 21:47:18 GMT
Message-ID: <Gl2gg.16652$A26.384572_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> Here's James Kanze, many winters ago:
>
> ----8<-----------------------------
>
> My point is really fairly simple:
>
> 1. Standard libraries are, by their nature, general. This implies a
> "wide" interface. And it has a sometimes significant price in run-time.
>
> 2. At the application (design) level, you don't need the wide interface,
> and a class customized to the required "narrow" interface can probably
> be far more efficient.
>
> 3. If the wide interface is present, some one is going to use it. Which
> means that you cannot later switch to a narrow interface.
>
> A simple example would be a text editor. A priori, the standard string
> class provides all of the functionality needed. On the other hand, the
> probability that the implementation is optimized precisely for your
> editor is pretty slim. If you design your editor using the standard
> string class as the text buffer, it is going to be next to impossible to
> optimize it later. A better solution would be to design a text buffer
> class, with exactly the needed functionality (and no more), and use the
> standard string to implement it.
>
> --James Kanze
>
> ----8<-----------------------------
>
> Now work his example, replacing editor with application, and string class
> for database. Narrow any wide interface down to what your application
> needs, then program to that interface.
Date: Fri, 02 Jun 2006 21:47:18 GMT
Message-ID: <Gl2gg.16652$A26.384572_at_ursa-nb00s0.nbnet.nb.ca>
phlip wrote:
> Marshall wrote:
>
>
>>>Team A, however, can sack its DBA any time they feel like, and can easily >>>replace the DB-facing modules with some other system. >> >>False! You might switch Oracle and DB2, but you're not going >>to "easily" replace Postgres with read/write/seek unless you've >>completely failed to understand the value and proper use of >>a DBMS, and treated it as no better than a record store.
>
>
> Here's James Kanze, many winters ago:
>
> ----8<-----------------------------
>
> My point is really fairly simple:
>
> 1. Standard libraries are, by their nature, general. This implies a
> "wide" interface. And it has a sometimes significant price in run-time.
>
> 2. At the application (design) level, you don't need the wide interface,
> and a class customized to the required "narrow" interface can probably
> be far more efficient.
>
> 3. If the wide interface is present, some one is going to use it. Which
> means that you cannot later switch to a narrow interface.
>
> A simple example would be a text editor. A priori, the standard string
> class provides all of the functionality needed. On the other hand, the
> probability that the implementation is optimized precisely for your
> editor is pretty slim. If you design your editor using the standard
> string class as the text buffer, it is going to be next to impossible to
> optimize it later. A better solution would be to design a text buffer
> class, with exactly the needed functionality (and no more), and use the
> standard string to implement it.
>
> --James Kanze
>
> ----8<-----------------------------
>
> Now work his example, replacing editor with application, and string class
> for database. Narrow any wide interface down to what your application
> needs, then program to that interface.
And your point would be? Received on Fri Jun 02 2006 - 23:47:18 CEST