NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/object/4658

Text File | 1992-12-24 | 3.4 KB | 69 lines

Newsgroups: comp.object
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!torn!nott!ObjecTime.on.ca!ObjecTime.on.ca!bran
From: [e-mail] (Bran Selic)
Subject: Re: A little glossary for objects
Message-ID: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Bran Selic)
Organization: ObjecTime Limited
References: <knight.724948496@cunews> <[e-mail]>
Distribution: bnr
Date: Thu, 24 Dec 92 14:34:38 GMT
Lines: 55

In article <[e-mail]>, [e-mail] (Bernhard Rumpe) writes:
|>
|>
|> Little glossary of object oriented software developement
|> ========================================================
|>
|> This paper is one result of a workshop over software development
|> of three partners from software industry and universities. The glossary
|> is a mixture of different views: a practical and a formal one, according
|> to the backgrounds of the partners.
|>
|> This glossary aims at giving small, rather formal definitions of object
|> oriented notions. The definitions are neither exact mathematic definitions
|> nor do they correspond exactly to the definitions used in the area of
|> algebraic specifications. We do not claim to cover the whole area of
|> object orientation with our definitions (but we tried to cover a large part).
|>
|> So what do you think of the following definitions?
|>

One thing that strikes me whenever people describe the object paradigm is
that defining what an "object" is, is only half the story. What is often
missing, in my view, is a definition of what I think is the primary aspect
of the object paradigm: what an object-oriented "system" is.

(An informal definition: an object-oriented system is a network of
co-operating objects.)

The significance of this is that the definition of an object should be
driven from this "deductive" system-centric perspective rather than from
an "inductive" or, object-centric, view. After all, an object
(e.g., a stack) by itself is not very useful just like a brick by itself
is not useful. To carry this analogy further, we seem to be focusing
too much on the technology of bricks at the expense of developing an
understanding of architectures.

There are a few exceptions too this, the work of Ralph Johnson and Ray Buhr
come to mind. Also, there is the ROOM methodology which recursively
encapsulates an object-oriented system withinin a higher-level object (etc.)
allowing in this way entire architectures to be subclassed and reused as
components. Simple and effective as it seems, this idea has yet to be
widely accepted by the object community which in the best tradition of
academia looks for elegant solutions while ignoring the problems.

(This is not meant as a comment on the glossary that prompted this article;
I rather liked the glossary.)
--
*------------------------------------------------------------*
* Bran Selic                 |  phone: [phone]        *
* Vice President R&D         |  fax: [phone]          *
* ObjecTime Limited          |  e-mail: [e-mail] *
* 340 March Road             |                               *
* Kanata, Ontario, CANADA    |                               *
* K2K 2E4                    |                               *
*------------------------------------------------------------*