[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