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

From: phlip <phlip2005_at_gEEEmail.com>
Date: Fri, 02 Jun 2006 17:04:33 GMT
Message-Id: <pan.2006.06.02.17.04.29.546453@gEEEmail.com>

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.

-- 
  Phlip

Received on Fri Jun 02 2006 - 12:04:33 CDT