Re: Objects and Relations

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

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

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

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

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

> It is to represent knowledge.

To model it, in fact.

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

> 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 Received on Thu Feb 08 2007 - 15:43:37 CET