On Monday, September 9, 2002, at 02:38  PM, Göran Hultgren wrote:
> Ok, let me be a bit frank.
>
> PWS might be simpler in terms of LOC but the design gives me the 
> creeps. What is
> an instance of the class "PWS"? A server? Or a request? And if it is a 
> request
> (which it is) why is the class called PWS and why does it have class 
> methods as
> if it was a server?
>
> 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.

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

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

__________
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/