1 | =head1 NAME
|
---|
2 |
|
---|
3 | perlboot - Beginner's Object-Oriented Tutorial
|
---|
4 |
|
---|
5 | =head1 DESCRIPTION
|
---|
6 |
|
---|
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
|
---|
11 | tutorial way.
|
---|
12 |
|
---|
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.
|
---|
17 |
|
---|
18 | =head2 If we could talk to the animals...
|
---|
19 |
|
---|
20 | Let's let the animals talk for a moment:
|
---|
21 |
|
---|
22 | sub Cow::speak {
|
---|
23 | print "a Cow goes moooo!\n";
|
---|
24 | }
|
---|
25 | sub Horse::speak {
|
---|
26 | print "a Horse goes neigh!\n";
|
---|
27 | }
|
---|
28 | sub Sheep::speak {
|
---|
29 | print "a Sheep goes baaaah!\n"
|
---|
30 | }
|
---|
31 |
|
---|
32 | Cow::speak;
|
---|
33 | Horse::speak;
|
---|
34 | Sheep::speak;
|
---|
35 |
|
---|
36 | This results in:
|
---|
37 |
|
---|
38 | a Cow goes moooo!
|
---|
39 | a Horse goes neigh!
|
---|
40 | a Sheep goes baaaah!
|
---|
41 |
|
---|
42 | Nothing spectacular here. Simple subroutines, albeit from separate
|
---|
43 | packages, and called using the full package name. So let's create
|
---|
44 | an entire pasture:
|
---|
45 |
|
---|
46 | # Cow::speak, Horse::speak, Sheep::speak as before
|
---|
47 | @pasture = qw(Cow Cow Horse Sheep Sheep);
|
---|
48 | foreach $animal (@pasture) {
|
---|
49 | &{$animal."::speak"};
|
---|
50 | }
|
---|
51 |
|
---|
52 | This results in:
|
---|
53 |
|
---|
54 | a Cow goes moooo!
|
---|
55 | a Cow goes moooo!
|
---|
56 | a Horse goes neigh!
|
---|
57 | a Sheep goes baaaah!
|
---|
58 | a Sheep goes baaaah!
|
---|
59 |
|
---|
60 | Wow. That symbolic coderef de-referencing there is pretty nasty.
|
---|
61 | We're counting on C<no strict subs> mode, certainly not recommended
|
---|
62 | for larger programs. And why was that necessary? Because the name of
|
---|
63 | the package seems to be inseparable from the name of the subroutine we
|
---|
64 | want to invoke within that package.
|
---|
65 |
|
---|
66 | Or is it?
|
---|
67 |
|
---|
68 | =head2 Introducing the method invocation arrow
|
---|
69 |
|
---|
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
|
---|
74 | use it like so:
|
---|
75 |
|
---|
76 | # Cow::speak, Horse::speak, Sheep::speak as before
|
---|
77 | Cow->speak;
|
---|
78 | Horse->speak;
|
---|
79 | Sheep->speak;
|
---|
80 |
|
---|
81 | And once again, this results in:
|
---|
82 |
|
---|
83 | a Cow goes moooo!
|
---|
84 | a Horse goes neigh!
|
---|
85 | a Sheep goes baaaah!
|
---|
86 |
|
---|
87 | That's not fun yet. Same number of characters, all constant, no
|
---|
88 | variables. But yet, the parts are separable now. Watch:
|
---|
89 |
|
---|
90 | $a = "Cow";
|
---|
91 | $a->speak; # invokes Cow->speak
|
---|
92 |
|
---|
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 C<use strict refs> is enabled.
|
---|
96 |
|
---|
97 | =head2 Invoking a barnyard
|
---|
98 |
|
---|
99 | Let's take that new arrow invocation and put it back in the barnyard
|
---|
100 | example:
|
---|
101 |
|
---|
102 | sub Cow::speak {
|
---|
103 | print "a Cow goes moooo!\n";
|
---|
104 | }
|
---|
105 | sub Horse::speak {
|
---|
106 | print "a Horse goes neigh!\n";
|
---|
107 | }
|
---|
108 | sub Sheep::speak {
|
---|
109 | print "a Sheep goes baaaah!\n"
|
---|
110 | }
|
---|
111 |
|
---|
112 | @pasture = qw(Cow Cow Horse Sheep Sheep);
|
---|
113 | foreach $animal (@pasture) {
|
---|
114 | $animal->speak;
|
---|
115 | }
|
---|
116 |
|
---|
117 | There! Now we have the animals all talking, and safely at that,
|
---|
118 | without the use of symbolic coderefs.
|
---|
119 |
|
---|
120 | But look at all that common code. Each of the C<speak> routines has a
|
---|
121 | similar structure: a C<print> operator and a string that contains
|
---|
122 | common text, except for two of the words. It'd be nice if we could
|
---|
123 | factor out the commonality, in case we decide later to change it all
|
---|
124 | to C<says> instead of C<goes>.
|
---|
125 |
|
---|
126 | And we actually have a way of doing that without much fuss, but we
|
---|
127 | have to hear a bit more about what the method invocation arrow is
|
---|
128 | actually doing for us.
|
---|
129 |
|
---|
130 | =head2 The extra parameter of method invocation
|
---|
131 |
|
---|
132 | The invocation of:
|
---|
133 |
|
---|
134 | Class->method(@args)
|
---|
135 |
|
---|
136 | attempts to invoke subroutine C<Class::method> as:
|
---|
137 |
|
---|
138 | Class::method("Class", @args);
|
---|
139 |
|
---|
140 | (If the subroutine can't be found, "inheritance" kicks in, but we'll
|
---|
141 | get to that later.) This means that we get the class name as the
|
---|
142 | first parameter (the only parameter, if no arguments are given). So
|
---|
143 | we can rewrite the C<Sheep> speaking subroutine as:
|
---|
144 |
|
---|
145 | sub Sheep::speak {
|
---|
146 | my $class = shift;
|
---|
147 | print "a $class goes baaaah!\n";
|
---|
148 | }
|
---|
149 |
|
---|
150 | And the other two animals come out similarly:
|
---|
151 |
|
---|
152 | sub Cow::speak {
|
---|
153 | my $class = shift;
|
---|
154 | print "a $class goes moooo!\n";
|
---|
155 | }
|
---|
156 | sub Horse::speak {
|
---|
157 | my $class = shift;
|
---|
158 | print "a $class goes neigh!\n";
|
---|
159 | }
|
---|
160 |
|
---|
161 | In each case, C<$class> will get the value appropriate for that
|
---|
162 | subroutine. But once again, we have a lot of similar structure. Can
|
---|
163 | we factor that out even further? Yes, by calling another method in
|
---|
164 | the same class.
|
---|
165 |
|
---|
166 | =head2 Calling a second method to simplify things
|
---|
167 |
|
---|
168 | Let's call out from C<speak> to a helper method called C<sound>.
|
---|
169 | This method provides the constant text for the sound itself.
|
---|
170 |
|
---|
171 | { package Cow;
|
---|
172 | sub sound { "moooo" }
|
---|
173 | sub speak {
|
---|
174 | my $class = shift;
|
---|
175 | print "a $class goes ", $class->sound, "!\n"
|
---|
176 | }
|
---|
177 | }
|
---|
178 |
|
---|
179 | Now, when we call C<< Cow->speak >>, we get a C<$class> of C<Cow> in
|
---|
180 | C<speak>. This in turn selects the C<< Cow->sound >> method, which
|
---|
181 | returns C<moooo>. But how different would this be for the C<Horse>?
|
---|
182 |
|
---|
183 | { package Horse;
|
---|
184 | sub sound { "neigh" }
|
---|
185 | sub speak {
|
---|
186 | my $class = shift;
|
---|
187 | print "a $class goes ", $class->sound, "!\n"
|
---|
188 | }
|
---|
189 | }
|
---|
190 |
|
---|
191 | Only the name of the package and the specific sound change. So can we
|
---|
192 | somehow share the definition for C<speak> between the Cow and the
|
---|
193 | Horse? Yes, with inheritance!
|
---|
194 |
|
---|
195 | =head2 Inheriting the windpipes
|
---|
196 |
|
---|
197 | We'll define a common subroutine package called C<Animal>, with the
|
---|
198 | definition for C<speak>:
|
---|
199 |
|
---|
200 | { package Animal;
|
---|
201 | sub speak {
|
---|
202 | my $class = shift;
|
---|
203 | print "a $class goes ", $class->sound, "!\n"
|
---|
204 | }
|
---|
205 | }
|
---|
206 |
|
---|
207 | Then, for each animal, we say it "inherits" from C<Animal>, along
|
---|
208 | with the animal-specific sound:
|
---|
209 |
|
---|
210 | { package Cow;
|
---|
211 | @ISA = qw(Animal);
|
---|
212 | sub sound { "moooo" }
|
---|
213 | }
|
---|
214 |
|
---|
215 | Note the added C<@ISA> array. We'll get to that in a minute.
|
---|
216 |
|
---|
217 | But what happens when we invoke C<< Cow->speak >> now?
|
---|
218 |
|
---|
219 | First, Perl constructs the argument list. In this case, it's just
|
---|
220 | C<Cow>. Then Perl looks for C<Cow::speak>. But that's not there, so
|
---|
221 | Perl checks for the inheritance array C<@Cow::ISA>. It's there,
|
---|
222 | and contains the single name C<Animal>.
|
---|
223 |
|
---|
224 | Perl next checks for C<speak> inside C<Animal> instead, as in
|
---|
225 | C<Animal::speak>. And that's found, so Perl invokes that subroutine
|
---|
226 | with the already frozen argument list.
|
---|
227 |
|
---|
228 | Inside the C<Animal::speak> subroutine, C<$class> becomes C<Cow> (the
|
---|
229 | first argument). So when we get to the step of invoking
|
---|
230 | C<< $class->sound >>, it'll be looking for C<< Cow->sound >>, which
|
---|
231 | gets it on the first try without looking at C<@ISA>. Success!
|
---|
232 |
|
---|
233 | =head2 A few notes about @ISA
|
---|
234 |
|
---|
235 | This magical C<@ISA> variable (pronounced "is a" not "ice-uh"), has
|
---|
236 | declared that C<Cow> "is a" C<Animal>. Note that it's an array,
|
---|
237 | not a simple single value, because on rare occasions, it makes sense
|
---|
238 | to have more than one parent class searched for the missing methods.
|
---|
239 |
|
---|
240 | If C<Animal> also had an C<@ISA>, then we'd check there too. The
|
---|
241 | search is recursive, depth-first, left-to-right in each C<@ISA>.
|
---|
242 | Typically, each C<@ISA> has only one element (multiple elements means
|
---|
243 | multiple inheritance and multiple headaches), so we get a nice tree of
|
---|
244 | inheritance.
|
---|
245 |
|
---|
246 | When we turn on C<use strict>, we'll get complaints on C<@ISA>, since
|
---|
247 | it's not a variable containing an explicit package name, nor is it a
|
---|
248 | lexical ("my") variable. We can't make it a lexical variable though
|
---|
249 | (it has to belong to the package to be found by the inheritance mechanism),
|
---|
250 | so there's a couple of straightforward ways to handle that.
|
---|
251 |
|
---|
252 | The easiest is to just spell the package name out:
|
---|
253 |
|
---|
254 | @Cow::ISA = qw(Animal);
|
---|
255 |
|
---|
256 | Or allow it as an implicitly named package variable:
|
---|
257 |
|
---|
258 | package Cow;
|
---|
259 | use vars qw(@ISA);
|
---|
260 | @ISA = qw(Animal);
|
---|
261 |
|
---|
262 | If you're bringing in the class from outside, via an object-oriented
|
---|
263 | module, you change:
|
---|
264 |
|
---|
265 | package Cow;
|
---|
266 | use Animal;
|
---|
267 | use vars qw(@ISA);
|
---|
268 | @ISA = qw(Animal);
|
---|
269 |
|
---|
270 | into just:
|
---|
271 |
|
---|
272 | package Cow;
|
---|
273 | use base qw(Animal);
|
---|
274 |
|
---|
275 | And that's pretty darn compact.
|
---|
276 |
|
---|
277 | =head2 Overriding the methods
|
---|
278 |
|
---|
279 | Let's add a mouse, which can barely be heard:
|
---|
280 |
|
---|
281 | # Animal package from before
|
---|
282 | { package Mouse;
|
---|
283 | @ISA = qw(Animal);
|
---|
284 | sub sound { "squeak" }
|
---|
285 | sub speak {
|
---|
286 | my $class = shift;
|
---|
287 | print "a $class goes ", $class->sound, "!\n";
|
---|
288 | print "[but you can barely hear it!]\n";
|
---|
289 | }
|
---|
290 | }
|
---|
291 |
|
---|
292 | Mouse->speak;
|
---|
293 |
|
---|
294 | which results in:
|
---|
295 |
|
---|
296 | a Mouse goes squeak!
|
---|
297 | [but you can barely hear it!]
|
---|
298 |
|
---|
299 | Here, C<Mouse> has its own speaking routine, so C<< Mouse->speak >>
|
---|
300 | doesn't immediately invoke C<< Animal->speak >>. This is known as
|
---|
301 | "overriding". In fact, we didn't even need to say that a C<Mouse> was
|
---|
302 | an C<Animal> at all, since all of the methods needed for C<speak> are
|
---|
303 | completely defined with C<Mouse>.
|
---|
304 |
|
---|
305 | But we've now duplicated some of the code from C<< Animal->speak >>,
|
---|
306 | and this can once again be a maintenance headache. So, can we avoid
|
---|
307 | that? Can we say somehow that a C<Mouse> does everything any other
|
---|
308 | C<Animal> does, but add in the extra comment? Sure!
|
---|
309 |
|
---|
310 | First, we can invoke the C<Animal::speak> method directly:
|
---|
311 |
|
---|
312 | # Animal package from before
|
---|
313 | { package Mouse;
|
---|
314 | @ISA = qw(Animal);
|
---|
315 | sub sound { "squeak" }
|
---|
316 | sub speak {
|
---|
317 | my $class = shift;
|
---|
318 | Animal::speak($class);
|
---|
319 | print "[but you can barely hear it!]\n";
|
---|
320 | }
|
---|
321 | }
|
---|
322 |
|
---|
323 | Note that we have to include the C<$class> parameter (almost surely
|
---|
324 | the value of C<"Mouse">) as the first parameter to C<Animal::speak>,
|
---|
325 | since we've stopped using the method arrow. Why did we stop? Well,
|
---|
326 | if we invoke C<< Animal->speak >> there, the first parameter to the
|
---|
327 | method will be C<"Animal"> not C<"Mouse">, and when time comes for it
|
---|
328 | to call for the C<sound>, it won't have the right class to come back
|
---|
329 | to this package.
|
---|
330 |
|
---|
331 | Invoking C<Animal::speak> directly is a mess, however. What if
|
---|
332 | C<Animal::speak> didn't exist before, and was being inherited from a
|
---|
333 | class mentioned in C<@Animal::ISA>? Because we are no longer using
|
---|
334 | the method arrow, we get one and only one chance to hit the right
|
---|
335 | subroutine.
|
---|
336 |
|
---|
337 | Also note that the C<Animal> classname is now hardwired into the
|
---|
338 | subroutine selection. This is a mess if someone maintains the code,
|
---|
339 | changing C<@ISA> for <Mouse> and didn't notice C<Animal> there in
|
---|
340 | C<speak>. So, this is probably not the right way to go.
|
---|
341 |
|
---|
342 | =head2 Starting the search from a different place
|
---|
343 |
|
---|
344 | A better solution is to tell Perl to search from a higher place
|
---|
345 | in the inheritance chain:
|
---|
346 |
|
---|
347 | # same Animal as before
|
---|
348 | { package Mouse;
|
---|
349 | # same @ISA, &sound as before
|
---|
350 | sub speak {
|
---|
351 | my $class = shift;
|
---|
352 | $class->Animal::speak;
|
---|
353 | print "[but you can barely hear it!]\n";
|
---|
354 | }
|
---|
355 | }
|
---|
356 |
|
---|
357 | Ahh. This works. Using this syntax, we start with C<Animal> to find
|
---|
358 | C<speak>, and use all of C<Animal>'s inheritance chain if not found
|
---|
359 | immediately. And yet the first parameter will be C<$class>, so the
|
---|
360 | found C<speak> method will get C<Mouse> as its first entry, and
|
---|
361 | eventually work its way back to C<Mouse::sound> for the details.
|
---|
362 |
|
---|
363 | But this isn't the best solution. We still have to keep the C<@ISA>
|
---|
364 | and the initial search package coordinated. Worse, if C<Mouse> had
|
---|
365 | multiple entries in C<@ISA>, we wouldn't necessarily know which one
|
---|
366 | had actually defined C<speak>. So, is there an even better way?
|
---|
367 |
|
---|
368 | =head2 The SUPER way of doing things
|
---|
369 |
|
---|
370 | By changing the C<Animal> class to the C<SUPER> class in that
|
---|
371 | invocation, we get a search of all of our super classes (classes
|
---|
372 | listed in C<@ISA>) automatically:
|
---|
373 |
|
---|
374 | # same Animal as before
|
---|
375 | { package Mouse;
|
---|
376 | # same @ISA, &sound as before
|
---|
377 | sub speak {
|
---|
378 | my $class = shift;
|
---|
379 | $class->SUPER::speak;
|
---|
380 | print "[but you can barely hear it!]\n";
|
---|
381 | }
|
---|
382 | }
|
---|
383 |
|
---|
384 | So, C<SUPER::speak> means look in the current package's C<@ISA> for
|
---|
385 | C<speak>, invoking the first one found. Note that it does I<not> look in
|
---|
386 | the C<@ISA> of C<$class>.
|
---|
387 |
|
---|
388 | =head2 Where we're at so far...
|
---|
389 |
|
---|
390 | So far, we've seen the method arrow syntax:
|
---|
391 |
|
---|
392 | Class->method(@args);
|
---|
393 |
|
---|
394 | or the equivalent:
|
---|
395 |
|
---|
396 | $a = "Class";
|
---|
397 | $a->method(@args);
|
---|
398 |
|
---|
399 | which constructs an argument list of:
|
---|
400 |
|
---|
401 | ("Class", @args)
|
---|
402 |
|
---|
403 | and attempts to invoke
|
---|
404 |
|
---|
405 | Class::method("Class", @Args);
|
---|
406 |
|
---|
407 | However, if C<Class::method> is not found, then C<@Class::ISA> is examined
|
---|
408 | (recursively) to locate a package that does indeed contain C<method>,
|
---|
409 | and that subroutine is invoked instead.
|
---|
410 |
|
---|
411 | Using this simple syntax, we have class methods, (multiple)
|
---|
412 | inheritance, overriding, and extending. Using just what we've seen so
|
---|
413 | far, we've been able to factor out common code, and provide a nice way
|
---|
414 | to reuse implementations with variations. This is at the core of what
|
---|
415 | objects provide, but objects also provide instance data, which we
|
---|
416 | haven't even begun to cover.
|
---|
417 |
|
---|
418 | =head2 A horse is a horse, of course of course -- or is it?
|
---|
419 |
|
---|
420 | Let's start with the code for the C<Animal> class
|
---|
421 | and the C<Horse> class:
|
---|
422 |
|
---|
423 | { package Animal;
|
---|
424 | sub speak {
|
---|
425 | my $class = shift;
|
---|
426 | print "a $class goes ", $class->sound, "!\n"
|
---|
427 | }
|
---|
428 | }
|
---|
429 | { package Horse;
|
---|
430 | @ISA = qw(Animal);
|
---|
431 | sub sound { "neigh" }
|
---|
432 | }
|
---|
433 |
|
---|
434 | This lets us invoke C<< Horse->speak >> to ripple upward to
|
---|
435 | C<Animal::speak>, calling back to C<Horse::sound> to get the specific
|
---|
436 | sound, and the output of:
|
---|
437 |
|
---|
438 | a Horse goes neigh!
|
---|
439 |
|
---|
440 | But all of our Horse objects would have to be absolutely identical.
|
---|
441 | If I add a subroutine, all horses automatically share it. That's
|
---|
442 | great for making horses the same, but how do we capture the
|
---|
443 | distinctions about an individual horse? For example, suppose I want
|
---|
444 | to give my first horse a name. There's got to be a way to keep its
|
---|
445 | name separate from the other horses.
|
---|
446 |
|
---|
447 | We can do that by drawing a new distinction, called an "instance".
|
---|
448 | An "instance" is generally created by a class. In Perl, any reference
|
---|
449 | can be an instance, so let's start with the simplest reference
|
---|
450 | that can hold a horse's name: a scalar reference.
|
---|
451 |
|
---|
452 | my $name = "Mr. Ed";
|
---|
453 | my $talking = \$name;
|
---|
454 |
|
---|
455 | So now C<$talking> is a reference to what will be the instance-specific
|
---|
456 | data (the name). The final step in turning this into a real instance
|
---|
457 | is with a special operator called C<bless>:
|
---|
458 |
|
---|
459 | bless $talking, Horse;
|
---|
460 |
|
---|
461 | This operator stores information about the package named C<Horse> into
|
---|
462 | the thing pointed at by the reference. At this point, we say
|
---|
463 | C<$talking> is an instance of C<Horse>. That is, it's a specific
|
---|
464 | horse. The reference is otherwise unchanged, and can still be used
|
---|
465 | with traditional dereferencing operators.
|
---|
466 |
|
---|
467 | =head2 Invoking an instance method
|
---|
468 |
|
---|
469 | The method arrow can be used on instances, as well as names of
|
---|
470 | packages (classes). So, let's get the sound that C<$talking> makes:
|
---|
471 |
|
---|
472 | my $noise = $talking->sound;
|
---|
473 |
|
---|
474 | To invoke C<sound>, Perl first notes that C<$talking> is a blessed
|
---|
475 | reference (and thus an instance). It then constructs an argument
|
---|
476 | list, in this case from just C<($talking)>. (Later we'll see that
|
---|
477 | arguments will take their place following the instance variable,
|
---|
478 | just like with classes.)
|
---|
479 |
|
---|
480 | Now for the fun part: Perl takes the class in which the instance was
|
---|
481 | blessed, in this case C<Horse>, and uses that to locate the subroutine
|
---|
482 | to invoke the method. In this case, C<Horse::sound> is found directly
|
---|
483 | (without using inheritance), yielding the final subroutine invocation:
|
---|
484 |
|
---|
485 | Horse::sound($talking)
|
---|
486 |
|
---|
487 | Note that the first parameter here is still the instance, not the name
|
---|
488 | of the class as before. We'll get C<neigh> as the return value, and
|
---|
489 | that'll end up as the C<$noise> variable above.
|
---|
490 |
|
---|
491 | If Horse::sound had not been found, we'd be wandering up the
|
---|
492 | C<@Horse::ISA> list to try to find the method in one of the
|
---|
493 | superclasses, just as for a class method. The only difference between
|
---|
494 | a class method and an instance method is whether the first parameter
|
---|
495 | is an instance (a blessed reference) or a class name (a string).
|
---|
496 |
|
---|
497 | =head2 Accessing the instance data
|
---|
498 |
|
---|
499 | Because we get the instance as the first parameter, we can now access
|
---|
500 | the instance-specific data. In this case, let's add a way to get at
|
---|
501 | the name:
|
---|
502 |
|
---|
503 | { package Horse;
|
---|
504 | @ISA = qw(Animal);
|
---|
505 | sub sound { "neigh" }
|
---|
506 | sub name {
|
---|
507 | my $self = shift;
|
---|
508 | $$self;
|
---|
509 | }
|
---|
510 | }
|
---|
511 |
|
---|
512 | Now we call for the name:
|
---|
513 |
|
---|
514 | print $talking->name, " says ", $talking->sound, "\n";
|
---|
515 |
|
---|
516 | Inside C<Horse::name>, the C<@_> array contains just C<$talking>,
|
---|
517 | which the C<shift> stores into C<$self>. (It's traditional to shift
|
---|
518 | the first parameter off into a variable named C<$self> for instance
|
---|
519 | methods, so stay with that unless you have strong reasons otherwise.)
|
---|
520 | Then, C<$self> gets de-referenced as a scalar ref, yielding C<Mr. Ed>,
|
---|
521 | and we're done with that. The result is:
|
---|
522 |
|
---|
523 | Mr. Ed says neigh.
|
---|
524 |
|
---|
525 | =head2 How to build a horse
|
---|
526 |
|
---|
527 | Of course, if we constructed all of our horses by hand, we'd most
|
---|
528 | likely make mistakes from time to time. We're also violating one of
|
---|
529 | the properties of object-oriented programming, in that the "inside
|
---|
530 | guts" of a Horse are visible. That's good if you're a veterinarian,
|
---|
531 | but not if you just like to own horses. So, let's let the Horse class
|
---|
532 | build a new horse:
|
---|
533 |
|
---|
534 | { package Horse;
|
---|
535 | @ISA = qw(Animal);
|
---|
536 | sub sound { "neigh" }
|
---|
537 | sub name {
|
---|
538 | my $self = shift;
|
---|
539 | $$self;
|
---|
540 | }
|
---|
541 | sub named {
|
---|
542 | my $class = shift;
|
---|
543 | my $name = shift;
|
---|
544 | bless \$name, $class;
|
---|
545 | }
|
---|
546 | }
|
---|
547 |
|
---|
548 | Now with the new C<named> method, we can build a horse:
|
---|
549 |
|
---|
550 | my $talking = Horse->named("Mr. Ed");
|
---|
551 |
|
---|
552 | Notice we're back to a class method, so the two arguments to
|
---|
553 | C<Horse::named> are C<Horse> and C<Mr. Ed>. The C<bless> operator
|
---|
554 | not only blesses C<$name>, it also returns the reference to C<$name>,
|
---|
555 | so that's fine as a return value. And that's how to build a horse.
|
---|
556 |
|
---|
557 | We've called the constructor C<named> here, so that it quickly denotes
|
---|
558 | the constructor's argument as the name for this particular C<Horse>.
|
---|
559 | You can use different constructors with different names for different
|
---|
560 | ways of "giving birth" to the object (like maybe recording its
|
---|
561 | pedigree or date of birth). However, you'll find that most people
|
---|
562 | coming to Perl from more limited languages use a single constructor
|
---|
563 | named C<new>, with various ways of interpreting the arguments to
|
---|
564 | C<new>. Either style is fine, as long as you document your particular
|
---|
565 | way of giving birth to an object. (And you I<were> going to do that,
|
---|
566 | right?)
|
---|
567 |
|
---|
568 | =head2 Inheriting the constructor
|
---|
569 |
|
---|
570 | But was there anything specific to C<Horse> in that method? No. Therefore,
|
---|
571 | it's also the same recipe for building anything else that inherited from
|
---|
572 | C<Animal>, so let's put it there:
|
---|
573 |
|
---|
574 | { package Animal;
|
---|
575 | sub speak {
|
---|
576 | my $class = shift;
|
---|
577 | print "a $class goes ", $class->sound, "!\n"
|
---|
578 | }
|
---|
579 | sub name {
|
---|
580 | my $self = shift;
|
---|
581 | $$self;
|
---|
582 | }
|
---|
583 | sub named {
|
---|
584 | my $class = shift;
|
---|
585 | my $name = shift;
|
---|
586 | bless \$name, $class;
|
---|
587 | }
|
---|
588 | }
|
---|
589 | { package Horse;
|
---|
590 | @ISA = qw(Animal);
|
---|
591 | sub sound { "neigh" }
|
---|
592 | }
|
---|
593 |
|
---|
594 | Ahh, but what happens if we invoke C<speak> on an instance?
|
---|
595 |
|
---|
596 | my $talking = Horse->named("Mr. Ed");
|
---|
597 | $talking->speak;
|
---|
598 |
|
---|
599 | We get a debugging value:
|
---|
600 |
|
---|
601 | a Horse=SCALAR(0xaca42ac) goes neigh!
|
---|
602 |
|
---|
603 | Why? Because the C<Animal::speak> routine is expecting a classname as
|
---|
604 | its first parameter, not an instance. When the instance is passed in,
|
---|
605 | we'll end up using a blessed scalar reference as a string, and that
|
---|
606 | shows up as we saw it just now.
|
---|
607 |
|
---|
608 | =head2 Making a method work with either classes or instances
|
---|
609 |
|
---|
610 | All we need is for a method to detect if it is being called on a class
|
---|
611 | or called on an instance. The most straightforward way is with the
|
---|
612 | C<ref> operator. This returns a string (the classname) when used on a
|
---|
613 | blessed reference, and C<undef> when used on a string (like a
|
---|
614 | classname). Let's modify the C<name> method first to notice the change:
|
---|
615 |
|
---|
616 | sub name {
|
---|
617 | my $either = shift;
|
---|
618 | ref $either
|
---|
619 | ? $$either # it's an instance, return name
|
---|
620 | : "an unnamed $either"; # it's a class, return generic
|
---|
621 | }
|
---|
622 |
|
---|
623 | Here, the C<?:> operator comes in handy to select either the
|
---|
624 | dereference or a derived string. Now we can use this with either an
|
---|
625 | instance or a class. Note that I've changed the first parameter
|
---|
626 | holder to C<$either> to show that this is intended:
|
---|
627 |
|
---|
628 | my $talking = Horse->named("Mr. Ed");
|
---|
629 | print Horse->name, "\n"; # prints "an unnamed Horse\n"
|
---|
630 | print $talking->name, "\n"; # prints "Mr Ed.\n"
|
---|
631 |
|
---|
632 | and now we'll fix C<speak> to use this:
|
---|
633 |
|
---|
634 | sub speak {
|
---|
635 | my $either = shift;
|
---|
636 | print $either->name, " goes ", $either->sound, "\n";
|
---|
637 | }
|
---|
638 |
|
---|
639 | And since C<sound> already worked with either a class or an instance,
|
---|
640 | we're done!
|
---|
641 |
|
---|
642 | =head2 Adding parameters to a method
|
---|
643 |
|
---|
644 | Let's train our animals to eat:
|
---|
645 |
|
---|
646 | { package Animal;
|
---|
647 | sub named {
|
---|
648 | my $class = shift;
|
---|
649 | my $name = shift;
|
---|
650 | bless \$name, $class;
|
---|
651 | }
|
---|
652 | sub name {
|
---|
653 | my $either = shift;
|
---|
654 | ref $either
|
---|
655 | ? $$either # it's an instance, return name
|
---|
656 | : "an unnamed $either"; # it's a class, return generic
|
---|
657 | }
|
---|
658 | sub speak {
|
---|
659 | my $either = shift;
|
---|
660 | print $either->name, " goes ", $either->sound, "\n";
|
---|
661 | }
|
---|
662 | sub eat {
|
---|
663 | my $either = shift;
|
---|
664 | my $food = shift;
|
---|
665 | print $either->name, " eats $food.\n";
|
---|
666 | }
|
---|
667 | }
|
---|
668 | { package Horse;
|
---|
669 | @ISA = qw(Animal);
|
---|
670 | sub sound { "neigh" }
|
---|
671 | }
|
---|
672 | { package Sheep;
|
---|
673 | @ISA = qw(Animal);
|
---|
674 | sub sound { "baaaah" }
|
---|
675 | }
|
---|
676 |
|
---|
677 | And now try it out:
|
---|
678 |
|
---|
679 | my $talking = Horse->named("Mr. Ed");
|
---|
680 | $talking->eat("hay");
|
---|
681 | Sheep->eat("grass");
|
---|
682 |
|
---|
683 | which prints:
|
---|
684 |
|
---|
685 | Mr. Ed eats hay.
|
---|
686 | an unnamed Sheep eats grass.
|
---|
687 |
|
---|
688 | An instance method with parameters gets invoked with the instance,
|
---|
689 | and then the list of parameters. So that first invocation is like:
|
---|
690 |
|
---|
691 | Animal::eat($talking, "hay");
|
---|
692 |
|
---|
693 | =head2 More interesting instances
|
---|
694 |
|
---|
695 | What if an instance needs more data? Most interesting instances are
|
---|
696 | made of many items, each of which can in turn be a reference or even
|
---|
697 | another object. The easiest way to store these is often in a hash.
|
---|
698 | The keys of the hash serve as the names of parts of the object (often
|
---|
699 | called "instance variables" or "member variables"), and the
|
---|
700 | corresponding values are, well, the values.
|
---|
701 |
|
---|
702 | But how do we turn the horse into a hash? Recall that an object was
|
---|
703 | any blessed reference. We can just as easily make it a blessed hash
|
---|
704 | reference as a blessed scalar reference, as long as everything that
|
---|
705 | looks at the reference is changed accordingly.
|
---|
706 |
|
---|
707 | Let's make a sheep that has a name and a color:
|
---|
708 |
|
---|
709 | my $bad = bless { Name => "Evil", Color => "black" }, Sheep;
|
---|
710 |
|
---|
711 | so C<< $bad->{Name} >> has C<Evil>, and C<< $bad->{Color} >> has
|
---|
712 | C<black>. But we want to make C<< $bad->name >> access the name, and
|
---|
713 | that's now messed up because it's expecting a scalar reference. Not
|
---|
714 | to worry, because that's pretty easy to fix up:
|
---|
715 |
|
---|
716 | ## in Animal
|
---|
717 | sub name {
|
---|
718 | my $either = shift;
|
---|
719 | ref $either ?
|
---|
720 | $either->{Name} :
|
---|
721 | "an unnamed $either";
|
---|
722 | }
|
---|
723 |
|
---|
724 | And of course C<named> still builds a scalar sheep, so let's fix that
|
---|
725 | as well:
|
---|
726 |
|
---|
727 | ## in Animal
|
---|
728 | sub named {
|
---|
729 | my $class = shift;
|
---|
730 | my $name = shift;
|
---|
731 | my $self = { Name => $name, Color => $class->default_color };
|
---|
732 | bless $self, $class;
|
---|
733 | }
|
---|
734 |
|
---|
735 | What's this C<default_color>? Well, if C<named> has only the name,
|
---|
736 | we still need to set a color, so we'll have a class-specific initial color.
|
---|
737 | For a sheep, we might define it as white:
|
---|
738 |
|
---|
739 | ## in Sheep
|
---|
740 | sub default_color { "white" }
|
---|
741 |
|
---|
742 | And then to keep from having to define one for each additional class,
|
---|
743 | we'll define a "backstop" method that serves as the "default default",
|
---|
744 | directly in C<Animal>:
|
---|
745 |
|
---|
746 | ## in Animal
|
---|
747 | sub default_color { "brown" }
|
---|
748 |
|
---|
749 | Now, because C<name> and C<named> were the only methods that
|
---|
750 | referenced the "structure" of the object, the rest of the methods can
|
---|
751 | remain the same, so C<speak> still works as before.
|
---|
752 |
|
---|
753 | =head2 A horse of a different color
|
---|
754 |
|
---|
755 | But having all our horses be brown would be boring. So let's add a
|
---|
756 | method or two to get and set the color.
|
---|
757 |
|
---|
758 | ## in Animal
|
---|
759 | sub color {
|
---|
760 | $_[0]->{Color}
|
---|
761 | }
|
---|
762 | sub set_color {
|
---|
763 | $_[0]->{Color} = $_[1];
|
---|
764 | }
|
---|
765 |
|
---|
766 | Note the alternate way of accessing the arguments: C<$_[0]> is used
|
---|
767 | in-place, rather than with a C<shift>. (This saves us a bit of time
|
---|
768 | for something that may be invoked frequently.) And now we can fix
|
---|
769 | that color for Mr. Ed:
|
---|
770 |
|
---|
771 | my $talking = Horse->named("Mr. Ed");
|
---|
772 | $talking->set_color("black-and-white");
|
---|
773 | print $talking->name, " is colored ", $talking->color, "\n";
|
---|
774 |
|
---|
775 | which results in:
|
---|
776 |
|
---|
777 | Mr. Ed is colored black-and-white
|
---|
778 |
|
---|
779 | =head2 Summary
|
---|
780 |
|
---|
781 | So, now we have class methods, constructors, instance methods,
|
---|
782 | instance data, and even accessors. But that's still just the
|
---|
783 | beginning of what Perl has to offer. We haven't even begun to talk
|
---|
784 | about accessors that double as getters and setters, destructors,
|
---|
785 | indirect object notation, subclasses that add instance data, per-class
|
---|
786 | data, overloading, "isa" and "can" tests, C<UNIVERSAL> class, and so
|
---|
787 | on. That's for the rest of the Perl documentation to cover.
|
---|
788 | Hopefully, this gets you started, though.
|
---|
789 |
|
---|
790 | =head1 SEE ALSO
|
---|
791 |
|
---|
792 | For more information, see L<perlobj> (for all the gritty details about
|
---|
793 | Perl objects, now that you've seen the basics), L<perltoot> (the
|
---|
794 | tutorial for those who already know objects), L<perltooc> (dealing
|
---|
795 | with class data), L<perlbot> (for some more tricks), and books such as
|
---|
796 | Damian Conway's excellent I<Object Oriented Perl>.
|
---|
797 |
|
---|
798 | Some modules which might prove interesting are Class::Accessor,
|
---|
799 | Class::Class, Class::Contract, Class::Data::Inheritable,
|
---|
800 | Class::MethodMaker and Tie::SecureHash
|
---|
801 |
|
---|
802 | =head1 COPYRIGHT
|
---|
803 |
|
---|
804 | Copyright (c) 1999, 2000 by Randal L. Schwartz and Stonehenge
|
---|
805 | Consulting Services, Inc. Permission is hereby granted to distribute
|
---|
806 | this document intact with the Perl distribution, and in accordance
|
---|
807 | with the licenses of the Perl distribution; derived documents must
|
---|
808 | include this copyright notice intact.
|
---|
809 |
|
---|
810 | Portions of this text have been derived from Perl Training materials
|
---|
811 | originally appearing in the I<Packages, References, Objects, and
|
---|
812 | Modules> course taught by instructors for Stonehenge Consulting
|
---|
813 | Services, Inc. and used with permission.
|
---|
814 |
|
---|
815 | Portions of this text have been derived from materials originally
|
---|
816 | appearing in I<Linux Magazine> and used with permission.
|
---|