Re: Objects and Relations

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) ...
>
> // Q2. What does this mean?
> if (*p1 == *p2) ...
>
> // Q3. What does this mean?
> Employee* p = p1->Clone();
>
> }

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.

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

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.

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

Marshall Received on Tue Feb 06 2007 - 18:45:51 CET