[Tutor] help with refactoring needed -- which approach
kent37 at tds.net
Thu Feb 10 11:52:51 CET 2005
Alan Gauld wrote:
>>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
> 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:
> 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):
> def parse(self):
> # your parsing method here.
You might want to extend list so a Node automatically has the behavior of a list.
More information about the Tutor