Hmm, where have I heard this before? I thought you were already talking about changes. My experience is that once a program is useful, people will come up with more and different things they want it to do. Assume it's going to change.
There's roughly two different things you can do with a module: define new packages (also called namespaces or classes) with their own subroutines (and maybe local data) and/or add subroutines (and maybe data) to existing packages (like especially 'main'). You can accomplish the same thing with code in a single large program, except that it's bigger, harder to find things, and impossible to re-use that way. By breaking up your program into modules, you can re-use common functionality. If you've designed it right, that is (modules are no guarantee of reusability, any more than object design is).
I use object-oriented design, in which I view my programs as a group of collaborating objects which call on each other to get the job done. Objects have a single responsibility.
Inheritance (@ISA in Perl) can be used where you have common behavior that you want to share between packages. You can put common behavior in one package, and inherit others from that one, adding specialized behavior to each of them.
I don't know your program, but one way to start breaking it up might be to ask where do I have behavior that might change for different platforms or hardware?. If you have several kinds of barcode readers, for instance, you might have a common package ("base class" in object-speak) that several reader-specific packages inherit from. Whether you put these in separate files or the same file depends mostly on how comfortable you are with the file sizes and number of files. It's easy to change later, assuming you don't share lexical variables between multiple packages in a single file.
In reply to Dividing programs into modules
by bikeNomad
in thread Project management
by Ea
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |