From: Aureliano Calvo <aurelianocalvo@...>
Date: 2007-07-23T10:55:58+09:00
Subject: Re: Class Overkill? What's practical?

On 7/22/07, Todd Burch <promos@burchwoodusa.com> 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.