From: John Joyce Date: 2007-07-23T21:29:16+09:00 Subject: Re: Class Overkill? What's practical? On Jul 22, 2007, at 8:55 PM, Aureliano Calvo wrote: > On 7/22/07, Todd Burch wrote: >> I've hacked out a monolithic script to parse a 3D file and create a >> custom bill of materials spreadsheet using win32ole and Microsoft >> Excel. >> Neat stuff. Very fast. Lots of methods - all of them defaulting >> to the >> Object class. >> >> Now, I'm in the process of properly coding the program (rewriting >> it), >> and creating classes and methods, and trying to pidgeon hole my >> existing >> code into a structure that could be called object oriented. >> >> I'm fretting over how many classes I actually need. Here are the >> classes I'm thinking I should have: >> >> 1) a class to represent the 3D file and methods for reading & >> validating >> it >> >> 2) a class to represent the resultant bill of material >> spreadsheets (in >> Excel terms a "WorkBook") that will have multiple sheets, with >> methods >> for colorizing, setting cell attributes, etc. >> >> 3) a class to represent the Excel file that is the lookup table, or >> catalog, of all items that could possibly make up a bill of >> materials, >> with methods for opening, closing, reading the headings, and item >> names, >> etc. >> >> 4) a class to represent the connection from Ruby to Excel that >> contains >> the methods for calling Excel, establishing the connection to Excel, >> quitting excel, etc. >> >> 5) I could have a class for all the headings in the catalog file that >> keep track of the column number >> >> 6) I could have a class for all the item names in the catalog >> file, and >> keep the row number >> >> But, then I have sections of code that "cut" data from the catalog >> sheet >> and "paste" it into the bill of materials sheet, and which class do I >> put that method in? >> >> I'm not making a general purpose library for distribution to John Q. >> Rubyist. It's for my use, and I will most likely create another >> bill of >> materials script for another user in the future, and most certainly, >> while the concepts might be the same, the specifics will change. For >> intance, it might use a MySQL database for the catalog data >> instead of >> an Excel spreadheet. Or, I might use Google Spreadsheets on the next >> one instead of Excel. Therefore, I want to structure the thing to be >> reusable, but I don't want to go crazy with it. >> >> So, I'm object-orientedly confused. Help! >> >> Thanks, Todd > > I think that you need to do nothing. Just make sure that you > understand the script when you read it. If you need to do a second > script that shares things, factorize when needed. I strongly suggest > that you do some automated tests to check that the original script is > not being broken (noting fancy, just a couple of examples with its > expected output). Factorizing before the need is over abstracting. > Over all though, truckloads of methods can still be used in their own right. Yes they should probably get moved to classes, but they are already object-like in Ruby anyway. Functional programing in Ruby is much closer to OOP than in most languages. So it should be easy to change it and change it again. Do continue to take it seriously. Class design should be pretty careful, but Ruby makes it fairly painless.