So, where do you go from here? Here's a brief list of topics,
presented in no specific order, that you may now want to pursue
in search of further module knowledge.
Object Oriented Design
We mentioned at the outset that you didn't need to be an OOP guru to create
modules. But the fact of the matter is, having worked your way through this
tutorial you already know a good portion of what you need to know to implement
an object oriented module. For example, in Perl OOP, packages are
classes; and a reference (such as a hash reference) becomes an object
when it is blessed into a class. From then on, all of the methods
(i.e., the sub routines) that exist in that class (i.e. package) are accessible
through the object itself; with the object automatically passed to the method
as a reference (so you can access the object from within the method). And
we saw a simplified use of inheritance via the @ISA variable on the
bottom of the previous page. Once you've coded up a module or two of your
own (or even before then, if you have an OOP background and/or are particular
adventurous), I encourage you to have a look at the bless command
and the general definition and use of objects in Perl.
Document Your Work!
Modules are intended to be encapsulated, functional collections of code.
But even if your module is perfectly designed, it will be useless if the next
person who comes along doesn't know what functions your module contains or
how to access and use them. An excellent way to make this type of information
available to everyone who wants to get it is to use Plain Old Documentation,
or POD. POD statements are embedded within your module itself, and can be
automatically read by specific perl utilities such as perldoc allowing
users to easily see what your module does and how it does it (and anything
else, within reason, that you want to tell the would-be user).
AUTOLOAD and AutoLoader
Perl provides a mechanism such that if the user calls a routine that doesn't
actually exist within a package, then a specific routine, called AUTOLOAD
is run instead. The AutoLoader module takes this concept a step
further, allowing you to separate chunks of your module into smaller components
that can then be pulled into the script as they are needed, as opposed to loading
your entire module in every time it is used. This can be helpful when your modules
get very large, as it can reduce the overall memory requirements of the calling
application.
I hope you've found this brief tutorial to be helpful. Good luck in your efforts
to build your own module-based projects!
