Re: Objects and Relations
Date: 7 Feb 2007 18:12:53 -0800
On Feb 8, 6:26 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> 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.
Bob is confused about the difference between 'variable' and 'object'. Actually it tests whether p1 and p2 point to the same object (ie instance in memory). Since the object type is (incorrectly) named "Employee" on casual reading it may appear to be true if and only if p1 and p2 designate the same Employee.
Correct (and curiously Bob's use of the word 'variable' here is proper), but my question concerned the semantics at the level of the problem domain.
> Unless of
> course someone overrode the equality comparison operation.
Bob's knowledge of C++ seems rather limited. It is not possible to override pointer comparisons in C++.
> >> // Q2. What does this mean?
> >> if (*p1 == *p2) ...
> Conditional test whether the variables pointed to by p1 and p2 have the
> same value.
Bob again is confused about the difference between 'variable' and 'object'.
"Unless" suggests it is no longer a value test. On the contrary it's only reasonable to override to ensure it correctly represents a value test at the semantic level of the problem domain.
My point was that the value test relates to equivalence testing of two models of employees rather than two employees. In OO (and unlike RM) there is no semantic requiring models of different external entities to be unique as far as value testing is concerned. Therefore this test can potentially return true for models of different employees.
> >> // 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 is not possible to override assignment of pointers in C++.
The semantics of Clone at the problem domain level is generally unambiguous except in its scope (in the sense of has-a relationships to other objects). It always means making a copy of the object such that it has the same attributes but a different identity. This makes sense for a class named EmployeeModel, but not for a class named Employee.
> It has no objective meaning, and one has no way to know on the basis of
> the above information what meaning it might have.
Well written code doesn't leave you guessing like that. Good code ensures there is a simple and *consistent* relationship between the high level semantics and the low level language semantics.
> > 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.
Quite right. It is irrelevant.
> >>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.
Bob admits to a simplistic attitude. I want a reasonable criterion of when to favor one approach over the other.
The idea that you look at entities (let's just call them nouns if you like) and ask whether they are part of the abstract machine is simple yet important because it neatly explains, without meta-physical mumbo jumbo the non-overlapping difference in scope of RM and OO.
This is irrespective of whether you consider the nouns to be
- model/what is modeled
- part of the conceptual layer / part of the logical layer
> If one makes the somewhat absurd decision to use
> object classes, an Employee class might or might not have tremendous
> > 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
> > 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.
There are some excellent OO programmers that value brevity.
Code that becomes ugly in order to be correct demonstrates that one's whole approach may be wrong. The suffix "Model" on lots of your classes is a symptom. It is wise to take heed. Received on Thu Feb 08 2007 - 03:12:53 CET