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

Internet Message Format | 1993-01-02 | 5.8 KB

Path: sparky!uunet!pipex!bnr.co.uk!uknet!gdt!aber!fronta.aber.ac.uk!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: Need basic OO information
Message-ID: <[e-mail]>
Date: 2 Jan 93 21:40:17 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth
Lines: 116
In-Reply-To: [e-mail]'s message of 29 Dec 92 16: 10:34 GMT
Nntp-Posting-Host: decb.aber.ac.uk

On 29 Dec 92 16:10:34 GMT, [e-mail] (David Geary) said:
Nntp-Posting-Host: grumpy

dgeary> [e-mail] writes:

tollefson> I'm looking for a good book (or E-mail replies) which can
tollefson> help me to understand some basics:

tollefson> 1) What are the basic benefits?  (why use it over
tollefson> traditional)

dgeary> When done correctly, OO makes the following *much* easier:

dgeary> 1.  Maintenance.  2.  Extensibility.  3.  Ability to change.

tollefson>      2) How does it work, very generally.

dgeary> *Very* generally, classes of objects which exhibit similar
dgeary> behavior are developed in a hierarchy of classes.  Using
dgeary> inheritance, specialized classes are derived from existing, more
dgeary> generalized, classes.

This is not *very* general; it is actually very specific to a fairly
common but by no means unique OO approaach.

Generally speaking, OO is about carving up large programming tasks in
optimally defined modules, where "optimally" means "most reusable", and
where one has a fairly effective principle on how to achieve this, which
is to put in the same module everything that knows the details of the
rpresentation of a class of values.

One way to express this in a language is to define as "class" the
description of one such module that defines the representation of a
class of like data, and to allow the programmer to mix and match classes
to derive the descriptions of new representations.

dgeary> This is a very natural paradigm for us humans; grouping similar
dgeary> classes of objects in hierarchies is something we do constantly
dgeary> in everyday life.

Mistakenly IMNHO -- hierarchical taxonomies are never quite apropriate;
they seem to apply most the time, but usually they can only be twisted
with effort to work in the very common case where many-to-many
relationships (between representations, as well as between values) need
to be described.

tollefson> (the only examples I've seen have been complex theoretical
tollefson> nightmares or simple contrived situations easily handled by
tollefson> conventional code.)

Frankly, complex nightmare sar enot theoretical at all; most
applications are unspeakably complex, if executed well. If not executed
well, the user will constantly bump against the "simplifications". OO
however helps anyhow; if you follow the OO principle on how to organize
a program, it is relatively easier to add or remove or modify the modules.

tolleefson> 3) How do you tell when to use it and when to avoid it for
tolleefson> specific programs?

Just about the only cases where the OO philosophy breaks down is when one
needs to define operations that are intimately involved with the details
of more than one representation, or, even worse, when representation
details are not what binds together a module most tightly.

Both cases are very hard to handle anyhow, and I am not aware of any
systematic way to attack them. In other words OO carries you as far as
you can go. Where its principle fails, there is not much of a clue
anyhow (well, I have a clue as to that, of course, even if very rough).

dgeary> OO is applicable across many different types of applications.
dgeary> There is some performance penalty for using OO in some
dgeary> situations; for speed critical apps this may be a problem.

Not really -- for example the speed penalty, if any, is usually about
dynamic procedure calls, which are a nifty idea independently of OO.
Most OO language implementations allow you to optimize it away though,
in most of the case where it can be done.

tollefson> 4) Can old dogs learn new tricks?  (how hard is it for a
tollefson> programmer to convert his thinking)

dgeary> I think it's a pretty natural thing to pick up.  Unfortunately,
dgeary> a developer who is mired down in a procedural paradigm may have
dgeary> a harder time making the switch to OO than someone who has never
dgeary> written a line of code in their life.

Well, if s/he has been writing modules and has realized that the most
maintainable way is to put in a module all the procedures that deal with
the same sort of data representation, as is often the case, he has
already got it. If not, getting into this new philosophy will be uplifting.

dgeary> I would recommend getting Smalltalk.  Smalltalk is a pure OO
dgeary> language where one can really see the benefits of having an
dgeary> existing hierarchy of very useful classes for building complex
dgeary> applications in a short period of time.

I would have Objective C as another recommendetation for C-ish
programmers.

tollefson> A description of a case where the programming became much
tollefson> easier or the end product became much better would be very
tollefson> helpful.  I'm not looking for source code, but some textual
tollefson> information on how the new scheme helped.

Use a NeXT workstation anytime, and try to customize it; compare with
the ease of customizing any other platform. Same goes for Smalltalk, and
so on.

dgeary> There are quite a few good books that cover simplistic case
dgeary> studies.  See the reading list that follows:

Not a bad list.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <[e-mail]>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta