3 perlboot - Beginner's Object-Oriented Tutorial
7 If you're not familiar with objects from other languages, some of the
8 other Perl object documentation may be a little daunting, such as
9 L<perlobj>, a basic reference in using objects, and L<perltoot>, which
10 introduces readers to the peculiarities of Perl's object system in a
13 So, let's take a different approach, presuming no prior object
14 experience. It helps if you know about subroutines (L<perlsub>),
15 references (L<perlref> et. seq.), and packages (L<perlmod>), so become
16 familiar with those first if you haven't already.
18 =head2 If we could talk to the animals...
20 Let's let the animals talk for a moment:
23 print "a Cow goes moooo!\n";
26 print "a Horse goes neigh!\n";
29 print "a Sheep goes baaaah!\n"
42 Nothing spectacular here. Simple subroutines, albeit from separate
43 packages, and called using the full package name. So let's create
46 # Cow::speak, Horse::speak, Sheep::speak as before
47 my @pasture = qw(Cow Cow Horse Sheep Sheep);
48 foreach my $animal (@pasture) {
60 Wow. That symbolic coderef de-referencing there is pretty nasty.
61 We're counting on L<strict|C<no strict refs>> mode, certainly not
62 recommended for larger programs. And why was that necessary? Because
63 the name of the package seems to be inseparable from the name of the
64 subroutine we want to invoke within that package.
68 =head2 Introducing the method invocation arrow
70 For now, let's say that C<< Class->method >> invokes subroutine
71 C<method> in package C<Class>. (Here, "Class" is used in its
72 "category" meaning, not its "scholastic" meaning.) That's not
73 completely accurate, but we'll do this one step at a time. Now let's
76 # Cow::speak, Horse::speak, Sheep::speak as before
81 And once again, this results in:
87 That's not fun yet. Same number of characters, all constant, no
88 variables. But yet, the parts are separable now. Watch:
91 $a->speak; # invokes Cow->speak
93 Ahh! Now that the package name has been parted from the subroutine
94 name, we can use a variable package name. And this time, we've got
95 something that works even when L<strict|C<use strict refs>> is
98 =head2 Invoking a barnyard
100 Let's take that new arrow invocation and put it back in the barnyard
104 print "a Cow goes moooo!\n";
107 print "a Horse goes neigh!\n";
110 print "a Sheep goes baaaah!\n"
113 my @pasture = qw(Cow Cow Horse Sheep Sheep);
114 foreach my $animal (@pasture) {
118 There! Now we have the animals all talking, and safely at that,
119 without the use of symbolic coderefs.
121 But look at all that common code. Each of the C<speak> routines has a
122 similar structure: a C<print> operator and a string that contains
123 common text, except for two of the words. It'd be nice if we could
124 factor out the commonality, in case we decide later to change it all
125 to C<says> instead of C<goes>.
127 And we actually have a way of doing that without much fuss, but we
128 have to hear a bit more about what the method invocation arrow is
129 actually doing for us.
131 =head2 The extra parameter of method invocation
137 attempts to invoke subroutine C<Class::method> as:
139 Class::method("Class", @args);
141 (If the subroutine can't be found, "inheritance" kicks in, but we'll
142 get to that later.) This means that we get the class name as the
143 first parameter (the only parameter, if no arguments are given). So
144 we can rewrite the C<Sheep> speaking subroutine as:
148 print "a $class goes baaaah!\n";
151 And the other two animals come out similarly:
155 print "a $class goes moooo!\n";
159 print "a $class goes neigh!\n";
162 In each case, C<$class> will get the value appropriate for that
163 subroutine. But once again, we have a lot of similar structure. Can
164 we factor that out even further? Yes, by calling another method in
167 =head2 Calling a second method to simplify things
169 Let's call out from C<speak> to a helper method called C<sound>.
170 This method provides the constant text for the sound itself.
175 sub sound { "moooo" }
179 print "a $class goes ", $class->sound, "!\n"
183 Now, when we call C<< Cow->speak >>, we get a C<$class> of C<Cow> in
184 C<speak>. This in turn selects the C<< Cow->sound >> method, which
185 returns C<moooo>. But how different would this be for the C<Horse>?
190 sub sound { "neigh" }
194 print "a $class goes ", $class->sound, "!\n"
198 Only the name of the package and the specific sound change. So can we
199 somehow share the definition for C<speak> between the Cow and the
200 Horse? Yes, with inheritance!
202 =head2 Inheriting the windpipes
204 We'll define a common subroutine package called C<Animal>, with the
205 definition for C<speak>:
212 print "a $class goes ", $class->sound, "!\n"
216 Then, for each animal, we say it "inherits" from C<Animal>, along
217 with the animal-specific sound:
222 # Not safe under `use strict', see below
225 sub sound { "moooo" }
228 Note the added C<@ISA> array. We'll get to that in a minute.
230 But what happens when we invoke C<< Cow->speak >> now?
232 First, Perl constructs the argument list. In this case, it's just
233 C<Cow>. Then Perl looks for C<Cow::speak>. But that's not there, so
234 Perl checks for the inheritance array C<@Cow::ISA>. It's there,
235 and contains the single name C<Animal>.
237 Perl next checks for C<speak> inside C<Animal> instead, as in
238 C<Animal::speak>. And that's found, so Perl invokes that subroutine
239 with the already frozen argument list.
241 Inside the C<Animal::speak> subroutine, C<$class> becomes C<Cow> (the
242 first argument). So when we get to the step of invoking
243 C<< $class->sound >>, it'll be looking for C<< Cow->sound >>, which
244 gets it on the first try without looking at C<@ISA>. Success!
246 =head2 A few notes about @ISA
248 This magical C<@ISA> variable (pronounced "is a" not "ice-uh"), has
249 declared that C<Cow> "is a" C<Animal>. Note that it's an array,
250 not a simple single value, because on rare occasions, it makes sense
251 to have more than one parent class searched for the missing methods.
253 If C<Animal> also had an C<@ISA>, then we'd check there too. The
254 search is recursive, depth-first, left-to-right in each C<@ISA>.
255 Typically, each C<@ISA> has only one element (multiple elements means
256 multiple inheritance and multiple headaches), so we get a nice tree of
259 When we turn on C<use strict>, we'll get complaints on C<@ISA>, since
260 it's not a variable containing an explicit package name, nor is it a
261 lexical ("my") variable. We can't make it a lexical variable though
262 (it has to belong to the package to be found by the inheritance mechanism),
263 so there's a couple of straightforward ways to handle that.
265 The easiest is to just spell the package name out:
267 @Cow::ISA = qw(Animal);
269 Or allow it as an implicitly named package variable:
272 our @ISA = qw(Animal);
274 If you're bringing in the class from outside, via an object-oriented
279 our @ISA = qw(Animal);
286 And that's pretty darn compact. Read about the L<base|base> pragma.
288 =head2 Overriding the methods
290 Let's add a mouse, which can barely be heard:
292 # Animal package that we wrote before, goes here
296 our @ISA = qw(Animal);
298 sub sound { "squeak" }
302 print "a $class goes ", $class->sound, "!\n";
303 print "[but you can barely hear it!]\n";
312 [but you can barely hear it!]
314 Here, C<Mouse> has its own speaking routine, so C<< Mouse->speak >>
315 doesn't immediately invoke C<< Animal->speak >>. This is known as
316 "overriding". In fact, we didn't even need to say that a C<Mouse> was
317 an C<Animal> at all, since all of the methods needed for C<speak> are
318 completely defined with C<Mouse>.
320 But we've now duplicated some of the code from C<< Animal->speak >>,
321 and this can once again be a maintenance headache. So, can we avoid
322 that? Can we say somehow that a C<Mouse> does everything any other
323 C<Animal> does, but add in the extra comment? Sure!
325 First, we can invoke the C<Animal::speak> method directly:
327 # Animal package that we wrote before, goes here
331 our @ISA = qw(Animal);
333 sub sound { "squeak" }
337 Animal::speak($class);
338 print "[but you can barely hear it!]\n";
342 Note that we have to include the C<$class> parameter (almost surely
343 the value of C<"Mouse">) as the first parameter to C<Animal::speak>,
344 since we've stopped using the method arrow. Why did we stop? Well,
345 if we invoke C<< Animal->speak >> there, the first parameter to the
346 method will be C<"Animal"> not C<"Mouse">, and when time comes for it
347 to call for the C<sound>, it won't have the right class to come back
350 Invoking C<Animal::speak> directly is a mess, however. What if
351 C<Animal::speak> didn't exist before, and was being inherited from a
352 class mentioned in C<@Animal::ISA>? Because we are no longer using
353 the method arrow, we get one and only one chance to hit the right
356 Also note that the C<Animal> classname is now hardwired into the
357 subroutine selection. This is a mess if someone maintains the code,
358 changing C<@ISA> for <Mouse> and didn't notice C<Animal> there in
359 C<speak>. So, this is probably not the right way to go.
361 =head2 Starting the search from a different place
363 A better solution is to tell Perl to search from a higher place
364 in the inheritance chain:
366 # same Animal as before
370 # same @ISA, &sound as before
374 $class->Animal::speak;
375 print "[but you can barely hear it!]\n";
379 Ahh. This works. Using this syntax, we start with C<Animal> to find
380 C<speak>, and use all of C<Animal>'s inheritance chain if not found
381 immediately. And yet the first parameter will be C<$class>, so the
382 found C<speak> method will get C<Mouse> as its first entry, and
383 eventually work its way back to C<Mouse::sound> for the details.
385 But this isn't the best solution. We still have to keep the C<@ISA>
386 and the initial search package coordinated. Worse, if C<Mouse> had
387 multiple entries in C<@ISA>, we wouldn't necessarily know which one
388 had actually defined C<speak>. So, is there an even better way?
390 =head2 The SUPER way of doing things
392 By changing the C<Animal> class to the C<SUPER> class in that
393 invocation, we get a search of all of our super classes (classes
394 listed in C<@ISA>) automatically:
396 # same Animal as before
400 # same @ISA, &sound as before
404 $class->SUPER::speak;
405 print "[but you can barely hear it!]\n";
409 So, C<SUPER::speak> means look in the current package's C<@ISA> for
410 C<speak>, invoking the first one found.
412 =head2 Where we're at so far...
414 So far, we've seen the method arrow syntax:
416 Class->method(@args);
423 which constructs an argument list of:
427 and attempts to invoke
429 Class::method("Class", @Args);
431 However, if C<Class::method> is not found, then C<@Class::ISA> is examined
432 (recursively) to locate a package that does indeed contain C<method>,
433 and that subroutine is invoked instead.
435 Using this simple syntax, we have class methods, (multiple)
436 inheritance, overriding, and extending. Using just what we've seen so
437 far, we've been able to factor out common code, and provide a nice way
438 to reuse implementations with variations. This is at the core of what
439 objects provide, but objects also provide instance data, which we
440 haven't even begun to cover.
442 =head2 A horse is a horse, of course of course -- or is it?
444 Let's start with the code for the C<Animal> class
445 and the C<Horse> class:
452 print "a $class goes ", $class->sound, "!\n"
459 our @ISA = qw(Animal);
461 sub sound { "neigh" }
464 This lets us invoke C<< Horse->speak >> to ripple upward to
465 C<Animal::speak>, calling back to C<Horse::sound> to get the specific
466 sound, and the output of:
470 But all of our Horse objects would have to be absolutely identical.
471 If I add a subroutine, all horses automatically share it. That's
472 great for making horses the same, but how do we capture the
473 distinctions about an individual horse? For example, suppose I want
474 to give my first horse a name. There's got to be a way to keep its
475 name separate from the other horses.
477 We can do that by drawing a new distinction, called an "instance".
478 An "instance" is generally created by a class. In Perl, any reference
479 can be an instance, so let's start with the simplest reference
480 that can hold a horse's name: a scalar reference.
483 my $talking = \$name;
485 So now C<$talking> is a reference to what will be the instance-specific
486 data (the name). The final step in turning this into a real instance
487 is with a special operator called C<bless>:
489 bless $talking, Horse;
491 This operator stores information about the package named C<Horse> into
492 the thing pointed at by the reference. At this point, we say
493 C<$talking> is an instance of C<Horse>. That is, it's a specific
494 horse. The reference is otherwise unchanged, and can still be used
495 with traditional dereferencing operators.
497 =head2 Invoking an instance method
499 The method arrow can be used on instances, as well as names of
500 packages (classes). So, let's get the sound that C<$talking> makes:
502 my $noise = $talking->sound;
504 To invoke C<sound>, Perl first notes that C<$talking> is a blessed
505 reference (and thus an instance). It then constructs an argument
506 list, in this case from just C<($talking)>. (Later we'll see that
507 arguments will take their place following the instance variable,
508 just like with classes.)
510 Now for the fun part: Perl takes the class in which the instance was
511 blessed, in this case C<Horse>, and uses that to locate the subroutine
512 to invoke the method. In this case, C<Horse::sound> is found directly
513 (without using inheritance), yielding the final subroutine invocation:
515 Horse::sound($talking)
517 Note that the first parameter here is still the instance, not the name
518 of the class as before. We'll get C<neigh> as the return value, and
519 that'll end up as the C<$noise> variable above.
521 If Horse::sound had not been found, we'd be wandering up the
522 C<@Horse::ISA> list to try to find the method in one of the
523 superclasses, just as for a class method. The only difference between
524 a class method and an instance method is whether the first parameter
525 is an instance (a blessed reference) or a class name (a string).
527 =head2 Accessing the instance data
529 Because we get the instance as the first parameter, we can now access
530 the instance-specific data. In this case, let's add a way to get at
536 our @ISA = qw(Animal);
538 sub sound { "neigh" }
546 Now we call for the name:
548 print $talking->name, " says ", $talking->sound, "\n";
550 Inside C<Horse::name>, the C<@_> array contains just C<$talking>,
551 which the C<shift> stores into C<$self>. (It's traditional to shift
552 the first parameter off into a variable named C<$self> for instance
553 methods, so stay with that unless you have strong reasons otherwise.)
554 Then, C<$self> gets de-referenced as a scalar ref, yielding C<Mr. Ed>,
555 and we're done with that. The result is:
559 =head2 How to build a horse
561 Of course, if we constructed all of our horses by hand, we'd most
562 likely make mistakes from time to time. We're also violating one of
563 the properties of object-oriented programming, in that the "inside
564 guts" of a Horse are visible. That's good if you're a veterinarian,
565 but not if you just like to own horses. So, let's let the Horse class
571 our @ISA = qw(Animal);
573 sub sound { "neigh" }
583 bless \$name, $class;
587 Now with the new C<named> method, we can build a horse:
589 my $talking = Horse->named("Mr. Ed");
591 Notice we're back to a class method, so the two arguments to
592 C<Horse::named> are C<Horse> and C<Mr. Ed>. The C<bless> operator
593 not only blesses C<$name>, it also returns the reference to C<$name>,
594 so that's fine as a return value. And that's how to build a horse.
596 We've called the constructor C<named> here, so that it quickly denotes
597 the constructor's argument as the name for this particular C<Horse>.
598 You can use different constructors with different names for different
599 ways of "giving birth" to the object (like maybe recording its
600 pedigree or date of birth). However, you'll find that most people
601 coming to Perl from more limited languages use a single constructor
602 named C<new>, with various ways of interpreting the arguments to
603 C<new>. Either style is fine, as long as you document your particular
604 way of giving birth to an object. (And you I<were> going to do that,
607 =head2 Inheriting the constructor
609 But was there anything specific to C<Horse> in that method? No. Therefore,
610 it's also the same recipe for building anything else that inherited from
611 C<Animal>, so let's put it there:
618 print "a $class goes ", $class->sound, "!\n"
629 bless \$name, $class;
636 our @ISA = qw(Animal);
638 sub sound { "neigh" }
641 Ahh, but what happens if we invoke C<speak> on an instance?
643 my $talking = Horse->named("Mr. Ed");
646 We get a debugging value:
648 a Horse=SCALAR(0xaca42ac) goes neigh!
650 Why? Because the C<Animal::speak> routine is expecting a classname as
651 its first parameter, not an instance. When the instance is passed in,
652 we'll end up using a blessed scalar reference as a string, and that
653 shows up as we saw it just now.
655 =head2 Making a method work with either classes or instances
657 All we need is for a method to detect if it is being called on a class
658 or called on an instance. The most straightforward way is with the
659 C<ref> operator. This returns a string (the classname) when used on a
660 blessed reference, and C<undef> when used on a string (like a
661 classname). Let's modify the C<name> method first to notice the change:
666 ? $$either # it's an instance, return name
667 : "an unnamed $either"; # it's a class, return generic
670 Here, the C<?:> operator comes in handy to select either the
671 dereference or a derived string. Now we can use this with either an
672 instance or a class. Note that I've changed the first parameter
673 holder to C<$either> to show that this is intended:
675 my $talking = Horse->named("Mr. Ed");
677 print Horse->name, "\n"; # prints "an unnamed Horse\n"
678 print $talking->name, "\n"; # prints "Mr Ed.\n"
680 and now we'll fix C<speak> to use this:
684 print $either->name, " goes ", $either->sound, "\n";
687 And since C<sound> already worked with either a class or an instance,
690 =head2 Adding parameters to a method
692 Let's train our animals to eat:
699 bless \$name, $class;
705 ? $$either # it's an instance, return name
706 : "an unnamed $either"; # it's a class, return generic
711 print $either->name, " goes ", $either->sound, "\n";
717 print $either->name, " eats $food.\n";
724 our @ISA = qw(Animal);
726 sub sound { "neigh" }
732 our @ISA = qw(Animal);
734 sub sound { "baaaah" }
739 my $talking = Horse->named("Mr. Ed");
740 $talking->eat("hay");
747 an unnamed Sheep eats grass.
749 An instance method with parameters gets invoked with the instance,
750 and then the list of parameters. So that first invocation is like:
752 Animal::eat($talking, "hay");
754 =head2 More interesting instances
756 What if an instance needs more data? Most interesting instances are
757 made of many items, each of which can in turn be a reference or even
758 another object. The easiest way to store these is often in a hash.
759 The keys of the hash serve as the names of parts of the object (often
760 called "instance variables" or "member variables"), and the
761 corresponding values are, well, the values.
763 But how do we turn the horse into a hash? Recall that an object was
764 any blessed reference. We can just as easily make it a blessed hash
765 reference as a blessed scalar reference, as long as everything that
766 looks at the reference is changed accordingly.
768 Let's make a sheep that has a name and a color:
770 my $data = { Name => "Evil", Color => "black" };
771 my $bad = bless $data, Sheep;
773 so C<< $bad->{Name} >> has C<Evil>, and C<< $bad->{Color} >> has
774 C<black>. But we want to make C<< $bad->name >> access the name, and
775 that's now messed up because it's expecting a scalar reference. Not
776 to worry, because that's pretty easy to fix up:
783 "an unnamed $either";
786 And of course C<named> still builds a scalar sheep, so let's fix that
793 my $self = { Name => $name, Color => $class->default_color };
798 What's this C<default_color>? Well, if C<named> has only the name,
799 we still need to set a color, so we'll have a class-specific initial color.
800 For a sheep, we might define it as white:
803 sub default_color { "white" }
805 And then to keep from having to define one for each additional class,
806 we'll define a "backstop" method that serves as the "default default",
807 directly in C<Animal>:
810 sub default_color { "brown" }
812 Now, because C<name> and C<named> were the only methods that
813 referenced the "structure" of the object, the rest of the methods can
814 remain the same, so C<speak> still works as before.
816 =head2 A horse of a different color
818 But having all our horses be brown would be boring. So let's add a
819 method or two to get and set the color.
827 $_[0]->{Color} = $_[1];
830 Note the alternate way of accessing the arguments: C<$_[0]> is used
831 in-place, rather than with a C<shift>. (This saves us a bit of time
832 for something that may be invoked frequently.) And now we can fix
833 that color for Mr. Ed:
835 my $talking = Horse->named("Mr. Ed");
836 $talking->set_color("black-and-white");
837 print $talking->name, " is colored ", $talking->color, "\n";
841 Mr. Ed is colored black-and-white
845 So, now we have class methods, constructors, instance methods,
846 instance data, and even accessors. But that's still just the
847 beginning of what Perl has to offer. We haven't even begun to talk
848 about accessors that double as getters and setters, destructors,
849 indirect object notation, subclasses that add instance data, per-class
850 data, overloading, "isa" and "can" tests, C<UNIVERSAL> class, and so
851 on. That's for the rest of the Perl documentation to cover.
852 Hopefully, this gets you started, though.
856 For more information, see L<perlobj> (for all the gritty details about
857 Perl objects, now that you've seen the basics), L<perltoot> (the
858 tutorial for those who already know objects), L<perltooc> (dealing
859 with class data), L<perlbot> (for some more tricks), and books such as
860 Damian Conway's excellent I<Object Oriented Perl>.
862 Some modules which might prove interesting are Class::Accessor,
863 Class::Class, Class::Contract, Class::Data::Inheritable,
864 Class::MethodMaker and Tie::SecureHash
868 Copyright (c) 1999, 2000 by Randal L. Schwartz and Stonehenge
869 Consulting Services, Inc. Permission is hereby granted to distribute
870 this document intact with the Perl distribution, and in accordance
871 with the licenses of the Perl distribution; derived documents must
872 include this copyright notice intact.
874 Portions of this text have been derived from Perl Training materials
875 originally appearing in the I<Packages, References, Objects, and
876 Modules> course taught by instructors for Stonehenge Consulting
877 Services, Inc. and used with permission.
879 Portions of this text have been derived from materials originally
880 appearing in I<Linux Magazine> and used with permission.