Thanks again for your thoughts Javier. You've certainly given me a mouthful to chew on :~) I was thinking more in terms of "OOP is about code reuse" and trying to equate the function approach to such with the class methods approach in a similar way. Obviously I have got my mind wrapped around the wrong tree.
I'm not actually looking for the best approach here - rather just trying to map a concept I'm familiar with to a new (to me) concept. The idea being than one learns from doing :') My initial thought that it would be a simple reusable code structure to re-map is shaping up otherwise. Thanks, Lee C On Jun 8, 2005, at 1:10 AM, Javier Ruere wrote: > Lee Cullens wrote: > > >> I was thinking of extending the learning exercise by re-factoring it >> as an OO approach, since it would contain a minimum altered method. >> Being new to OOP also though, I'm confusing myself with how that >> would be best accomplished. My thinking is that class/subclass >> method instances would replace the recursive functions approach, but >> have as yet not formed the coding in my mind. >> >> > > I can't imagine this either and, though I'm no OO guru, have never > considered that that an inheritance relationship could replace a > recursive function call. > > > >> I've read a lot on OOP, but seem to have a problem with the practical >> use of such in this utility. I'm undoubtedly creating a mountain of >> an ant hill in my mind, so any thoughts would be appreciated. >> >> > > I don't see any benefit from using OO in this case. Module level > functions (like you have now) are ideal in this case IMHO. > Maybe in a situation where you can benefit from OO it would be > crearer how to use it. Having state is usually a good sign. Working > with > several "things" which have a behaviour would be another. > Just for fun lets do it anyway. :) Directories and files could be > considered things, files could tell if they are files, links or > whatever > and directories could tell which subdirectories and files they have. > Also this objects could render themselfs to a proper string > representation we can directly output as a row. > So, in pseudocode, this would be something like: > > class File: > """File(name:str, parent:Dir) > > parent: The directory which contains this File. > name: The name of this File. > """ > def __init__(self, name, parent): > self._parent = parent > self._name = name > > assert exists(join(repr(parent), name)) > > def isLink(self): > return islink(self.path) > > [Rest of the is* functions.] > > def __str__(self): > return [...] > > class Dir: > """Dir(name:str, [parent:Dir]) > > parent: The directory which contains this File. > If omited, an absolute path is assumed. > name: The name of this File. > """ > def __init__(self, name, parent=None) > self._parent = parent > self._name = name > > assert isdir(join(repr(parent), name)) > > def getDirs(self): > return [...] > > def getFiles(self): > return [...] > > Now, both classes could inherit from a FSElement (or something) > but I > see no benefit in doing that. > The output functionality could also be in a different class: > > class CSVOutput: > def __init__(self, filename): > [validate for overwritting] > self._out = file(filename, 'w') > > def process(self, root): > for file in root.getFiles(): > self._out.write(str(file)) > > for dir in root.getDirs(): > self.process(dir) > > And the main: > > CVSOuput(argv[2]).process(Dir(mkAbsolutePath(argv[1]))) > > I'm very sleepy so this could all just be gibberish but I hope it > will help you get the idea. Ideally, functions should be very small, a > couple of lines, and object should be reusable. So moving the > rendering > to CVSOutput would be better. :) > > Javier > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor