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

In article <FtXfg.16505$A26.381501_at_ursa-nb00s0.nbnet.nb.ca>, Bob Badour <bbadour_at_pei.sympatico.ca> wrote:
>Christian Brunschen wrote:
>
>> In article <wIKfg.16269$A26.376462_at_ursa-nb00s0.nbnet.nb.ca>,
>> Bob Badour <bbadour_at_pei.sympatico.ca> wrote:
>>
>>>Christian Brunschen wrote:
>>>
>>>>In article <lsBfg.3076$%86.209_at_trndny04>,
>>>>David Cressey <dcressey_at_verizon.net> wrote:
>>>>
>>>>>"Christian Brunschen" <cb_at_festis.df.lth.se> wrote in message
>>>>>news:e5mir9$gug$1_at_news.lth.se...
>>>>>
>>>>>>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;
>
>I can only conclude you do not know what database management system
>means. Security and authentication are fundamental functions of a dbms.
>If some product fails to deliver that function, it cannot possibly be a
>dbms.

Do all RDBMS:es offer the same level and functionality, do they all expose it in the same way, and so on and so forth? No. In other words, there would still be differences in how authentication services, built on top of different RDBMS:es, would have to be implemented. And indeed, it might be that the application has other requirements that makes it unsuitable to use the database's authenticaation mechanism.

By the way, is user authentication included in any SQL standard? I've looked on the net, but found nothing that indicates this to be the case; to the contrary. Now, presuming I've not missed somethign obvious and thus it's not, you're basically saying that even something that implements all of the mandatory parts of the SQL ... still isn't an RDBMS?

>[remainder predicated on false axiom snipped]

... except that even if authentication services _are_ offered by RDBMS:es, they don't seem to be offered in any standardised platform, so one would still need to have different implementations depending on which particular RDBMS one wanted to use; and by hiding all these different implementations between one shared interface, we can replace one with another as necessary.

>>>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?
>
>It might be an excellent thing to do; however, your response does not
>address the issue I raised.

You said that my 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 was as valid as stating one should create a square root function so as to insulate the program" - and then you appear to agree that that, in fact, is perfectly valid ... thus appearing to completely validate validate my argument! Thank you :)

>All you have established is simple
>predicates (in the computer programming sense) and simple subroutines
>make for cohesive abstractions.
>
>That in no way supports an argument that one should establish an
>arbitrary level to hide a higher-level language from a lower-level one
>and thereby forsake the benefits of the higher-level abstraction.

I disagree that an RDBMS is a 'higher-level abstraction' than an object-oriented program is. The relational model may have a better mathematical foundation, but that does not a 'higher level of abstraction' make, certainly not from the point of view of the application - which will be dealing with abstractions like 'User', which will be implemented in the OO model with classes, in the database through rows in a table, and so on. (I.e., I would place the OO model and the relational model on similar levels of abstraction.)

>>>While I consider the separation of concerns a sound design principle,
>>>your argument leaves me uncertain as to what concerns you intend to
>>>separate.
>>
>> Wherever it makes sense to separate concerns, they should be. It makes the
>> code more maintainable and robust in the face of change.
>
>You are begging the question. We agree axiomatically that separating
>concerns is a sound design principle. You do not need to write pointless
>tautologies purporting to prove an agreed axiom.
>
>By suggesting one should establish some boundary level in the code to
>hide a higher level abstraction, what concerns do you think you are
>separating on each side of that boundary?

From the point of view of what I as an application developer am trying to achieve, most of the abstractions offered by services that I consume are going to be 'lower level' than the things I am working on - such as existing classes and objects in the language I am using, predefined libraries, or even using an RDBMS to manage data. So your choice of phrase, 'hiding a higher-level abstraction behind a lower-level one', is inaccurate from my point of view: I am, instead, building _my_ _higher-level_ abstractions on top of the lower-level ones that are available to me. And I am insulating each distinct service or similar that I use and may want or need to be able to replace, behind a wall of my own design, so that everything else just talks to the wall regardless of what's hiding behind it. This also allows me to make that wall, that interface, as general or as specific, as narrow or as wide, as my application warrants.

Best wishes,

// Christian Brunschen Received on Fri Jun 02 2006 - 23:13:52 CEST