NEWBIE: What's the instance name?

[Alan Gauld]

On Mon, 29 Dec 2003 11:03:46 -0800, engsolnom at ipns.com wrote:

> As to the (good) suggestions I use :
> 
> lx = UPCA(<string>)
> lx.display()
> 
> I considered this approach. The reason I rejected it is that the
> actual program has a total of 13 UPCA-like classes (different names,
> of course). 

So you have an inheritance heirarchy?


> In use, each class may have one or many instances at a
> time, as determined by the user script. My idea was to include the
> calling instance 'name' in the display ...not strictly needed, but a
> nice touch.
> 
> I could use:
>  display(lx, 'lx')

So you could add a name parameter to the method and do:

lx.display('lx')

> Why the display in the first place? The user *may* desire to display
> the class output, probably most often while trouble-shooting a user
> script problem.
> 
> Some of the classes have a common (or near common) display routine,

So OOP to the rescue and only write it once at the appropriately
common point in the inheritance heirarchy. 

> others are totally different. 

And override it for the unique cases.

> If I use lx.display(), the display code has to be contained as a 
> method in each class. 

Which is good becausae if the data in the class changes you 
can change the display method (or add a new override if it 
was using a common one) at the same time in the same place.
The display method is tightly coupled to the internals of 
the class so should be kept with the class.

> I chose, for ease of maintenance, to make a display module 
> with all the display routines gathered together in one spot. 

In fact that will almost certainly make it harder to maintain,
because the most likely need to change a display method is
because the class itself has changed. Now you have to change the
class and change the display in a separate place. And if the
class programmer forgets to change display after making a change
it breaks! This is exactly the kind of maintenance scenario that
OOP tries to avoid

[Note: if you want to change how the display occurs(eg from
terminal to GUI) then the best way is to get display to return a
string which you can then externally write to console or text
widget as needed. In fact if this is for debugging you may want
to look at providing a custom repr() method. repr() is intended
for giving a programmers view and returns a string. Then you 
can dosplay your classes at the >>> prompt too for free.]

> needed to add a class/display, I feel there's less chance of his/her
> messing up the UPCA-like classes. 

Addimng a class is no problem since he could add a new display
method. EXtending an existing class should be done by inheritance
so that the origibnal code is not affected, and will simply
extend the display method...

class UPCA:
   def display(self, name = ''):
      # do it here

class newUCPA(UCPA):
   def __init__(self, foo):
      UCPA.__init__(self)
      self.foo = foo
   def display(self, name = '')
      UCPA.display(self,name)
      print self.foo

> I guess I'm a believer in classes/methods doing a limited number of things, 
> and doing them well.

Classes should manage their own data and that includes displayig
it if thats whats neeed. The minute you introduce extermnal
functions which access the innards of a class you have broken the
data hiding metaphor of OOP and introduced potential for
corruption of the data...

> Is that a C hang-over?

Probably! :-)

> Another idea might be to make a display base class, and inherit the
> proper display method in each UPCA-like class. But that still leaves
> the problem of passing the instance name to the display method.

You could use a mixin style (which is what you propose) but it
buys very little here. If your aim is to display the internal
data of the class then the class itself should do it, its the
only one who should know whats inside, to the rest of the world
(including the inherited display class) it should be a black box.

Alan G


Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld