Re: Objects and Relations

On Feb 7, 2:45 am, "Marshall" <marshall.spi..._at_gmail.com> 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) ...
>
> > // 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.

The difference between equality vs. identity is not the point I'm making.

Take Q1. People may read that and think that it (identity) tests for whether p1 and p2 represent the same Employee. That is not true. It actually only (identity) tests for whether p1 and p2 represent the same model of an Employee.

Take Q2. Have we cloned an Employee? No! We have only cloned a model. I note that when I described this on comp.object one person regarded this as a limitation (artifact) of the OO language and could be made sense of at the design level. I call that confusion.

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

In a sense OO modeling is a contradiction. Objects by definition encapsulate state, behavior and identity. Objects are what they are and they cannot pretend to be something else. The interpretation that objects model something else, if you want to make it, is outside the semantics of OO which is (merely) to construct an abstract machine. If I see OO code that has forgotten that I'm compelled to tell the (ignorant) programmer to stop misusing OO.

I have written large OO programs that have no need to confuse the semantics of object identity. I see no reason why anyone else should!

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

There is a bigger problem. It tricks legions of ignorant OO programmers into thinking that OO should be used to "state" knowledge about external entities when RM is much better. Received on Wed Feb 07 2007 - 02:28:20 CET