Sounds to me like mostly a poor choice of objects. If you could do all of the work in a couple of pages, then designing a dozen modules is certainly overkill.
I think it'd be interesting to see your original version and the OO version (even as large as it is) to let people offer alternate designs that are still OO but not so bloated.
And, yes, you shouldn't be made to feel bad about writing a single script without using any OO. Now, if this was to be the first of many scripts that were going to be extended and maintained for years, then selecting a design philosophy that would almost certainly make the first script larger and take longer to write might well pay off in the long run. In such a case, in Perl, OO might well be the best choice for many of the components.
But even then, there is some merit to the idea of getting a working "prototype" up and running quickly if for no other reason than to help solidify your understanding of the situation, in hopes of helping to improve the design. Over-designing too early can certainly be as much of a problem as under-designing.
My strong preference for OO in Perl has little to do with OO (Perl's OO isn't very OO) and more to do with it being a good way to control namespace collisions and to make modules that can be flexible while being easy to use and being able to fit in a large project where they are likely to be used in more than one place in possibly conflicting ways.
I'll also add my OO pet peeve: Inheritance should mostly be considered a last resort (especially in Perl) despite the fact that nearly every elementary OO book makes it sound more like it should be your first choice.
- tye (but my friends call me "Tye")In reply to (tye)Re: OO 2 death?
by tye
in thread OO 2 death?
by Cestus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |