Re: Hacking with objects

[mothra]

By the sounds of it, the coding that you do is done on tiny tasks, for which OO isn't really meant, IMHO.

In my (day job) situation, we're using OO for a project (that doesn't use Perl, because it features a few stupidly complex GUI widgets in it :) that has over 200 stored procedures behind it, a 30 tablish database, and about 20,000 lines of code (ballpark). OO works quite well for it though.

For example, my current task is to write an abstraction layer for creating database tables from the source code (rather than in the procs). The OO paradigm is nice here, because the interface to creating these tables (via the set of objects I'm creating to encapsulate this process) can stay exactly the same whilst the database vendor should change, or a version upgrade should change the SQL statements necessary to create tables.

OTOH, a "side job" I'm doing is a simple CGI shopping cart site (maybe 500-600 lines of Perl, if that), for which I haven't even considered OO because it would be overkill.

Overall, I really like the OO paradigm because to me it seems like a natural way of thinking about the way pieces interact within a complex system. But for small administrationish type scripts (or simpler CGI scripts), unless you have time to burn (or want to learn something fun), don't OOverdo it. :P