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!pipex!uunet!rcm!rmartin
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Teaching OO
References: <1994Dec31.225557.5213@mole-end.matawan.nj.us> <1995Jan5.234347.7823@rcmcon.com> <3ekiib$2fu7@news-s01.ny.us.ibm.net> <1995Jan9.183950.7765@rcmcon.com> <1995Jan12.142433.5953@inca.comlab.ox.ac.uk> <3f6aam$2k5f@news-s01.ny.us.ibm.net>
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Sat, 14 Jan 1995 18:08:03 GMT
Message-ID: <1995Jan14.180803.5237@rcmcon.com>
Lines: 51
Xref: glinda.oz.cs.cmu.edu comp.object:25055 comp.lang.c++:107474 comp.lang.smalltalk:19545

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:
>[snip]
>>>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.

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

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

-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++
