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

Stephane Ducasse squeak-dev at lists.squeakfoundation.org
Wed Sep 11 06:30:27 UTC 2002


I like the book of Arthur Riel Object Oirented Design Heuristics
even if it is in C++ there are a lot of useful advices....

Stef
On mardi, septembre 10, 2002, at 03:55  PM, Mark Guzdial wrote:

>
> On Monday, September 9, 2002, at 02:38  PM, G=F6ran Hultgren wrote:
>> Ok, let me be a bit frank.
>>
>> PWS might be simpler in terms of LOC but the design gives me the=
=20
>> creeps. What is
>> an instance of the class "PWS"? A server? Or a request? And if it =
is=20
>> a request
>> (which it is) why is the class called PWS and why does it have cla=
ss=20
>> methods as
>> if it was a server?
>>
>> In short - I find it very poor "OO design" having the class=20
>> 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=20
>> fine by me
>> but... Ok, I can't refrain from saying this - *personally* I would=
=20
>> not use this
>> code in a course called "Objects and design".
>
> I understand your complaints, but my decision is based on pedagogic=
al=20
> strategy.
>
> As a graduate student, I worked with Elliot Soloway, who's thought =
a=20
> lot about how we teach computer science.  One of his complaints is=
=20
> that we rarely teach design -- most textbooks show students complet=
ed=20
> works of lovely design and announce "Ta-dah!" without a word of how=
 we=20
> got there, nor why it's a good design.  One of my goals with the Wh=
ite=20
> Book was to directly address this criticism:
> - The White book builds things over-and-over.  Joe the Box gets don=
e=20
> twice.  The Clock UI gets redone FIVE times.
> - I explicitly point out both good and bad design.  Your complaints=
=20
> about PWS are made very explicitly in the Case Study chapter.
>
> One of Elliot's papers is titled "'But my program runs!': Discourse=
=20
> rules for programmers"  The common complaint from students who get=
=20
> points taken off for bad designs is, "But it works! Why should I ge=
t=20
> points taken off?"  As novice programmers, it's very hard to get=
=20
> students to recognize bad design -- they simply haven't had enough=
=20
> experience to be able to understand the alternatives, that there is=
=20
> more than one way to do anything.  My class is for Sophomores --=
=20
> they're ready to move past that point, in my estimation.  So I very=
=20
> explicitly have them use things with "bad" design -- we critique it=
,=20
> we point out that it works but that isn't enough, and we have them =
use=20
> and even extend it so that they get a sense of what it's like to li=
ve=20
> with not-quite-100% designs.
>
> In my opinion, school should not be a museum of lovely works that o=
ne=20
> admires but doesn't touch.  Learning occurs much better in the sand=
box=20
> or at the workbench, where you learn to deal with things that aren'=
t=20
> 100% and you learn to recognize the good and the bad.  To teach=
=20
> design, I'd much rather have students use something whose faults we=
=20
> can carefully analyze, than simply assign use of something terrific=
=20
> that goes without comment (or that we can only say good things abou=
t).
>
> Mark
>
> __________
> Mark Guzdial : Georgia Tech : College of Computing
> Atlanta, GA 30332-0280
> Associate Professor, Learning Sciences & Technologies
> Collaborative Software Lab, http://coweb.cc.gatech.edu/csl
> http://www.cc.gatech.edu/~mark.guzdial/
>
>
>
Dr. St=E9phane DUCASSE (ducasse at iam.unibe.ch)=20
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes





More information about the Squeak-dev mailing list