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:
a class to represent the 3D file and methods for reading & validating
it
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.
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.
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.
I could have a class for all the headings in the catalog file that
keep track of the column number
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.
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?
In reading that description I picture something like:
bom_sheet << catalog_sheet.cut(some_params)
The catalog sheet would know how to provide some data from itself, and
the bill of materials sheet would know how to insert data into itself.
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.
I would recommend keeping it quite specific, and then generalizing it
later. I always find, at least, that generalizing becomes sort of a
project of its own, so it feels like I’m working on two things at
once, if I try to do it all at the same time.
I’m fretting over how many classes I actually need. Here are the
classes I’m thinking I should have:
a class to represent the 3D file and methods for reading & validating
it
Very good.
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.
Very good.
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.
Very good.
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.
Very good.
I could have a class for all the headings in the catalog file that
keep track of the column number
I could have a class for all the item names in the catalog file, and
keep the row number
5 and 6 should be apart of a “Catalog” class, if I understand your
design correctly.
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 would probably put it into the “Bill Of Materials” class so that it
can “get
from Catalog”. Make your objects do things rather than have things
done to them.
Hope that has helped.
For future reference, take a look at the Unified Modeling Language.
It’s a good
way to develop OO applications:
And a good book:
Ambler, Scott William (2004). The Object Primer: Agile Model Driven
Development
with UML 2. Cambridge University Press. ISBN 0-521-54018-6.
Travis W.
“Programming in Java is like dealing with your mom –
it’s kind, forgiving, and gently chastising.
Programming in C++ is like dealing with a disgruntled
girlfriend – it’s cold, unforgiving, and doesn’t tell
you what you’ve done wrong.”
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
classes I’m thinking I should have:
with methods for opening, closing, reading the headings, and item names,
keep the row number
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.
and creating classes and methods, and trying to pidgeon hole my
2) a class to represent the resultant bill of material
etc.
file, and
materials script for another user in the future, and most certainly,
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.
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.
I agree with the sentiment of “don’t make too much more work for
yourself,” but OP says he expects to “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.” So it wouldn’t
be unwise, unnecessary, or overdoing it do factor it now, especially
if he has time now.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.