I typically think in objects when I develop my systems. As a result, I spend more than 99% of my time creating classes from where I instantiate objects.
I do have a similar problem as yours, since I constantly ask myself when I should bring out a class from my application source file and make it a separate module file.
When I write a new class for the first time, I try to think if I can make it generic so that it could be reused by a future application and more often than just often this is the case.
If I don't immediately see the usage for the class in another application, I tend to keep the class in the original application's source file. At the first occurence of reuse, I have a very small effort to cut out the class and put it in it's own module file.
There is a small disadvantage with a module file; Distribution and installation. Especially to remote systems and when you have different systems for development, integration test and production. (Which is my case.)
On the other hand, if the class/module can be reused in more than one application, the reuse related advantages almost immediately outweights the distribution and logistics costs/efforts.
In reply to Re: Perl Module Useage
by Biker
in thread Perl Module Useage
by gawatkins
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |