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






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

web hosting perl

 

Our partners: PHP: Hypertext Preprocessor Best Web Hosting Java Web Hosting Inexpensive Web Hosting  Jsp Web Hosting

Cheapest Web Hosting Jsp Hosting Cheap Hosting

Visionwebhosting.net Business web hosting division of Web Design Plus. All rights reserved