perltoot - Tom's object-oriented tutorial for perl
Object-oriented programming is a big seller these days. Some managers would rather have
objects than sliced bread. Why is that? What's so special about an object? Just what is
an object anyway?
An object is nothing but a way of tucking away complex behaviours into a neat little
easy-to-use bundle. (This is what professors call abstraction.) Smart people who have nothing to
do but sit around for weeks on end figuring out really hard problems make these nifty objects
that even regular people can use. (This is what professors call software reuse.) Users (well,
programmers) can play with this little bundle all they want, but they aren't to open it up and
mess with the insides. Just like an expensive piece of hardware, the contract says that you void
the warranty if you muck with the cover. So don't do that.
The heart of objects is the class, a protected little private namespace full of data and
functions. A class is a set of related routines that addresses some problem area. You can think
of it as a user-defined type. The Perl package mechanism, also used for more traditional
modules, is used for class modules as well. Objects "live" in a class, meaning that
they belong to some package.
More often than not, the class provides the user with little bundles. These bundles are
objects. They know whose class they belong to, and how to behave. Users ask the class to do
something, like "give me an object." Or they can ask one of these objects to do
something. Asking a class to do something for you is calling a class method. Asking an
object to do something for you is calling an object method. Asking either a class
(usually) or an object (sometimes) to give you back an object is calling a constructor,
which is just a kind of method.
That's all well and good, but how is an object different from any other Perl data type? Just
what is an object really; that is, what's its fundamental type? The answer to the first
question is easy. An object is different from any other data type in Perl in one and only one
way: you may dereference it using not merely string or numeric subscripts as with simple arrays
and hashes, but with named subroutine calls. In a word, with methods.
The answer to the second question is that it's a reference, and not just any reference, mind
you, but one whose referent has been bless()ed into a particular class (read: package).
What kind of reference? Well, the answer to that one is a bit less concrete. That's because in
Perl the designer of the class can employ any sort of reference they'd like as the underlying
intrinsic data type. It could be a scalar, an array, or a hash reference. It could even be a
code reference. But because of its inherent flexibility, an object is usually a hash reference.
In the various OO literature, it seems that a lot of different words are used to describe
only a few different concepts. If you're not already an object programmer, then you don't need
to worry about all these fancy words. But if you are, then you might like to know how to get at
the same concepts in Perl.
For example, it's common to call an object an instance of a class and to call those
objects' methods instance methods. Data fields peculiar to each object are often called instance
data or object attributes, and data fields common to all members of that class are class
data, class attributes, or static data members.
Also, base class, generic class, and superclass all describe the same
notion, whereas derived class, specific class, and subclass describe the
other related one.
C++ programmers have static methods and virtual methods, but Perl only has class
methods and object methods. Actually, Perl only has methods. Whether a method gets
used as a class or object method is by usage only. You could accidentally call a class method
(one expecting a string argument) on an object (one expecting a reference), or vice versa.
From the C++ perspective, all methods in Perl are virtual. This, by the way, is why they are
never checked for function prototypes in the argument list as regular builtin and user-defined
functions can be.
Because a class is itself something of an object, Perl's classes can be taken as describing
both a "class as meta-object" (also called object factory) philosophy and the
"class as type definition" (declaring behaviour, not defining mechanism)
idea. C++ supports the latter notion, but not the former.
Directory and resources for homeschool curriculum
and information. What is 1031 exchange and
information. Buying tips for bar code scanners.
The following manpages will doubtless provide more background for this one: perlmod, perlref, perlobj, perlbot, perltie, and overload.
perlboot is a kinder,
gentler introduction to object-oriented programming.
perltooc provides more
detail on class data.
Some modules which might prove interesting are Class::Accessor, Class::Class, Class::Contract,
Class::Data::Inheritable, Class::MethodMaker and Tie::SecureHash
Copyright (c) 1997, 1998 Tom Christiansen All rights reserved.
This documentation is free; you can redistribute it and/or modify it under the same terms as
Irrespective of its distribution, all code examples in this file are hereby placed into the
public domain. You are permitted and encouraged to use this code in your own programs for fun or
for profit as you see fit. A simple comment in the code giving credit would be courteous but is
Thanks to Larry Wall, Roderick Schertler, Gurusamy Sarathy, Dean Roehrich, Raphael Manfredi,
Brent Halsey, Greg Bacon, Brad Appleton, and many others for their helpful comments.