Forum: Ruby Class Overkill? What's practical?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
13b511cd4fff9f72326e38526b9701fa?d=identicon&s=25 Todd Burch (toddburch)
on 2007-07-23 01:29
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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2007-07-26 00:45
(Received via mailing list)
Hi --

On Mon, 23 Jul 2007, Todd Burch wrote:

> 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.


David
F05add2c1c1b613e8e318e9360eac5c2?d=identicon&s=25 Travis D Warlick Jr (Guest)
on 2007-07-26 00:46
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Burch wrote:
> 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

Very good.

> 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.

Very good.

> 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.

Very good.

> 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.

Very good.

> 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

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:

http://en.wikipedia.org/wiki/Unified_Modeling_Language
http://www.uml.org/

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 Warlick

  "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

iD8DBQFGo/8dWvapaOIz2YYRAjovAJ4/oljoctC/xWlJKvO+ClAwgbU7nQCgmxrr
SZ+A4Veyba7PSK4fVp3PQa0=
=XkuJ
-----END PGP SIGNATURE-----
69498abbf47d4967f8640317a58377dd?d=identicon&s=25 Aureliano Calvo (Guest)
on 2007-07-26 00:46
(Received via mailing list)
On 7/22/07, Todd Burch <promos@burchwoodusa.com> wrote:
> 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.
1c0cd550766a3ee3e4a9c495926e4603?d=identicon&s=25 John Joyce (Guest)
on 2007-07-26 00:46
(Received via mailing list)
On Jul 22, 2007, at 8:55 PM, Aureliano Calvo wrote:

>> 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.
5dbb7a37b65f9e4ed415a97ab39300e5?d=identicon&s=25 Kaldrenon (Guest)
on 2007-09-25 23:04
(Received via mailing list)
On Jul 22, 9:55 pm, "Aureliano Calvo" <aurelianoca...@gmail.com>
wrote:
> 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 topic is locked and can not be replied to.