to use or not to use, a module?

[bazz]

Hello folks,

with about three, soon to grow to around ten, perl scripts, several of the subs are common to all codes. I think this is probably a silly question but should I put the sub routines in their own modules and pull them into each script on parsing them?

Would the disadvantages potentially mean that load potential would be reduced as the 1 module would be used much more often than if placed in each code?

Would the advantages of doing this include:

1. simpler update
2. simpler addition of new features

I hope to reach a point shortly, when I shall not have to look at them for some months (Yay!) I am hoping that putting it into modules might make it easier to pick up again in a few months.

But, perhaps there might be drawbacks to this?

Your views would be appreciated.


Bazz

[Jeff Mott]

On the topic of performance, computers today are comparatively so fast that a function call versus inlined code is insignificant. Compilers usually make many of these small optimizations for you, anyway. And especially for a language as high-level as Perl is; you need to think about the algorithm more than the nanosecond speedups. So you should really focus on building the program in a way that makes it easier to understand, maintain, and expand. Because I guarentee you this will be the part that will cost the most time.

If you do put together a module of your own it shouldn't simply be a collection of miscellaneous subroutines, it should represent a logical entity with specific attributes and actions.

For an example, consider a module (or class) for a post. Not even necessarily for a guestbook, forum, blog, or whatever; just a generic post. It could have methods getForm and toHtml. This would allow what input should be taken in and how that information should be presented when going out to all be controlled from one central location. With this setup you could also distinguish Post->getForm(), which would return a blank form, versus $post_obj->getForm(), which could return a form preloaded with the values of that particular post.

Additionally, perhaps a post repository. This might have methods such as add($post_obj), get('post-ID'), remove($post_obj). The benefit here is that the real database accessing routines that are intertwined throughout a program are all collected in one place. This would allow you to change from one database to another (if necessary) completely transparently to the rest of the program.

This also makes it far easier to pick up again later on, or even for a brand new developer looking at it. You don't have to learn the entire program to understand a single module, and you don't have to learn how the insides of these modules work to learn the main program.

[bazz]

Great Jeff.

The sub routuines that are common to the files, each perform just one function, be that to ouput a specific section of html to the page or to perform a specific function.

Each, effectively, is a single 'building block' of code for the scripts and if one sub were to need to be changed, all of those files which yuse that sub, would have to be changed also.

In addition, each has its own locally-global variables so that in the future, everything a developer should need to understand about the individual module, to modify or just update the sub, is held within it.

So I think in my case - with my interpretation of your answer - it means that I would be better to put some of the subs in a module of their own so that I would have perhaps six modules, instead of perhaps, 40 sub routines.

This forum and its contributors, just get better and better.

Thanks Jeff

Bazz