Commit | Line | Data |
694468e3 |
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 |
dbe48302 |
10 | introduces readers to the peculiarities of Perl's object system in a |
694468e3 |
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 |
769c2898 |
47 | my @pasture = qw(Cow Cow Horse Sheep Sheep); |
48 | foreach my $animal (@pasture) { |
694468e3 |
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. |
769c2898 |
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. |
694468e3 |
65 | |
66 | Or is it? |
67 | |
68 | =head2 Introducing the method invocation arrow |
69 | |
c47ff5f1 |
70 | For now, let's say that C<< Class->method >> invokes subroutine |
694468e3 |
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 | |
769c2898 |
90 | my $a = "Cow"; |
694468e3 |
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 |
769c2898 |
95 | something that works even when L<strict|C<use strict refs>> is |
96 | enabled. |
694468e3 |
97 | |
98 | =head2 Invoking a barnyard |
99 | |
100 | Let's take that new arrow invocation and put it back in the barnyard |
101 | example: |
102 | |
103 | sub Cow::speak { |
104 | print "a Cow goes moooo!\n"; |
105 | } |
106 | sub Horse::speak { |
107 | print "a Horse goes neigh!\n"; |
108 | } |
109 | sub Sheep::speak { |
110 | print "a Sheep goes baaaah!\n" |
111 | } |
112 | |
769c2898 |
113 | my @pasture = qw(Cow Cow Horse Sheep Sheep); |
114 | foreach my $animal (@pasture) { |
694468e3 |
115 | $animal->speak; |
116 | } |
117 | |
118 | There! Now we have the animals all talking, and safely at that, |
119 | without the use of symbolic coderefs. |
120 | |
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>. |
126 | |
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. |
130 | |
131 | =head2 The extra parameter of method invocation |
132 | |
133 | The invocation of: |
134 | |
135 | Class->method(@args) |
136 | |
137 | attempts to invoke subroutine C<Class::method> as: |
138 | |
139 | Class::method("Class", @args); |
140 | |
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 |
dbe48302 |
143 | first parameter (the only parameter, if no arguments are given). So |
144 | we can rewrite the C<Sheep> speaking subroutine as: |
694468e3 |
145 | |
146 | sub Sheep::speak { |
147 | my $class = shift; |
148 | print "a $class goes baaaah!\n"; |
149 | } |
150 | |
151 | And the other two animals come out similarly: |
152 | |
153 | sub Cow::speak { |
154 | my $class = shift; |
155 | print "a $class goes moooo!\n"; |
156 | } |
157 | sub Horse::speak { |
158 | my $class = shift; |
159 | print "a $class goes neigh!\n"; |
160 | } |
161 | |
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 |
165 | the same class. |
166 | |
167 | =head2 Calling a second method to simplify things |
168 | |
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. |
171 | |
769c2898 |
172 | { |
173 | package Cow; |
174 | |
694468e3 |
175 | sub sound { "moooo" } |
769c2898 |
176 | |
694468e3 |
177 | sub speak { |
769c2898 |
178 | my $class = shift; |
179 | print "a $class goes ", $class->sound, "!\n" |
694468e3 |
180 | } |
181 | } |
182 | |
c47ff5f1 |
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 |
694468e3 |
185 | returns C<moooo>. But how different would this be for the C<Horse>? |
186 | |
769c2898 |
187 | { |
188 | package Horse; |
189 | |
694468e3 |
190 | sub sound { "neigh" } |
769c2898 |
191 | |
694468e3 |
192 | sub speak { |
193 | my $class = shift; |
194 | print "a $class goes ", $class->sound, "!\n" |
195 | } |
196 | } |
197 | |
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! |
201 | |
202 | =head2 Inheriting the windpipes |
203 | |
204 | We'll define a common subroutine package called C<Animal>, with the |
205 | definition for C<speak>: |
206 | |
769c2898 |
207 | { |
208 | package Animal; |
209 | |
694468e3 |
210 | sub speak { |
211 | my $class = shift; |
212 | print "a $class goes ", $class->sound, "!\n" |
213 | } |
214 | } |
215 | |
216 | Then, for each animal, we say it "inherits" from C<Animal>, along |
217 | with the animal-specific sound: |
218 | |
769c2898 |
219 | { |
220 | package Cow; |
221 | |
222 | # Not safe under `use strict', see below |
694468e3 |
223 | @ISA = qw(Animal); |
769c2898 |
224 | |
694468e3 |
225 | sub sound { "moooo" } |
226 | } |
227 | |
228 | Note the added C<@ISA> array. We'll get to that in a minute. |
229 | |
c47ff5f1 |
230 | But what happens when we invoke C<< Cow->speak >> now? |
694468e3 |
231 | |
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>. |
236 | |
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. |
240 | |
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 |
c47ff5f1 |
243 | C<< $class->sound >>, it'll be looking for C<< Cow->sound >>, which |
694468e3 |
244 | gets it on the first try without looking at C<@ISA>. Success! |
245 | |
246 | =head2 A few notes about @ISA |
247 | |
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. |
252 | |
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 |
257 | inheritance. |
258 | |
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 |
dbe48302 |
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), |
694468e3 |
263 | so there's a couple of straightforward ways to handle that. |
264 | |
265 | The easiest is to just spell the package name out: |
266 | |
267 | @Cow::ISA = qw(Animal); |
268 | |
dbe48302 |
269 | Or allow it as an implicitly named package variable: |
694468e3 |
270 | |
271 | package Cow; |
769c2898 |
272 | our @ISA = qw(Animal); |
694468e3 |
273 | |
274 | If you're bringing in the class from outside, via an object-oriented |
275 | module, you change: |
276 | |
277 | package Cow; |
278 | use Animal; |
769c2898 |
279 | our @ISA = qw(Animal); |
694468e3 |
280 | |
281 | into just: |
282 | |
283 | package Cow; |
284 | use base qw(Animal); |
285 | |
769c2898 |
286 | And that's pretty darn compact. Read about the L<base|base> pragma. |
694468e3 |
287 | |
288 | =head2 Overriding the methods |
289 | |
290 | Let's add a mouse, which can barely be heard: |
291 | |
769c2898 |
292 | # Animal package that we wrote before, goes here |
293 | { |
294 | package Mouse; |
295 | |
296 | our @ISA = qw(Animal); |
297 | |
694468e3 |
298 | sub sound { "squeak" } |
769c2898 |
299 | |
694468e3 |
300 | sub speak { |
301 | my $class = shift; |
302 | print "a $class goes ", $class->sound, "!\n"; |
303 | print "[but you can barely hear it!]\n"; |
304 | } |
305 | } |
306 | |
307 | Mouse->speak; |
308 | |
309 | which results in: |
310 | |
311 | a Mouse goes squeak! |
312 | [but you can barely hear it!] |
313 | |
c47ff5f1 |
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 |
694468e3 |
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>. |
319 | |
c47ff5f1 |
320 | But we've now duplicated some of the code from C<< Animal->speak >>, |
694468e3 |
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! |
324 | |
325 | First, we can invoke the C<Animal::speak> method directly: |
326 | |
769c2898 |
327 | # Animal package that we wrote before, goes here |
328 | { |
329 | package Mouse; |
330 | |
331 | our @ISA = qw(Animal); |
332 | |
694468e3 |
333 | sub sound { "squeak" } |
769c2898 |
334 | |
694468e3 |
335 | sub speak { |
336 | my $class = shift; |
337 | Animal::speak($class); |
338 | print "[but you can barely hear it!]\n"; |
339 | } |
340 | } |
341 | |
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, |
c47ff5f1 |
345 | if we invoke C<< Animal->speak >> there, the first parameter to the |
694468e3 |
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 |
348 | to this package. |
349 | |
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 |
354 | subroutine. |
355 | |
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. |
360 | |
361 | =head2 Starting the search from a different place |
362 | |
363 | A better solution is to tell Perl to search from a higher place |
364 | in the inheritance chain: |
365 | |
366 | # same Animal as before |
769c2898 |
367 | { |
368 | package Mouse; |
369 | |
694468e3 |
370 | # same @ISA, &sound as before |
769c2898 |
371 | |
694468e3 |
372 | sub speak { |
373 | my $class = shift; |
374 | $class->Animal::speak; |
375 | print "[but you can barely hear it!]\n"; |
376 | } |
377 | } |
378 | |
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. |
384 | |
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? |
389 | |
390 | =head2 The SUPER way of doing things |
391 | |
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: |
395 | |
396 | # same Animal as before |
769c2898 |
397 | { |
398 | package Mouse; |
399 | |
694468e3 |
400 | # same @ISA, &sound as before |
769c2898 |
401 | |
694468e3 |
402 | sub speak { |
403 | my $class = shift; |
404 | $class->SUPER::speak; |
405 | print "[but you can barely hear it!]\n"; |
406 | } |
407 | } |
408 | |
409 | So, C<SUPER::speak> means look in the current package's C<@ISA> for |
410 | C<speak>, invoking the first one found. |
411 | |
412 | =head2 Where we're at so far... |
413 | |
414 | So far, we've seen the method arrow syntax: |
415 | |
416 | Class->method(@args); |
417 | |
418 | or the equivalent: |
419 | |
769c2898 |
420 | my $a = "Class"; |
694468e3 |
421 | $a->method(@args); |
422 | |
423 | which constructs an argument list of: |
424 | |
425 | ("Class", @args) |
426 | |
427 | and attempts to invoke |
428 | |
429 | Class::method("Class", @Args); |
430 | |
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. |
434 | |
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. |
441 | |
442 | =head2 A horse is a horse, of course of course -- or is it? |
443 | |
444 | Let's start with the code for the C<Animal> class |
445 | and the C<Horse> class: |
446 | |
769c2898 |
447 | { |
448 | package Animal; |
449 | |
694468e3 |
450 | sub speak { |
451 | my $class = shift; |
452 | print "a $class goes ", $class->sound, "!\n" |
453 | } |
454 | } |
769c2898 |
455 | |
456 | { |
457 | package Horse; |
458 | |
459 | our @ISA = qw(Animal); |
460 | |
694468e3 |
461 | sub sound { "neigh" } |
462 | } |
463 | |
c47ff5f1 |
464 | This lets us invoke C<< Horse->speak >> to ripple upward to |
694468e3 |
465 | C<Animal::speak>, calling back to C<Horse::sound> to get the specific |
466 | sound, and the output of: |
467 | |
468 | a Horse goes neigh! |
469 | |
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. |
476 | |
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. |
481 | |
769c2898 |
482 | my $name = "Mr. Ed"; |
694468e3 |
483 | my $talking = \$name; |
484 | |
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>: |
488 | |
489 | bless $talking, Horse; |
490 | |
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. |
496 | |
497 | =head2 Invoking an instance method |
498 | |
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: |
501 | |
502 | my $noise = $talking->sound; |
503 | |
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.) |
509 | |
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: |
514 | |
515 | Horse::sound($talking) |
516 | |
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. |
520 | |
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 |
dbe48302 |
525 | is an instance (a blessed reference) or a class name (a string). |
694468e3 |
526 | |
527 | =head2 Accessing the instance data |
528 | |
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 |
531 | the name: |
532 | |
769c2898 |
533 | { |
534 | package Horse; |
535 | |
536 | our @ISA = qw(Animal); |
537 | |
694468e3 |
538 | sub sound { "neigh" } |
769c2898 |
539 | |
694468e3 |
540 | sub name { |
541 | my $self = shift; |
542 | $$self; |
543 | } |
544 | } |
c47ff5f1 |
545 | |
694468e3 |
546 | Now we call for the name: |
547 | |
548 | print $talking->name, " says ", $talking->sound, "\n"; |
549 | |
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: |
556 | |
557 | Mr. Ed says neigh. |
558 | |
559 | =head2 How to build a horse |
560 | |
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 |
566 | build a new horse: |
567 | |
769c2898 |
568 | { |
569 | package Horse; |
570 | |
571 | our @ISA = qw(Animal); |
572 | |
694468e3 |
573 | sub sound { "neigh" } |
769c2898 |
574 | |
694468e3 |
575 | sub name { |
576 | my $self = shift; |
577 | $$self; |
578 | } |
769c2898 |
579 | |
694468e3 |
580 | sub named { |
581 | my $class = shift; |
769c2898 |
582 | my $name = shift; |
694468e3 |
583 | bless \$name, $class; |
584 | } |
585 | } |
586 | |
587 | Now with the new C<named> method, we can build a horse: |
588 | |
589 | my $talking = Horse->named("Mr. Ed"); |
590 | |
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. |
595 | |
dbe48302 |
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, |
605 | right?) |
606 | |
694468e3 |
607 | =head2 Inheriting the constructor |
608 | |
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: |
612 | |
769c2898 |
613 | { |
614 | package Animal; |
615 | |
694468e3 |
616 | sub speak { |
617 | my $class = shift; |
618 | print "a $class goes ", $class->sound, "!\n" |
619 | } |
769c2898 |
620 | |
694468e3 |
621 | sub name { |
622 | my $self = shift; |
623 | $$self; |
624 | } |
769c2898 |
625 | |
694468e3 |
626 | sub named { |
627 | my $class = shift; |
769c2898 |
628 | my $name = shift; |
694468e3 |
629 | bless \$name, $class; |
630 | } |
631 | } |
769c2898 |
632 | |
633 | { |
634 | package Horse; |
635 | |
636 | our @ISA = qw(Animal); |
637 | |
694468e3 |
638 | sub sound { "neigh" } |
639 | } |
640 | |
641 | Ahh, but what happens if we invoke C<speak> on an instance? |
642 | |
643 | my $talking = Horse->named("Mr. Ed"); |
644 | $talking->speak; |
645 | |
646 | We get a debugging value: |
647 | |
648 | a Horse=SCALAR(0xaca42ac) goes neigh! |
649 | |
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. |
654 | |
655 | =head2 Making a method work with either classes or instances |
656 | |
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: |
662 | |
663 | sub name { |
664 | my $either = shift; |
665 | ref $either |
769c2898 |
666 | ? $$either # it's an instance, return name |
694468e3 |
667 | : "an unnamed $either"; # it's a class, return generic |
668 | } |
669 | |
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: |
674 | |
675 | my $talking = Horse->named("Mr. Ed"); |
769c2898 |
676 | |
677 | print Horse->name, "\n"; # prints "an unnamed Horse\n" |
694468e3 |
678 | print $talking->name, "\n"; # prints "Mr Ed.\n" |
679 | |
680 | and now we'll fix C<speak> to use this: |
681 | |
682 | sub speak { |
683 | my $either = shift; |
684 | print $either->name, " goes ", $either->sound, "\n"; |
685 | } |
686 | |
687 | And since C<sound> already worked with either a class or an instance, |
688 | we're done! |
689 | |
690 | =head2 Adding parameters to a method |
691 | |
692 | Let's train our animals to eat: |
693 | |
769c2898 |
694 | { |
695 | package Animal; |
694468e3 |
696 | sub named { |
697 | my $class = shift; |
769c2898 |
698 | my $name = shift; |
694468e3 |
699 | bless \$name, $class; |
700 | } |
769c2898 |
701 | |
694468e3 |
702 | sub name { |
703 | my $either = shift; |
704 | ref $either |
769c2898 |
705 | ? $$either # it's an instance, return name |
694468e3 |
706 | : "an unnamed $either"; # it's a class, return generic |
707 | } |
769c2898 |
708 | |
694468e3 |
709 | sub speak { |
710 | my $either = shift; |
711 | print $either->name, " goes ", $either->sound, "\n"; |
712 | } |
769c2898 |
713 | |
694468e3 |
714 | sub eat { |
715 | my $either = shift; |
769c2898 |
716 | my $food = shift; |
694468e3 |
717 | print $either->name, " eats $food.\n"; |
718 | } |
719 | } |
769c2898 |
720 | |
721 | { |
722 | package Horse; |
723 | |
724 | our @ISA = qw(Animal); |
725 | |
694468e3 |
726 | sub sound { "neigh" } |
727 | } |
769c2898 |
728 | |
729 | { |
730 | package Sheep; |
731 | |
732 | our @ISA = qw(Animal); |
733 | |
694468e3 |
734 | sub sound { "baaaah" } |
735 | } |
736 | |
737 | And now try it out: |
738 | |
739 | my $talking = Horse->named("Mr. Ed"); |
740 | $talking->eat("hay"); |
769c2898 |
741 | |
694468e3 |
742 | Sheep->eat("grass"); |
743 | |
744 | which prints: |
745 | |
746 | Mr. Ed eats hay. |
747 | an unnamed Sheep eats grass. |
748 | |
749 | An instance method with parameters gets invoked with the instance, |
750 | and then the list of parameters. So that first invocation is like: |
751 | |
752 | Animal::eat($talking, "hay"); |
753 | |
754 | =head2 More interesting instances |
755 | |
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. |
762 | |
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. |
767 | |
768 | Let's make a sheep that has a name and a color: |
769 | |
769c2898 |
770 | my $data = { Name => "Evil", Color => "black" }; |
771 | my $bad = bless $data, Sheep; |
694468e3 |
772 | |
c47ff5f1 |
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 |
694468e3 |
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: |
777 | |
778 | ## in Animal |
779 | sub name { |
780 | my $either = shift; |
781 | ref $either ? |
782 | $either->{Name} : |
783 | "an unnamed $either"; |
784 | } |
785 | |
786 | And of course C<named> still builds a scalar sheep, so let's fix that |
787 | as well: |
788 | |
789 | ## in Animal |
790 | sub named { |
791 | my $class = shift; |
769c2898 |
792 | my $name = shift; |
793 | my $self = { Name => $name, Color => $class->default_color }; |
794 | |
694468e3 |
795 | bless $self, $class; |
796 | } |
797 | |
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: |
801 | |
802 | ## in Sheep |
803 | sub default_color { "white" } |
804 | |
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>: |
808 | |
809 | ## in Animal |
810 | sub default_color { "brown" } |
811 | |
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. |
815 | |
816 | =head2 A horse of a different color |
817 | |
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. |
820 | |
821 | ## in Animal |
822 | sub color { |
823 | $_[0]->{Color} |
824 | } |
769c2898 |
825 | |
694468e3 |
826 | sub set_color { |
827 | $_[0]->{Color} = $_[1]; |
828 | } |
829 | |
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: |
834 | |
835 | my $talking = Horse->named("Mr. Ed"); |
836 | $talking->set_color("black-and-white"); |
837 | print $talking->name, " is colored ", $talking->color, "\n"; |
838 | |
839 | which results in: |
840 | |
841 | Mr. Ed is colored black-and-white |
842 | |
843 | =head2 Summary |
844 | |
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. |
853 | |
854 | =head1 SEE ALSO |
855 | |
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 |
890a53b9 |
858 | tutorial for those who already know objects), L<perltooc> (dealing |
8257a158 |
859 | with class data), L<perlbot> (for some more tricks), and books such as |
860 | Damian Conway's excellent I<Object Oriented Perl>. |
861 | |
862 | Some modules which might prove interesting are Class::Accessor, |
863 | Class::Class, Class::Contract, Class::Data::Inheritable, |
864 | Class::MethodMaker and Tie::SecureHash |
694468e3 |
865 | |
866 | =head1 COPYRIGHT |
867 | |
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. |
873 | |
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. |
878 | |
879 | Portions of this text have been derived from materials originally |
880 | appearing in I<Linux Magazine> and used with permission. |