The main change in refactoring is moving it to OOP. I have a method that serves as the entry point for parsing the files.
Not an object? If you are thinking terms of what the methods do its probably not OOP...
I would expect to see an object for the File, another for the Header, a third for the Body and another for the Node. The first (containing a header and bosdy object) is responsible for cracking open the file and reading the lines, recognising where it has a header and sending those lines to the header object and the rest to the bosy object.
The body object then reades those lines and creates a Node object per node feeding it lines as appropriate...
This is a reasonable approach. Having the Body and Node classes gives a handy place to put functions to do something with that data. But I tend to take the Extreme Programming position of You Aren't Going To Need It. I would probably stick with the list representation of Node, for example, until I had some real work for the Node class to do.
It's definitely a judgement call when to introduce classes, there isn't a right way and a wrong way. Some problems cry out for classes, some clearly have no need, and then there is a gray area in the middle.
Pseudo code: class Body: def __init__(self,content): self.contents = contents self.nodes = []
def parse(self): for line in self.contents: if line == NodeStartTag: node = Node() if line == NodeEndTag: self.nodes.append(node) node.append(line)
def __del__(self): del self.nodes
Why is 'del self.nodes' needed? When the Body is del'ed the reference to self.nodes should be lost and the nodes list will be GC'd. Or am I missing something?
class Node:
def __init__(self,lines=[]):
self.lines = lines
def append(self,item):
self.lines.append(item)
def parse(self):
# your parsing method here.
You might want to extend list so a Node automatically has the behavior of a list.
Kent
_______________________________________________ Tutor maillist - [email protected] http://mail.python.org/mailman/listinfo/tutor
