How to teach design (was Re: Squeak book !)

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Tue Sep 10 15:20:15 UTC 2002


Hi Mark and all!

Mark Guzdial <guzdial at cc.gatech.edu> wrote:
> On Monday, September 9, 2002, at 02:38  PM, Göran Hultgren wrote:
[SNIP]
> > In short - I find it very poor "OO design" having the class 
> > effectively being
> > the server singleton and instances of itself represent requests to it.
> >
> > I know that PWS was whipped together very quickly (IIRC) and that is 
> > fine by me
> > but... Ok, I can't refrain from saying this - *personally* I would not 
> > use this
> > code in a course called "Objects and design".
> 
> I understand your complaints, but my decision is based on pedagogical 
> strategy.

Aha! Now that's more like it.

> As a graduate student, I worked with Elliot Soloway, who's thought a 
> lot about how we teach computer science.  One of his complaints is that 
> we rarely teach design -- most textbooks show students completed works 
> of lovely design and announce "Ta-dah!" without a word of how we got 
> there, nor why it's a good design.  One of my goals with the White Book 

Yes, very true observation. In many different disciplines in fact, not
just CS.

> was to directly address this criticism:
> - The White book builds things over-and-over.  Joe the Box gets done 
> twice.  The Clock UI gets redone FIVE times.
> - I explicitly point out both good and bad design.  Your complaints 
> about PWS are made very explicitly in the Case Study chapter.

Goodie. :-)

> One of Elliot's papers is titled "'But my program runs!': Discourse 
> rules for programmers"  The common complaint from students who get 
> points taken off for bad designs is, "But it works! Why should I get 
> points taken off?"  As novice programmers, it's very hard to get 
> students to recognize bad design -- they simply haven't had enough 
> experience to be able to understand the alternatives, that there is 
> more than one way to do anything.  My class is for Sophomores -- 
> they're ready to move past that point, in my estimation.  So I very 
> explicitly have them use things with "bad" design -- we critique it, we 
> point out that it works but that isn't enough, and we have them use and 
> even extend it so that they get a sense of what it's like to live with 
> not-quite-100% designs.
> 
> In my opinion, school should not be a museum of lovely works that one 
> admires but doesn't touch.  Learning occurs much better in the sandbox 

I agree fully.

> or at the workbench, where you learn to deal with things that aren't 
> 100% and you learn to recognize the good and the bad.  To teach design, 
> I'd much rather have students use something whose faults we can 
> carefully analyze, than simply assign use of something terrific that 
> goes without comment (or that we can only say good things about).
> 
> Mark

Interesting topic. I used (couple of years ago) to teach "OO in
practice" - a followup 2-day course to a basic 2-day OO course for
professional developers. We argued that all these short courses tend to
use "silly" code - very small examples that can't begin to show the
advantages of OO. So I developed a domain implementation of a library
with Books, Magazines, Customers etc. I also built a UI on top of it for
students to play with but that is beside the point.

The course was planned like this:

Day one before lunch: Teach Smalltalk in 3 hours. Simple syntax,
messages, browser, debugger. Small exercises.
Day one after lunch: Explain the library code. Object models. Small
exercises - creating the model, populating it a bit, digging around with
inspectors etc. Seeing the model "for real".

Day two before lunch: Point out missing functionality - a complete class
missing - Loan. Discuss how it should be implemented. Use the existing
code as hints for what protocol it should provide. Focus on
encapsulation, protocols etc. Students start planning on paper.

Day two after lunch: Agree in a groupdiscussion together on one
implementation. Let the students implement it (in groups of 2). When the
testcode runs correctly they are free to go home! :-)


I taught this course about 8-10 times and it worked very well. At one
point a *very* capable teacher tried remaking it using Java but gave up
- there was no way to be able to teach enough Java in 3 hours etc. Java
has too much stuff that must be explained - students don't like to be
told "Never mind those funny characters - they should just be there...".
:-)

Almost all students loved the course and thought it really showed how an
OO system works. It also made the theoretic concepts become tangible and
understandable.

Anyway, I am not sure why I am writing about this - I just wanted to
show that I understand what you are saying. :-)

regards, Göran



More information about the Squeak-dev mailing list