[Edu-sig] Re: Python Programming: An Introduction to ComputerScience

[Kirby Urner]

Earlier I wrote:
> When considering option (e), my attention goes to the Point class.  If all
> a Point does is hold x and y coords, then a class implementation seems 
> like overkill in Python.  You could get by with built-in tuples.

Now that I have the student CD, I see that the Point class is not just a
holder for (x,y) values.  It has some knowledge of Tk, is in fact a subclass
of GraphicsObject, which is very Tk aware.

This brings up a design pattern thread for me.  My tendency over the years
has been to write the geometric objects, such as vectors and polyhedra, in
such a way as to deliberately keep them ignorant of any output apparatus.  

Then I define a "writer" that's customized to say Tk, or VRML, or POV-Ray,
and pass the geometric objects to the writer.  The writer squeezes pure
geometric information from the things, and translates them into output
appropriate to its medium.

You can see evidence of this strategy going all the way back to 1998, when I
was still doing this stuff in FoxPro (I hadn't learned of Python yet):
http://www.4dsolutions.net/ocn/oop.html

A consequence of this design is I've been putting what philosophers used to
call "secondary attributes" (color, texture) in the writer, instead of in
the geometric objects.  So if I want a red tetrahedron, say, I change to
"edge color" and "face color" properties in the writer, before passing a
tetrahedron object to it.

E.g.:

  >>> povwriter = povray.Povray("outfile.pov")
  >>> povwriter.cylcolor = 'Red'  # secondary attribute
  >>> obj = rbf.Tetra()  # get a tetrahedron
  >>> obj.draw(povwriter)

But internally to obj.draw(povwriter), I'm invoking povwriter on the various
edges, vertices and faces of my obj:

  def draw(povwriter):

     for e in self.edges():
         povwriter.edge(e)

     ...

and like that.

The upside of this design is if I go obj.draw(vrmlwriter), then the same
object gets output in VRML syntax.

In sum, when writing geometric objects to output media, there's a way to go
wherein anything specific to the medium is saved to the "writer" object,
while anything purely geometric, and common to all media, is saved in the
geometric object.  The pure geometry is kept separate from the messy details
of I/O.

I'm just bringing this up as a by the way.  I'm not saying Zelle should have
done this in his text book. 

It'd be a fruitful discussion for CS2 level course -- when we're talking
about design patterns.

Kirby