Re: Objects and Relations

On Feb 8, 11:43 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
> On Feb 8, 4:25 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 8, 1:04 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
> > > On Feb 7, 8:12 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> > > <snip>
>
> > > > 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.
> > > <snip>
> > > > 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.
>
> > > When I have worked with architects who have prepared models as
> > > blueprints and they point to their model of a doorway, they call it a
> > > doorway. They similarly use the terms "room" and "wall." There is no
> > > confusion at all. I understand they are pointing to a model of a room
> > > and calling it a room. Similarly with software. There is absolutely
> > > no reason whatsoever not to name the components of your model after
> > > that which they are modeling.
>
> > Note firstly that you have only provided a metaphor with your
> > architecture blue prints example. An (OO) object by definition
> > encapsulates state, behaviour and identity. All three must be
> > directly associated with the instance in memory. OO is fundamentally
> > about building a machine, not a model of something else. The state,
> > behaviour and identity must all be understood on that basis.
>
> One could say the very same thing about a 3-D model of a building, one
> that has doors that open, for example. Sure a doll house needs to be
> a working, functioning "machine" (if you will) but it is still a model
> of a house. Models have their own identity, but for a model of an
> existing building, there is also a mapping to that which it is
> modeling, even if only in the minds of those viewing it. Models do
> not include everything about that which they model (or they become
> clones). It is really very important, I think, to understand that a
> shopping cart on a web site is a model for a shopping cart in a store
> and that a ShoppingCart class in the software is also a model of that
> shopping cart.
>
> > If you were to build a *simulation* (not merely a model)
>
> simulations are one type of model

All the above comes down to definition. Your usage of "model" is different to mine. I restrict it to the narrow sense of the representation of knowledge (in the form of attributes and relationships) about external entities. I define "simulation" to be about creating a working machine that happens to *mimic* reality with no intention of storing knowledge about external entities. Are you saying such a distinction doesn't exist? If so then we disagree. If it is merely over what the words "model" and "simulation" mean there is nothing interesting to discuss.

I obviously can't prove that OO can't be used for modeling (using my sense of the term). I can only say it is not what OO is for.

> > using OO then
> > it would be fair and reasonable to use real world names for the
> > classes. For example a class called "car" may make sense in the scope
> > of the simulation. The identity of a car, its state and its behaviour
> > are all associated with an entity within the abstract machine. For
> > example, change the accelerator position and the car in the simulation
> > accelerates. If you like, take this as a definition of what
> > "simulation" (as distinct from "model") means.
>
> OK, you are able to see that something is a model when it very closely
> resembles that which it models.

Hang on I just said that the above car is *not* to be defined as a model. It is a simulation. Please accept my usage of the words for the sake of discussing the underlying ideas.

> Now abstract it a bit. A model can
> be very unlike a clone, perhaps with a focus on modeling only one
> aspect of that which it is modeling. Models are like metaphors. They
> capture some aspects, but not all.

Yes, with your liberal use of the word "model" (which encompasses architecture blue prints, doll houses, RM and OO).

> > A (data) model by contrast is all about representing knowledge (in the
> > form of attributes and relationships) about entities outside the
> > abstract machine.
>
> Physical data models might be about the shape of data on secondary
> storage devices, but a logical data model has to do with the
> interactions within software. It has to do with every point at which
> a language (or UI, service...) interacts with a tool that can put and
> get such data. Think of it as an abstract computer language that must
> be instantiated (for example, as SQL) and then used. We use data
> models. We use them in software, even if we do not care how the bits
> are laid out on disk for storage.

So?

> > That is not what OO is intended for, and never
> > was. The programmers who think that OO is suitable for building
> > models should study the RM because it is far better suited for that
> > purpose.
>
> OO is quite capable of modeling data, as is the RM. These are two
> different models. You are giving no proof that the RM is better
> suited for modeling data, even if such data finds its way to a
> secondary storage device.

Have you used OO for systems programming? One has a very clear focus on using objects that encapsulate state, behavior and identity to create a working machine. I doubt whether you would find a systems programmer that refers to the creations as "models". There is no interest in representing knowledge about external entities.

Contrast this with someone building a business application and they say to themselves "I need to represent all the employees in the company". Do you see the difference? The abstract machine is irrelevant; instead the focus is on representation of knowledge about external entities.

There is plenty of evidence to show that OO works very well for systems programming, and plenty of evidence that it is inferior to RM for representing knowledge about external entities.

I agree there is no formal proof.

> > Typically a model only represents partial information about the
> > entities and there is an intention to keep the model in sync with the
> > external entities.
>
> There might be intention in the minds of users to keep the accounting
> information in line with the "real world" for example, but there is no
> automated means of aligning data about a person, for example, with any
> computerized model.
>
> > There is no intention to think of the model as a
> > machine or even a simulation.
>
> The model is a model, it need not be a machine. There are many kinds
> of models. Please see if you can grasp this.

Yes, with your liberal use of the word "model".

> > It is to represent knowledge.
>
> To model it, in fact.

Your argument is based on trying to be unspecific.

> > It is precisely when OO is misused that the semantic lie appears in
> > the names of the classes.
>
> If I see a model of a building, I still call the walls "walls." Do
> you understand what a model is? A photograph is a model, as is a
> drawing of an owl by a 1st grader. These are not machines and need
> not be machines.

You are merely defending your liberal use of the word "model".

> > Therefore the ugly names represent a non-
> > problem and are better regarded as a symptom of the misuse of OO.
>
> I really hope you can get beyond this misconception.

> > > As for the scope of RM and OO, there is obviously an overlapping
> > > scope. The question is not whether one can persist data using one
> > > model for the data or another, but what the pros and cons are for
> > > using either or using some other model. Given a typical software
> > > application, one could choose to use an OO model, a multivalued model
> > > (Nelson-Pick model), a relational model, or a codasyl model, for
> > > example, for the development of this software application. I think
> > > that shows some overlap in scope, don't you? --dawn
>
> > I regard an "OO model" as a contradiction. In that sense I can't see
> > how it can overlap in scope with RM.
>
> Again, you need to move beyond this. It really is inaccurate. There
> are a lot of arguments out there for why the RM is "the only" possible
> model we could use for a DBMS. They are all flawed, but no others I
> have read have the holes in them that your argument does. Do some
> reading about various types of models and I think you will see that
> class Employee {...} is, indeed, a model of an employee. Best
> wishes. --dawn-

A class called Employee is a semantic lie. The word "Employee" is by definition a type of human, not a type of object. You want to resolve that problem by overloading the meaning of the word!

Imagine how many contradictions you'll get in mathematics if you overload definitions.

To be honest I'm surprised that members of a theory newsgroup would want to justify overloading the meaning of words (for the sake of brevity no less!!!!!!!!!) when the aim should be to properly understand what we're talking about.

Overloading a word to mean different things causes confusion and limits your ability to reason.

I note as well that most of your counterarguments are based on overloading the word "model". One of the signs of progress is the development of more refined words and definitions. For example it is useful to understand the difference between speed, velocity, momentum and kinetic energy of a moving object. Received on Fri Feb 09 2007 - 02:23:39 CET