| 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> by |
| 242 | default (see L<mro> for alternatives). Typically, each C<@ISA> has |
| 243 | only one element (multiple elements means multiple inheritance and |
| 244 | multiple headaches), so we get a nice tree of 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 C<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 an empty string 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. |