Module Design and Implementation

why you're not using it. You might also use this as a chance to explain any design 

goals that might not be obvious from the module description. Such a section 

might look like this:

=head1 RATIONAL

The CPAN module Net::SETI seems on the surface to provide the same

functionality as BOA::SETI, but in actuality Net::SETI only works over a

TCP connection.  The BOA application requires greater performance than can

be achieved using TCP so the decision was made to implement our own module.

Writing down your rational for building the module forces you to critically 

examine your design choices before it's too late to reverse them. Also, your users 

will be less likely to reject your module if they understand why your wrote it in the 

first place. Any time you can spend convincing your fellow programmers to stop 

reinventing the wheel is time well spent!

Interface Design

Design a good interface, and everything else is negotiable. If your first pass at the 

implementation is flawed, no big deal; you improve it, and your users get a 

painless upgrade. Design a bad interface, and your module is doomed to use 

lessness. It doesn't matter how fantastic your implementation is no one can 

figure out how to use it and no one will.

This property of a module, that the internals may change without affecting 

users of the module, is known as encapsulation. Encapsulation is often associated 

with object oriented programming, but any well designed module can benefit 

from it. A module's interface is the barrier between users and the module's internals 

that allows for encapsulation.

Functions or Objects?

You might not have to think about this question you might be an OO true believer. 

My introduction to the Church of Pure Objects came on my first day as a computer 

science student. The guy sitting next to me in CS201 greeted me with  Do you 

uphold the object model?  I thought for a moment and said  Ah, sometimes.  His 

eyes narrowed. I was clearly the enemy.

73

73