Re: Objects and Relations

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.

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

>>}

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.

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