Why a class when there will only be one instance?

SeeBelow at SeeBelow.Nut SeeBelow at SeeBelow.Nut
Wed May 26 00:54:06 EDT 2004


Dave Harris wrote:
> 
> Mitchell Timin wrote:
> > I see the value of a class when two or more instances will be created,
> > but Python programmers regularly use a class when there will only be one
> > instance.
> > What is the benefit of this?  It has a disadvantage of a whole lot of
> > "self."
> > being required everywhere, making the code less readable.  Also, since a
> > strength of Python is rapid application development, it slows one down
> > to have to put in all those self.'s.  The code seems much cleaner to me
> > without classes that have only one instance.  Oh, also, all the methods
> > of this class will have to have the instance name prepended to them.
> >
> > I would appreciate it if someone could explain the advantages of doing
> > this, or at least the sociological reasons why it occurs.
> 
> I may very well be the person prompting this question -- Mitchell has been
> reviewing some Python code I wrote. As a matter of fact, I asked myself the
> same question, wondering if I was slavishly using a technique that
> obfuscates the code.
> 
> In particular (and this may remind list readers of an embarrassing recent
> post by me), I have a window with multiple Frames. Two of the frames,
> CourseView(Tk.Frame) and DetailView(Tk.Frame) contain independent Canvas
> objects. The views have different origins and I found it very convenient to
> set up instance variables named xoffset and yyoffset for coordinate
> translations. The names are meaningful (to me) and serve the same purpose in
> each Canvas. This seems minor, but the idea extends to other orthogonal
> relationships.
> 
> The most likely non-class alternative leads to longer function names which
> slow down comprehension and inflate the namespace. For example, instead of:
> 
> courseView = CourseView(frame)
> courseView.pack()
> detailView = DetailView(frame)
> courseView.pack()
> courseView.drawAll()
> detailView.drawAll()
> 
> I might have to resort to:
> 
> courseView = Frame(frame)
> courseView.pack()
> courseView.canvas = Canvas(courseView)
> courseView.canvas.pack()
> detailView = Frame(frame)
> detailView.pack()
> detailView.canvas = Canvas(detailView)
> detailView.canvas.pack()
> drawAllCourseView(courseView)
> drawAllDetailView(detailView)
> 
> (I'm almost positive I made this look as bad as I possibly could. Another
> embarrassment?)

You left out the code required to define the two classes, CourseView &
DetailView.  When that code is added to the upper version, then it
becomes lengthier and more obscure than the lower version, IMO.

I admit the lower version is not real clear to me.  courseView is an
instance of Frame, as is detailView.  How can you tack a .canvas onto
it?  I suppose canvas is an instance variable, and you have to know
that, and know that it is supposed to become and instance of the Canvas
class? 

Mitchell Timin

<snip>
-- 
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca



More information about the Python-list mailing list