Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: Teaching object oriented programmin
Message-ID: <80500066@p.cs.uiuc.edu>
Date: 3 Aug 89 14:58:00 GMT
References: <1318@massormetrix.ida.liu.se>
Lines: 74
Nf-ID: #R:massormetrix.ida.liu.se:1318:p.cs.uiuc.edu:80500066:000:3748
Nf-From: p.cs.uiuc.edu!johnson    Aug  3 09:58:00 1989


I'd like to thank Edward Berard for the good reference list.  There
were several Ada related articles that I haven't seen.  

He writes:
>There seem to be three classes of example problems:

Most of the programming language books have examples.  However,
the purpose is often to describe the language instead of the
programming style.  Stroustrup's book is a good example of this
phenomenon--you can't learn object-oriented design from that
book.  On the other hand, Smalltalk books often make an attempt
to teach design.  The language is so small that they would run
out of things to talk about if they didn't.  They talk about
both the design of the standard class libraries and the design
of new applications.  However, the examples are all pretty small,
and object-oriented programming becomes most valuable on larger
projects.

>If you find any object-oriented examples of any size, you will find
>that they often address such issues as "object-oriented domain
>analysis," "object-oriented requirements analysis," and
>"object-oriented design." Unfortunately you will find precious few
>references to "object-oriented development in the large" (OODIL) --
>but there are a few.

As far as I can tell, there aren't any problems in OODIL that are
unique to OO, they are all caused by the DIL.

One feature of object-oriented technology is that it squashes together
the various phases of the design cycle.  OOP is great for prototyping,
so usually systems are built during the requirements analysis phase to
help figure out what the user needs.  Not surprisingly, a certain amount
of design information is discovered here as well, and sometimes a few
components are developed that are reused later.  At the other end of
the life-cycle, I find that code is not reusable until it has been
reused, and this implies that you have to redesign software after it
has been used in a couple of projects.

On the other hand, OOP provides a consistent world-view that can carry
you through the whole life-cycle.  Requirements analysis is determining
the objects from the users point of view and figuring out what operations
will take place on them.  Design is decomposing these objects into smaller
objects, delegating responsibility for operations to various objects,
determining the class hierarchy, and discovering new classes that are
part of the solution domain, not the problem domain.  Implementation
is writing code for all the operations and defining data structures
for the classes.  Invariably new classes are discovered and the design
is revised during implementation, but that's just because top-down
development is impossible to carry off perfectly.

>Most of the work which has been done in the area of object-oriented
>life-cycle issues, outside of object-oriented programming, has been
>accomplished within the Ada community. 

In general, I don't like this work.  Speaking from the point of view
of a Smalltalk programmer, I think that they are really talking about
data abstraction and NOT object-oriented programming.  Important
issues that they miss are the importance of building families of
components with the same interface, using abstract classes for
templates for new components, and polymorphism.

On the other hand, I haven't read all these papers, so perhaps I am
missing something.  I'll read them.

By the way, I encourage people to take a look at Ed's object and
class specifications.  He sent me his notes and I found them worthwhile.

I agree that the details of execution of Smalltalk are unimportant.
However, the general world-view of objects communicating by sending
messages is important, and close to what Smalltalk actually does.
This notion is important to understand polymorphism and inheritance.

Ralph Johnson