Chapter 3

Even if you don't use inheritance in your module, you should be ready for it. 

You should design your module with the expectation that some users will use it as 

a parent class for their creations. At the very least, this means using the two argument 

form of bless() and using isa() to check the type of objects rather than ref().

Better yet, document your private methods and object layout so that subclasses 

can avoid breaking the rules.

Designing a Method

Methods in Perl are subroutines, so all the advice about subroutine design and 

construction in the section on functional modules applies here. Of course, methods 

aren't just subroutines; depending on your outlook, they might be messages 

passed to the object, actions performed by the object, or actions performed on the 

object. Nailing your metaphors is the key to designing powerful methods. Be con 

sistent and be explicit about your choices in your documentation.

Consider, as an example, an object oriented implementation of the check_mail()

function presented previously. To refresh your memory, this function is called 

as follows:

check_mail(imap_sever => $imap_server,

           username   => $username,

           password   => $password,

           retries    => 3);

One possible object oriented approach to this functionality would encapsulate 

the parameters in attributes of a mail checking object. For example:

my $checker = MailChecker >new();    # create a new MailChecker object

$checker >imap_server($imap_server); # set up attributes

$checker >username($username);

$checker >password($password);

$checker >retries(3);

$checker >check();                   # check mail

This design has a few problems. First, what happens if you call check() before 

calling imap_server()? Second, this system is considerably more verbose than the 

functional example. To solve these problems, the constructor should be written to 

take attributes as parameters:

84