Thanks, Alan. That's exactly the kind of explanation I was looking for. As this is pretty much a one-off project and the data transformations are pretty different for each field, I'll stick with the functional approach. The rule of thumb you mention is useful, too. I hadn't heard that before.
On Jan 23, 2006, at 2:53 AM, Alan Gauld wrote: >> I'm processing a tab-delimited text file where I read in a file, >> perform a bunch of operations on the items, and then write them >> out again to a fixed-width text file. >> I've been doing this with a very functional approach: >> Anyway, this all works fine. Not knowing much about OO, I'm >> wondering if there's a way to approach this from an object- >> oriented perspective. Is there anything to be gained? Or is this >> type of problem best tackled with a functional approach? > > This is one of the types of problem where I personally don't try to > use objects too much. Where objects might be helpful is if you have > a number of similar but slightly different data records such that > the processing consists of lots of if/elif chains. In that case > identifying the type once and relying on polymorphism to deal with > the differences is useful. But if the records all have similar > processing then OOP will make the code bulkier, slower and not add > too much IMHO. > > OTOH if you were to write a lot of these kinds of applications OOP > might provide a higher level of code reuse between projects.... But > remember that the cost of reuse means that you need to reuse code 3 > (*) or more times to make it economical! > > (*) Metrics suggest the actual figure varies between 3-10 times > depending on language, object complexity and level of generality. > > HTH, > > Alan G > Author of the learn to program web tutor > http://www.freenetpages.co.uk/hp/alan.gauld > > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
