Chapter 3

Aside from fulfilling religious obligations, object oriented modules do provide 

some benefits. If your module will need to maintain state between calls to the 

interface, then using objects might be a good idea. This was the case with the 

BOA::Logger example in the last chapter. Object oriented modules are also easier 

to extend through the magic of inheritance, which sometimes allows OO modules 

to be reused in situations where a functional

5

 module would be rewritten.

On the other hand, object oriented code is usually more complicated than an 

equivalent functional implementation. Doing OO means dealing with references 

and occasionally thinking about difficult topics like garbage collection and inher 

itance. Sometimes a module is more naturally expressed as a set of functions that 

can be exported into the caller's namespace. One easy test for this is to ask yourself 

if more than one object will ever be created by this module in a typical usage. If the 

answer is no, then chances are you don't really need to go the OO route.

Regardless of which way you choose to go, you should read through both of 

following sections. The dividing line between a functional interface and an object 

oriented one is exceptionally blurry in Perl. Topics in functional programming like 

parameter passing and subroutine naming have parallels in object oriented pro 

gramming. Conversely, object oriented programming techniques like inheritance 

can be useful in functional programming. Ultimately Perl makes little distinction 

between functional and object oriented modules; both are built on the same 

underlying technology packages and subroutines.

Functional Interfaces

A functional interface is defined by the subroutines it provides and the ways in 

which users can access them. Designing a functional interface is similar to designing a 

small programming language. The subroutines you provide form a grammar that 

is used to write programs in your module's domain. If you design a powerful and 

flexible grammar, then your users will be able to write powerful and flexible programs.

Subroutine Naming

In general, subroutines should be named with an action verb and, optionally, a 

noun

6

 for example, print_form(), connect(), find_cities(), and complain(). This 

allows the arguments to be treated as subjects and direct objects of the activity 

5. No need to send me angry e mail I know this isn't the best usage of  functional.  I'm actually a 

big fan of LISP, so I know about the real functional programming.  See Inline::Guile on CPAN for 

proof. Here I'm using the word as the opposite of object oriented in terms of Perl module design.

6. For object oriented methods, the noun is usually unnecessary a well named object does 

the trick. For example, $logger >print_log() has no advantages over $logger >print().

74