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 13:57:57 GMT
Message-ID: <FtXfg.16505$A26.381501@ursa-nb00s0.nbnet.nb.ca>

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.

[remainder predicated on false axiom snipped]

>>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. 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.

>>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? Received on Fri Jun 02 2006 - 08:57:57 CDT