|
|
Anonymous Subroutines, Closures, and Privacy
Public User Interface—Documenting Classes
Using Objects from the Perl Library
The big addition to Perl 5 was the ability to do object-oriented programming, called OOP for short. OOP is centered on the way a program is organized. Object-oriented languages, such as C++ and Java, bundle up data into a variable and call it an object. An object can be described as a noun in English: a person, place, or thing. A cat, a computer, and an employee are objects. Adjectives describe nouns. For example, the cat is sneaky, the computer is fast, the employee is called "John." In OO languages, the adjectives that describe the object are called properties, also called attributes. Verbs that describe what the object can do or what can be done to it are called methods in OO. The cat eats, the computer crashes, the employee works. Perl methods are just specialized subroutines.
The object's data is normally kept private. Messages are sent to the object through its methods. The methods are normally public. The only way that a user of the program should access the data is through these public methods. If you have an object called "money", the methods might be earnit(), findit(), stealit(), etc.
The data and the methods are packaged up into a data structure called a class. A Perl package will function as a class when using the object-oriented approach. This is not really a new idea for Perl, since data is already encapsulated in packages. Recall from our short discussion of packages that a package gives a sense of privacy to your program. Each package has its own symbol table, a hash that contains all the names in the "current" package. This makes it possible to create variables and subroutines that have their own namespace within a package. When using different packages within your program, each package has its own namespace, thus protecting the accidental clobbering of variables with the same name. The idea of hiding data in packages, then, is inherently part of Perl and also happens to be one of the basic tenets of object-oriented programming.
Every Perl program has at least one package called main, where Perl statements are internally compiled. The standard Perl library consists of a number of files containing packages. Most of these files are called modules. A module is really just a fancy package that is reusable. The reuse of code is done through inheritance; that is, a package can inherit characteristics from a parent, or base, class and thus extend or restrict its own capabilities. The ability to extend the functionality of a class is called polymorphism. Hiding data (encapsulation), inheritance, and polymorphism are considered the basic tenets of the object-oriented philosophy.
To create a Perl module, you still use the package keyword, and the scope is from the declaration of the package to the end of the enclosing block or file. Packages normally are the size of one file. The files can be recognized as modules if their names end with a .pm extension and if the first letter of the module is capitalized. Pragmas are another special kind of module (the name is spelled in lowercase but still has the .pm extension) that directs the compiler to behave in a specified way. Whether the package is called a module or a pragma, it has some special features that differentiate it from an ordinary package. Those special features introduced in Perl 5 give you the ability to model your programs with the object-oriented way of abstract thinking. You can think of procedural languages as action-oriented and OO languages as object-oriented.
Tom Christianson, discussing Perl and objects on his Web page "Easy Perl5 Object Intro," says that people tend to shy away from highly convenient Perl 5 modules because some of them deal with objects. Unfortunately, some problems very much lend themselves to objects. Christianson says that people shouldn't be scared by this, because merely knowing enough OO programming to use someone else's modules is not nearly as difficult as actually designing and implementing one yourself.[1] Even if you are not interested in writing programs that take advantage of the OOP features of Perl but still need to use Perl modules that do utilize objects, reading through this chapter should greatly enhance your understanding of how these modules work.
[1] Go to www.perl.com/CPAN-local/doc/FMTEYEWTK/easy_objects.html to see Tom Christianson's Web page.
Object-oriented programming is a huge subject. Thousands of books have been written on OO programming, design, and methodology. Many programmers of the 1990s moved away from traditional top-down structured programming and toward object-oriented programming languages for building complex software. This is not a book on object-oriented design or programming. However, there are some basic key words associated with OOP that should be mentioned before tackling Perl's OOP features. They are listed in Table 14.1.
|
|