Re: Objects and Relations

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 07 Feb 2007 21:26:13 GMT
Message-ID: <Vtryh.3703$R71.56306@ursa-nb00s0.nbnet.nb.ca>

Marshall wrote:

> On Feb 6, 12:03 am, "David BL" <davi..._at_iinet.net.au> wrote:
>

>>On Feb 6, 3:57 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote:
>>
>>>On Feb 5, 9:58 pm, "David BL" <davi..._at_iinet.net.au> wrote:
>>
>>>>A class called Employee in an OO program is sloppy.  Instead it should
>>>>be called EmployeeModel (or better still EmployeeInfo).
>>
>>>I strongly disagree. "Employee" is a perfectly good name for
>>>a class that models a real-world employee. You don't put
>>>"-model" on the end because everyone knows it's a model.
>>>No one thinks that a Java class is an actual person; the
>>>confusion you're decrying doesn't occur in nature.
>>
>>My purpose was to draw attention to the semantic lie.
>>
>>Confusion does occur.

>
>
> You keep asserting that, but I am not convinced. I have never
> encountered anyone who thought that an employee record was
> an actual person, or that, say, you shouldn't issue an update
> to that row in the employee table because you haven't been
> introduced, or that Java Employee objects have to get enough
> sleep every night or they get cranky.
>
>
>

>>Consider the following
>>
>>void foo(Employee* p1,  Employee* p2)
>>{
>>    // Q1.  What does this mean?
>>    if (p1 == p2)  ...

Conditional test whether p1 and p2 point to the same variable. ie. whether the p1 variable has the same value as the p2 variable. Unless of course someone overrode the equality comparison operation.

>> // Q2. What does this mean?
>> if (*p1 == *p2) ...

Conditional test whether the variables pointed to by p1 and p2 have the same value. Unless of course someone overrode the equality comparison operation.

>> // Q3. What does this mean?
>> Employee* p = p1->Clone();

The meaning is not apparent and depends on how someone might have overridden the assignment operation and how someone wrote a Clone method.

It has no objective meaning, and one has no way to know on the basis of the above information what meaning it might have.

>>}

>
> The issue of equality vs. identity is a well understood one,
> and it doesn't have anything to do with how we name
> classes. This is a non-sequitur.

It is well understood and the above snippet of code is pretty-much irrelevant to it.

>>IMO it's a moot point because the very idea to have an Employee class >>is wrong. RM should be used.

I agree the RM should be used, but only because one should always use it whenever one can. If one makes the somewhat absurd decision to use object classes, an Employee class might or might not have tremendous utility.

> Although I prefer the RM to OO models, I am unwilling to tell
> OOPL programmers that they can't write code about employees
> for purely philisophical reasons. I'd rather make the case that
> they ought to be using set-at-a-time operations for arguments
> relating to expressiveness, integrity, and consistency. And
> also performance in a distributed app.

Well, they should use set-level operations for operating on sets of things. I have had to deal with some horrible messes created when naive programmers failed create an appropriate class for a set of something along the lines of creating a cell class but no spreadsheet class.

>>When OO is used sensibly (say for
>>systems programming, front ends or games development) the problem
>>doesn't exist.  For example classes named String, Stack, Image are
>>well named.  Appending "Info" or "Model" to these would be
>>inappropriate.

>
> If in fact there is a clear-cut demarcation between what should
> and should not have an "info" suffix, then we could perhaps
> choose to adopt the naming convention of applying "-info"
> where appropriate. However, we could also adopt the convention
> that we do not do so, and instead implicitly understand
> which ones are models of real-world entities and which
> ones are not, which we've already decided we can
> unambiguously do because of the clear-cut demarcation
> we've agreed on.
>
> The latter is more concise.

You don't actually expect an OO programmer to value brevity, do you? Received on Wed Feb 07 2007 - 15:26:13 CST