Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!swrinde!pipex!uunet!mole-end!mat
From: mat@mole-end.matawan.nj.us
Subject: Re: Teaching OO
Message-ID: <1995Jan17.051437.9948@mole-end.matawan.nj.us>
Organization: :
References: <1994Dec31.225557.5213@mole-end.matawan.nj.us> <1995Jan14.180803.5237@rcmcon.com>
Date: Tue, 17 Jan 1995 05:14:37 GMT
Lines: 95
Xref: glinda.oz.cs.cmu.edu comp.object:25149 comp.lang.c++:107824 comp.lang.smalltalk:19604

In article <1995Jan14.180803.5237@rcmcon.com>, rmartin@rcmcon.com (Robert Martin) writes:
> bfelton@ibm.net writes:
> 
> >In <1995Jan12.142433.5953@inca.comlab.ox.ac.uk>, lady0065@sable.ox.ac.uk (David J Hopwood) writes:
> >>In article <1995Jan9.183950.7765@rcmcon.com>,
> >>Robert Martin <rmartin@rcmcon.com> wrote:
 ...
> >>>I have no objection if beginning students are taught to fiddle with
> >>>OOPLs.  But the principles of OOD, i.e. the management of
> >>>dependencies, will not be properly understood without the proper
> >>>context.
 ...
> >>I would dispute that. As you say in another thread, the important difference
> >>between Data Abstraction and OOD that allows dependencies between modules to
> >>be broken, is the use of abstract interfaces (or protocols, or whatever you
> >>want to call them). New OO programmers can be immersed in that from day 1.
> >>So where is the problem?
> >>
> >>Perhaps beginning students will not appreciate just how bad previous
> >>approaches were at managing dependency. Is that any great hardship?
> >>I don't have to learn the ins and outs of using vacuum tubes before I
> >>can use a knowledge of transistors. I know that transistors are smaller,
> >>faster, more energy-efficient, etc., and that is all I need.

No, actually it's NOT all you need.  You need to be able to model the
transistor in the circuit, and the modelling tool you use is circuit
theory--the very same tool you use for modelling vacuum tubes.  Both
transistors and vacuum-tubes are three-terminal devices; the tube has
grounded-cathode, grounded-plate, and grounded-grid configurations; the
(bipolar junction) transistor has common-emitter, common-collector, and
common-base configurations; the properties of one tube amplifier
configuration are analagous to those of the corresponding transistor
amplifier configuration.  Both tubes and transistors can be used in
differential amplifier configurations; both can be used in push-pull
configurations.  (Transistors can be stacked a totem-pole arrangement
impossible to transistors because both electrons and holes can be
majority carriers in transistors where only the electron plasma--`space
charge'--can serve as the current carrier in vacuum tubes.)

> >I strongly agree with Mr. Hopwood.  Not only does this map much more
> >realistically on to my own experience with electronics, but I think it
> >exposes one of the central problems I have with Mr. Martin's views:
> >One will *never* proceed beyond "fiddling" with OOPL's if one does
> >not have some design guidelines to go by.
> 
> Of course.  And so they must be taught.  And to begin with, we teach
> the simple guidelines, e.g. use sequence, selection and iteration
> instead of random goto.   
> 
> As the students gain more skill, they can be taught functional
> decomposition, and data structures.  Still later they can be taught
> encapsulation, data hiding, and data abstraction.   Still later,
> inheritance and polymorphism can be taught.

I agree very strongly with Bob; the one place where we may differ is
in how much suffering we should allow the student at any given level.
I think it's enough to _show_ an example or two where the method breaks
down and to explain the breakdown.  Students who are on the ball will
appreciate what is presented.
 
> >To assert that all there is to OOD is "dependency management" is to miss
> >a number of useful OO design guidelines.
> 
> I don't think so.  If you consider all the guidelines that I mentioned
> above, I think you will find that they all are ways of managing
> dependencies.  Of isolating knowlege of one part of the design from
> other parts of the design.  

I'd like to suggest a different view: dependency management is _one of
the functions_ that we must perform in managing software.

Right now, OO is the best we have.  Someday we'll have something better.
In being better, it will either _incorporate_ OO, _transcend_ OO, or
completely _refute_ OO.  Which it will do is anyone's guess.

E/R modelling has been more-or-less incorporated in Class-relationship
modelling, thus OO has _incorporated_ the static model of SA/SD.  (I
think there is still a place for `pure' E/R, or for a mix of E/R and C/R,
because the incorporation is not complete.)

Instead of depicting communication between procedural program units by
structure charts, OO depicts communication between units that join
procedure and data (state).  Class-message and object-message diagrams,
and even event traces, have _transcended_ the structure chart.

SA/SD begins with the process model (DFD); the transformation of process
model into the structure chart is the main `black magic' of SA/SD.
OO as a whole _refutes_ the use of the detailed process model (as
depicted in a DFD) as a primary analysis and design model.  (It's
still useful as a secondary model.)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
	(Training and consulting in C, C++, UNIX, etc.)
