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

From: Christian Brunschen <>
Date: Fri, 2 Jun 2006 10:34:29 +0000 (UTC)
Message-ID: <e5p47l$5ko$>

In article <wIKfg.16269$>, Bob Badour <> wrote:
>Christian Brunschen wrote:
>> In article <lsBfg.3076$%86.209_at_trndny04>,
>> David Cressey <> wrote:
>>>"Christian Brunschen" <> wrote in message
>>>>For a trivial example, consider an application that needs to somehow
>>>>authenticate users [ ... ]
>>>What makes the example trivial? Do you mean trivial in the sense that
>>>mathematicians use the word, in the sense that engineers use the word, or
>>>in the sense that common parlance uses the word?
>> In a very loose common parlance sense of the example being easy to come up
>> with, not being contrived and thus something that people do occasionally
>> encounter.
>You left out the part where it was not very illuminating either.
>Assuming one decides that forgoing the authentication system built into
>every dbms is a good idea in the first place, authentication lends
>itself to a simple predicate (using the computer programming definition)
>or similarly simple subroutine regardless.

For one thing, not all RDBMS:es offer authentication services; for another, not all of them offer them in exactly the same way. Either way, it still makes sense to create an interface used by the application and implemented in whatever way necessary by the pluggable implementation, whether it uses LDAP, ORACLE, MySQL, Derby or something else.

>Your argument is as valid as stating one should create a square root
>function to isolate the program from numerical methods or a distance
>function to isolate the program from your choice of square root function.

If you have the option of using different math libraries (that might use different algorithms, offer different precision or similar), then that would indeed be an excellent thing to do, wouldn't it?

>While I consider the separation of concerns a sound design principle,
>your argument leaves me uncertain as to what concerns you intend to

Wherever it makes sense to separate concerns, they should be. It makes the code more maintainable and robust in the face of change.

Best wishes,

// Christian Brunschen Received on Fri Jun 02 2006 - 12:34:29 CEST

Original text of this message