[Tutor] design?--having subclassed methods add logic in the middelof class methods

Alan Gauld alan.gauld at freenet.co.uk
Tue Feb 22 05:46:13 CET 2005


> All code below is pseudo-code.
>
> Is this an acceptable design for doing this?
>
> # in Node class
>
> def _parse(self, list_of_lines):
>
>      # some parsing based on whole list_of_lines
>
>      for line in list_of_lines:
>          _subclass_preparse(line)
>          # Do line parsing stuff here
>
> def _subclass_preparse(self, line):
>      '''Dummy method to override'''
>      pass
>
>
> # in Subclassed_Node class
>
> def _subclass_preparse(self, line):
>     '''Subclassed_Node class specific parsing, overrides Node
method.'''
>     # Do special parsing of the line here here
>
> Does this scream `Danger -- spaghetti code will result down the
road'?

This is a perfectly normal approach. It is even formalised in some
Lisp
OO dialects which have BEFORE, AROUND and AFTER methods. They work
like this:

class Parent:
  def myMethod(...)

class Child_A(Parent)
  def myMethod(BEFORE,...)  # always execute before Parent method

class Child_B(Parent):
  def myMethod(AFTER,....)  # always execute afyter parent method

class Child_C(Parent):
   def myMethod(AROUND,...) # only execute parent if I explicitly call
it

Languages without such support use a system of *hooks*, which is
what you have done

class Parent:
   def pre_Method(...): pass  # only for overridding
   def method(...):
      self.preMethod()
      # code here
      self.postMethod()
   def postMetrhod(...): pass  # only for over ridding

> The method name containing `preparse' indicates I might also feel a
> need for a `postparse' structure, too.

Absolutely.

Alan G.



More information about the Tutor mailing list