Chapter 3

Size Matters

Many modules try to do too much. Instead of being useful tools, they're more like 

overflowing toolboxes. They're hard to learn, hard to implement, and painfully slow to 

load. Even if they provide undeniably useful services, their bulk limits their utility.

The best modules do one thing and do it well. As a result, they are easy to use 

and easy to implement. The trick is to break your problem down into pieces that 

are small enough to make good modules but no smaller. If you create too many 

small modules, you'll end up back in the spaghetti bowl where you started!

A good test for module complexity is to try to describe what the module does. 

If it takes more than a clause or two, then you've got something that's too compli 

cated to be just one module. For example,  an interface to the Acme Products 

Database  would make a fine module. On the other hand,  an interface to the Acme 

Products Database that functions as its own Web server and accepts orders via CGI 

and e mail  would not. Of course, it's possible to find a compact expression for an 

impossibly large module. For example,  a complete replacement for Linux  would 

not make a good Perl module! Although the description is simple, the scope of the 

module is vast.

The process of taking a system and breaking it down into component pieces is 

called factoring. It doesn't stop once you've decided to create a module. The next 

task is to break the functionality of your module down into subroutines (or methods 

in the case of an OO module) that will form the interface. At this point you might 

find that your module requires a large number of subroutines (or methods). This 

may be a sign that your module is trying to do too much.

Factoring may sound like a science, but in practice it is much closer to an art. 

It owes more to composition in the visual arts than it does to any particular engi 

neering discipline. Over time you'll develop a taste in module size and shape that 

will guide you. Until then, keep it simple and don't be afraid to refactor when your 

modules grow!

Document First

The easiest way to make sure you've got a workable design is to start writing the 

documentation. If you can explain it in the docs, then there's a good chance you'll 

be able to code it. When you get stuck writing the documentation, there's a good 

chance you've discovered a flaw in your design. This is an excellent time to fix 

design flaws there's no code to rewrite and very little effort wasted.

66