| 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 refs> 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 (pronounced "is a"). 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 has declared that C<Cow> "is a" C<Animal>. |
| 236 | Note that it's an array, not a simple single value, because on rare |
| 237 | occasions, it makes sense to have more than one parent class searched |
| 238 | 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 declare it as package global variable: |
| 257 | |
| 258 | package Cow; |
| 259 | our @ISA = qw(Animal); |
| 260 | |
| 261 | Or allow it as an implicitly named package variable: |
| 262 | |
| 263 | package Cow; |
| 264 | use vars qw(@ISA); |
| 265 | @ISA = qw(Animal); |
| 266 | |
| 267 | If the C<Animal> class comes from another (object-oriented) module, then |
| 268 | just employ C<use base> to specify that C<Animal> should serve as the basis |
| 269 | for the C<Cow> class: |
| 270 | |
| 271 | package Cow; |
| 272 | use base qw(Animal); |
| 273 | |
| 274 | Now that's pretty darn simple! |
| 275 | |
| 276 | =head2 Overriding the methods |
| 277 | |
| 278 | Let's add a mouse, which can barely be heard: |
| 279 | |
| 280 | # Animal package from before |
| 281 | { package Mouse; |
| 282 | @ISA = qw(Animal); |
| 283 | sub sound { "squeak" } |
| 284 | sub speak { |
| 285 | my $class = shift; |
| 286 | print "a $class goes ", $class->sound, "!\n"; |
| 287 | print "[but you can barely hear it!]\n"; |
| 288 | } |
| 289 | } |
| 290 | |
| 291 | Mouse->speak; |
| 292 | |
| 293 | which results in: |
| 294 | |
| 295 | a Mouse goes squeak! |
| 296 | [but you can barely hear it!] |
| 297 | |
| 298 | Here, C<Mouse> has its own speaking routine, so C<< Mouse->speak >> |
| 299 | doesn't immediately invoke C<< Animal->speak >>. This is known as |
| 300 | "overriding". In fact, we don't even need to say that a C<Mouse> is |
| 301 | an C<Animal> at all, because all of the methods needed for C<speak> are |
| 302 | completely defined for C<Mouse>; this is known as "duck typing": |
| 303 | "If it walks like a duck and quacks like a duck, I would call it a duck" |
| 304 | (James Whitcomb). However, it would probably be beneficial to allow a |
| 305 | closer examination to conclude that a C<Mouse> is indeed an C<Animal>, |
| 306 | so it is actually better to define C<Mouse> with C<Animal> as its base |
| 307 | (that is, it is better to "derive C<Mouse> from C<Animal>"). |
| 308 | |
| 309 | Moreover, this duplication of code could become a maintenance headache |
| 310 | (though code-reuse is not actually a good reason for inheritance; good |
| 311 | design practices dictate that a derived class should be usable wherever |
| 312 | its base class is usable, which might not be the outcome if code-reuse |
| 313 | is the sole criterion for inheritance. Just remember that a C<Mouse> |
| 314 | should always act like an C<Animal>). |
| 315 | |
| 316 | So, let's make C<Mouse> an C<Animal>! |
| 317 | |
| 318 | The obvious solution is to invoke C<Animal::speak> directly: |
| 319 | |
| 320 | # Animal package from before |
| 321 | { package Mouse; |
| 322 | @ISA = qw(Animal); |
| 323 | sub sound { "squeak" } |
| 324 | sub speak { |
| 325 | my $class = shift; |
| 326 | Animal::speak($class); |
| 327 | print "[but you can barely hear it!]\n"; |
| 328 | } |
| 329 | } |
| 330 | |
| 331 | Note that we're using C<Animal::speak>. If we were to invoke |
| 332 | C<< Animal->speak >> instead, the first parameter to C<Animal::speak> |
| 333 | would automatically be C<"Animal"> rather than C<"Mouse">, so that |
| 334 | the call to C<< $class->sound >> in C<Animal::speak> would become |
| 335 | C<< Animal->sound >> rather than C<< Mouse->sound >>. |
| 336 | |
| 337 | Also, without the method arrow C<< -> >>, it becomes necessary to specify |
| 338 | the first parameter to C<Animal::speak> ourselves, which is why C<$class> |
| 339 | is explicitly passed: C<Animal::speak($class)>. |
| 340 | |
| 341 | However, invoking C<Animal::speak> directly is a mess: Firstly, it assumes |
| 342 | that the C<speak> method is a member of the C<Animal> class; what if C<Animal> |
| 343 | actually inherits C<speak> from its own base? Because we are no longer using |
| 344 | C<< -> >> to access C<speak>, the special method look up mechanism wouldn't be |
| 345 | used, so C<speak> wouldn't even be found! |
| 346 | |
| 347 | The second problem is more subtle: C<Animal> is now hardwired into the subroutine |
| 348 | selection. Let's assume that C<Animal::speak> does exist. What happens when, |
| 349 | at a later time, someone expands the class hierarchy by having C<Mouse> |
| 350 | inherit from C<Mus> instead of C<Animal>. Unless the invocation of C<Animal::speak> |
| 351 | is also changed to an invocation of C<Mus::speak>, centuries worth of taxonomical |
| 352 | classification could be obliterated! |
| 353 | |
| 354 | What we have here is a fragile or leaky abstraction; it is the beginning of a |
| 355 | maintenance nightmare. What we need is the ability to search for the right |
| 356 | method wih as few assumptions as possible. |
| 357 | |
| 358 | =head2 Starting the search from a different place |
| 359 | |
| 360 | A I<better> solution is to tell Perl where in the inheritance chain to begin searching |
| 361 | for C<speak>. This can be achieved with a modified version of the method arrow C<< -> >>: |
| 362 | |
| 363 | ClassName->FirstPlaceToLook::method |
| 364 | |
| 365 | So, the improved C<Mouse> class is: |
| 366 | |
| 367 | # same Animal as before |
| 368 | { package Mouse; |
| 369 | # same @ISA, &sound as before |
| 370 | sub speak { |
| 371 | my $class = shift; |
| 372 | $class->Animal::speak; |
| 373 | print "[but you can barely hear it!]\n"; |
| 374 | } |
| 375 | } |
| 376 | |
| 377 | Using this syntax, we start with C<Animal> to find C<speak>, and then |
| 378 | use all of C<Animal>'s inheritance chain if it is not found immediately. |
| 379 | As usual, the first parameter to C<speak> would be C<$class>, so we no |
| 380 | longer need to pass C<$class> explicitly to C<speak>. |
| 381 | |
| 382 | But what about the second problem? We're still hardwiring C<Animal> into |
| 383 | the method lookup. |
| 384 | |
| 385 | =head2 The SUPER way of doing things |
| 386 | |
| 387 | If C<Animal> is replaced with the special placeholder C<SUPER> in that |
| 388 | invocation, then the contents of C<Mouse>'s C<@ISA> are used for the |
| 389 | search, beginning with C<$ISA[0]>. So, all of the problems can be fixed |
| 390 | as follows: |
| 391 | |
| 392 | # same Animal as before |
| 393 | { package Mouse; |
| 394 | # same @ISA, &sound as before |
| 395 | sub speak { |
| 396 | my $class = shift; |
| 397 | $class->SUPER::speak; |
| 398 | print "[but you can barely hear it!]\n"; |
| 399 | } |
| 400 | } |
| 401 | |
| 402 | In general, C<SUPER::speak> means look in the current package's C<@ISA> |
| 403 | for a class that implements C<speak>, and invoke the first one found. |
| 404 | The placeholder is called C<SUPER>, because many other languages refer |
| 405 | to base classes as "I<super>classes", and Perl likes to be eclectic. |
| 406 | |
| 407 | Note that a call such as |
| 408 | |
| 409 | $class->SUPER::method; |
| 410 | |
| 411 | does I<not> look in the C<@ISA> of C<$class> unless C<$class> happens to |
| 412 | be the current package. |
| 413 | |
| 414 | =head2 Let's review... |
| 415 | |
| 416 | So far, we've seen the method arrow syntax: |
| 417 | |
| 418 | Class->method(@args); |
| 419 | |
| 420 | or the equivalent: |
| 421 | |
| 422 | $a = "Class"; |
| 423 | $a->method(@args); |
| 424 | |
| 425 | which constructs an argument list of: |
| 426 | |
| 427 | ("Class", @args) |
| 428 | |
| 429 | and attempts to invoke: |
| 430 | |
| 431 | Class::method("Class", @args); |
| 432 | |
| 433 | However, if C<Class::method> is not found, then C<@Class::ISA> is examined |
| 434 | (recursively) to locate a class (a package) that does indeed contain C<method>, |
| 435 | and that subroutine is invoked instead. |
| 436 | |
| 437 | Using this simple syntax, we have class methods, (multiple) inheritance, |
| 438 | overriding, and extending. Using just what we've seen so far, we've |
| 439 | been able to factor out common code (though that's never a good reason |
| 440 | for inheritance!), and provide a nice way to reuse implementations with |
| 441 | variations. |
| 442 | |
| 443 | Now, what about data? |
| 444 | |
| 445 | =head2 A horse is a horse, of course of course -- or is it? |
| 446 | |
| 447 | Let's start with the code for the C<Animal> class |
| 448 | and the C<Horse> class: |
| 449 | |
| 450 | { package Animal; |
| 451 | sub speak { |
| 452 | my $class = shift; |
| 453 | print "a $class goes ", $class->sound, "!\n"; |
| 454 | } |
| 455 | } |
| 456 | { package Horse; |
| 457 | @ISA = qw(Animal); |
| 458 | sub sound { "neigh" } |
| 459 | } |
| 460 | |
| 461 | This lets us invoke C<< Horse->speak >> to ripple upward to |
| 462 | C<Animal::speak>, calling back to C<Horse::sound> to get the specific |
| 463 | sound, and the output of: |
| 464 | |
| 465 | a Horse goes neigh! |
| 466 | |
| 467 | But all of our Horse objects would have to be absolutely identical. |
| 468 | If we add a subroutine, all horses automatically share it. That's |
| 469 | great for making horses the same, but how do we capture the |
| 470 | distinctions of an individual horse? For example, suppose we want |
| 471 | to give our first horse a name. There's got to be a way to keep its |
| 472 | name separate from the other horses. |
| 473 | |
| 474 | That is to say, we want particular instances of C<Horse> to have |
| 475 | different names. |
| 476 | |
| 477 | In Perl, any reference can be an "instance", so let's start with the |
| 478 | simplest reference that can hold a horse's name: a scalar reference. |
| 479 | |
| 480 | my $name = "Mr. Ed"; |
| 481 | my $horse = \$name; |
| 482 | |
| 483 | So, now C<$horse> is a reference to what will be the instance-specific |
| 484 | data (the name). The final step is to turn this reference into a real |
| 485 | instance of a C<Horse> by using the special operator C<bless>: |
| 486 | |
| 487 | bless $horse, Horse; |
| 488 | |
| 489 | This operator stores information about the package named C<Horse> into |
| 490 | the thing pointed at by the reference. At this point, we say |
| 491 | C<$horse> is an instance of C<Horse>. That is, it's a specific |
| 492 | horse. The reference is otherwise unchanged, and can still be used |
| 493 | with traditional dereferencing operators. |
| 494 | |
| 495 | =head2 Invoking an instance method |
| 496 | |
| 497 | The method arrow can be used on instances, as well as classes (the names |
| 498 | of packages). So, let's get the sound that C<$horse> makes: |
| 499 | |
| 500 | my $noise = $horse->sound("some", "unnecessary", "args"); |
| 501 | |
| 502 | To invoke C<sound>, Perl first notes that C<$horse> is a blessed |
| 503 | reference (and thus an instance). It then constructs an argument |
| 504 | list, as per usual. |
| 505 | |
| 506 | Now for the fun part: Perl takes the class in which the instance was |
| 507 | blessed, in this case C<Horse>, and uses that class to locate the |
| 508 | subroutine. In this case, C<Horse::sound> is found directly (without |
| 509 | using inheritance). In the end, it is as though our initial line were |
| 510 | written as follows: |
| 511 | |
| 512 | my $noise = Horse::sound($horse, "some", "unnecessary", "args"); |
| 513 | |
| 514 | Note that the first parameter here is still the instance, not the name |
| 515 | of the class as before. We'll get C<neigh> as the return value, and |
| 516 | that'll end up as the C<$noise> variable above. |
| 517 | |
| 518 | If Horse::sound had not been found, we'd be wandering up the C<@Horse::ISA> |
| 519 | array, trying to find the method in one of the superclasses. The only |
| 520 | difference between a class method and an instance method is whether the |
| 521 | first parameter is an instance (a blessed reference) or a class name (a |
| 522 | string). |
| 523 | |
| 524 | =head2 Accessing the instance data |
| 525 | |
| 526 | Because we get the instance as the first parameter, we can now access |
| 527 | the instance-specific data. In this case, let's add a way to get at |
| 528 | the name: |
| 529 | |
| 530 | { package Horse; |
| 531 | @ISA = qw(Animal); |
| 532 | sub sound { "neigh" } |
| 533 | sub name { |
| 534 | my $self = shift; |
| 535 | $$self; |
| 536 | } |
| 537 | } |
| 538 | |
| 539 | Inside C<Horse::name>, the C<@_> array contains: |
| 540 | |
| 541 | ($horse, "some", "unnecessary", "args") |
| 542 | |
| 543 | so the C<shift> stores C<$horse> into C<$self>. Then, C<$self> gets |
| 544 | de-referenced with C<$$self> as normal, yielding C<"Mr. Ed">. |
| 545 | |
| 546 | It's traditional to C<shift> the first parameter into a variable named |
| 547 | C<$self> for instance methods and into a variable named C<$class> for |
| 548 | class methods. |
| 549 | |
| 550 | Then, the following line: |
| 551 | |
| 552 | print $horse->name, " says ", $horse->sound, "\n"; |
| 553 | |
| 554 | outputs: |
| 555 | |
| 556 | Mr. Ed says neigh. |
| 557 | |
| 558 | =head2 How to build a horse |
| 559 | |
| 560 | Of course, if we constructed all of our horses by hand, we'd most |
| 561 | likely make mistakes from time to time. We're also violating one of |
| 562 | the properties of object-oriented programming, in that the "inside |
| 563 | guts" of a Horse are visible. That's good if you're a veterinarian, |
| 564 | but not if you just like to own horses. So, let's have the Horse |
| 565 | class handle the details inside a class method: |
| 566 | |
| 567 | { package Horse; |
| 568 | @ISA = qw(Animal); |
| 569 | sub sound { "neigh" } |
| 570 | sub name { |
| 571 | my $self = shift; # instance method, so use $self |
| 572 | $$self; |
| 573 | } |
| 574 | sub named { |
| 575 | my $class = shift; # class method, so use $class |
| 576 | my $name = shift; |
| 577 | bless \$name, $class; |
| 578 | } |
| 579 | } |
| 580 | |
| 581 | Now with the new C<named> method, we can build a horse as follows: |
| 582 | |
| 583 | my $horse = Horse->named("Mr. Ed"); |
| 584 | |
| 585 | Notice we're back to a class method, so the two arguments to |
| 586 | C<Horse::named> are C<Horse> and C<Mr. Ed>. The C<bless> operator |
| 587 | not only blesses C<\$name>, it also returns that reference. |
| 588 | |
| 589 | This C<Horse::named> method is called a "constructor". |
| 590 | |
| 591 | We've called the constructor C<named> here, so that it quickly denotes |
| 592 | the constructor's argument as the name for this particular C<Horse>. |
| 593 | You can use different constructors with different names for different |
| 594 | ways of "giving birth" to the object (like maybe recording its |
| 595 | pedigree or date of birth). However, you'll find that most people |
| 596 | coming to Perl from more limited languages use a single constructor |
| 597 | named C<new>, with various ways of interpreting the arguments to |
| 598 | C<new>. Either style is fine, as long as you document your particular |
| 599 | way of giving birth to an object. (And you I<were> going to do that, |
| 600 | right?) |
| 601 | |
| 602 | =head2 Inheriting the constructor |
| 603 | |
| 604 | But was there anything specific to C<Horse> in that method? No. Therefore, |
| 605 | it's also the same recipe for building anything else that inherited from |
| 606 | C<Animal>, so let's put C<name> and C<named> there: |
| 607 | |
| 608 | { package Animal; |
| 609 | sub speak { |
| 610 | my $class = shift; |
| 611 | print "a $class goes ", $class->sound, "!\n"; |
| 612 | } |
| 613 | sub name { |
| 614 | my $self = shift; |
| 615 | $$self; |
| 616 | } |
| 617 | sub named { |
| 618 | my $class = shift; |
| 619 | my $name = shift; |
| 620 | bless \$name, $class; |
| 621 | } |
| 622 | } |
| 623 | { package Horse; |
| 624 | @ISA = qw(Animal); |
| 625 | sub sound { "neigh" } |
| 626 | } |
| 627 | |
| 628 | Ahh, but what happens if we invoke C<speak> on an instance? |
| 629 | |
| 630 | my $horse = Horse->named("Mr. Ed"); |
| 631 | $horse->speak; |
| 632 | |
| 633 | We get a debugging value: |
| 634 | |
| 635 | a Horse=SCALAR(0xaca42ac) goes neigh! |
| 636 | |
| 637 | Why? Because the C<Animal::speak> routine is expecting a classname as |
| 638 | its first parameter, not an instance. When the instance is passed in, |
| 639 | we'll end up using a blessed scalar reference as a string, and that |
| 640 | shows up as we saw it just now. |
| 641 | |
| 642 | =head2 Making a method work with either classes or instances |
| 643 | |
| 644 | All we need is for a method to detect if it is being called on a class |
| 645 | or called on an instance. The most straightforward way is with the |
| 646 | C<ref> operator. This returns a string (the classname) when used on a |
| 647 | blessed reference, and an empty string when used on a string (like a |
| 648 | classname). Let's modify the C<name> method first to notice the change: |
| 649 | |
| 650 | sub name { |
| 651 | my $either = shift; |
| 652 | ref $either ? $$either : "Any $either"; |
| 653 | } |
| 654 | |
| 655 | Here, the C<?:> operator comes in handy to select either the |
| 656 | dereference or a derived string. Now we can use this with either an |
| 657 | instance or a class. Note that I've changed the first parameter |
| 658 | holder to C<$either> to show that this is intended: |
| 659 | |
| 660 | my $horse = Horse->named("Mr. Ed"); |
| 661 | print Horse->name, "\n"; # prints "Any Horse\n" |
| 662 | print $horse->name, "\n"; # prints "Mr Ed.\n" |
| 663 | |
| 664 | and now we'll fix C<speak> to use this: |
| 665 | |
| 666 | sub speak { |
| 667 | my $either = shift; |
| 668 | print $either->name, " goes ", $either->sound, "\n"; |
| 669 | } |
| 670 | |
| 671 | And since C<sound> already worked with either a class or an instance, |
| 672 | we're done! |
| 673 | |
| 674 | =head2 Adding parameters to a method |
| 675 | |
| 676 | Let's train our animals to eat: |
| 677 | |
| 678 | { package Animal; |
| 679 | sub named { |
| 680 | my $class = shift; |
| 681 | my $name = shift; |
| 682 | bless \$name, $class; |
| 683 | } |
| 684 | sub name { |
| 685 | my $either = shift; |
| 686 | ref $either ? $$either : "Any $either"; |
| 687 | } |
| 688 | sub speak { |
| 689 | my $either = shift; |
| 690 | print $either->name, " goes ", $either->sound, "\n"; |
| 691 | } |
| 692 | sub eat { |
| 693 | my $either = shift; |
| 694 | my $food = shift; |
| 695 | print $either->name, " eats $food.\n"; |
| 696 | } |
| 697 | } |
| 698 | { package Horse; |
| 699 | @ISA = qw(Animal); |
| 700 | sub sound { "neigh" } |
| 701 | } |
| 702 | { package Sheep; |
| 703 | @ISA = qw(Animal); |
| 704 | sub sound { "baaaah" } |
| 705 | } |
| 706 | |
| 707 | And now try it out: |
| 708 | |
| 709 | my $horse = Horse->named("Mr. Ed"); |
| 710 | $horse->eat("hay"); |
| 711 | Sheep->eat("grass"); |
| 712 | |
| 713 | which prints: |
| 714 | |
| 715 | Mr. Ed eats hay. |
| 716 | Any Sheep eats grass. |
| 717 | |
| 718 | An instance method with parameters gets invoked with the instance, |
| 719 | and then the list of parameters. So that first invocation is like: |
| 720 | |
| 721 | Animal::eat($horse, "hay"); |
| 722 | |
| 723 | =head2 More interesting instances |
| 724 | |
| 725 | What if an instance needs more data? Most interesting instances are |
| 726 | made of many items, each of which can in turn be a reference or even |
| 727 | another object. The easiest way to store these is often in a hash. |
| 728 | The keys of the hash serve as the names of parts of the object (often |
| 729 | called "instance variables" or "member variables"), and the |
| 730 | corresponding values are, well, the values. |
| 731 | |
| 732 | But how do we turn the horse into a hash? Recall that an object was |
| 733 | any blessed reference. We can just as easily make it a blessed hash |
| 734 | reference as a blessed scalar reference, as long as everything that |
| 735 | looks at the reference is changed accordingly. |
| 736 | |
| 737 | Let's make a sheep that has a name and a color: |
| 738 | |
| 739 | my $bad = bless { Name => "Evil", Color => "black" }, Sheep; |
| 740 | |
| 741 | so C<< $bad->{Name} >> has C<Evil>, and C<< $bad->{Color} >> has |
| 742 | C<black>. But we want to make C<< $bad->name >> access the name, and |
| 743 | that's now messed up because it's expecting a scalar reference. Not |
| 744 | to worry, because that's pretty easy to fix up. |
| 745 | |
| 746 | One solution is to override C<Animal::name> and C<Animal::named> by |
| 747 | defining them anew in C<Sheep>, but then any methods added later to |
| 748 | C<Animal> might still mess up, and we'd have to override all of those |
| 749 | too. Therefore, it's never a good idea to define the data layout in a |
| 750 | way that's different from the data layout of the base classes. In fact, |
| 751 | it's a good idea to use blessed hash references in all cases. Also, this |
| 752 | is why it's important to have constructors do the low-level work. So, |
| 753 | let's redefine C<Animal>: |
| 754 | |
| 755 | ## in Animal |
| 756 | sub name { |
| 757 | my $either = shift; |
| 758 | ref $either ? $either->{Name} : "Any $either"; |
| 759 | } |
| 760 | sub named { |
| 761 | my $class = shift; |
| 762 | my $name = shift; |
| 763 | my $self = { Name => $name }; |
| 764 | bless $self, $class; |
| 765 | } |
| 766 | |
| 767 | Of course, we still need to override C<named> in order to handle |
| 768 | constructing a C<Sheep> with a certain color: |
| 769 | |
| 770 | ## in Sheep |
| 771 | sub named { |
| 772 | my ($class, $name) = @_; |
| 773 | my $self = $class->SUPER::named(@_); |
| 774 | $$self{Color} = $class->default_color; |
| 775 | $self |
| 776 | } |
| 777 | |
| 778 | (Note that C<@_> contains the parameters to C<named>.) |
| 779 | |
| 780 | What's this C<default_color>? Well, if C<named> has only the name, |
| 781 | we still need to set a color, so we'll have a class-specific default color. |
| 782 | For a sheep, we might define it as white: |
| 783 | |
| 784 | ## in Sheep |
| 785 | sub default_color { "white" } |
| 786 | |
| 787 | Now: |
| 788 | |
| 789 | my $sheep = Sheep->named("Bad"); |
| 790 | print $sheep->{Color}, "\n"; |
| 791 | |
| 792 | outputs: |
| 793 | |
| 794 | white |
| 795 | |
| 796 | Now, there's nothing particularly specific to C<Sheep> when it comes |
| 797 | to color, so let's remove C<Sheep::named> and implement C<Animal::named> |
| 798 | to handle color instead: |
| 799 | |
| 800 | ## in Animal |
| 801 | sub named { |
| 802 | my ($class, $name) = @_; |
| 803 | my $self = { Name => $name, Color => $class->default_color }; |
| 804 | bless $self, $class; |
| 805 | } |
| 806 | |
| 807 | And then to keep from having to define C<default_color> for each additional |
| 808 | class, we'll define a method that serves as the "default default" directly |
| 809 | in C<Animal>: |
| 810 | |
| 811 | ## in Animal |
| 812 | sub default_color { "brown" } |
| 813 | |
| 814 | Of course, because C<name> and C<named> were the only methods that |
| 815 | referenced the "structure" of the object, the rest of the methods can |
| 816 | remain the same, so C<speak> still works as before. |
| 817 | |
| 818 | =head2 A horse of a different color |
| 819 | |
| 820 | But having all our horses be brown would be boring. So let's add a |
| 821 | method or two to get and set the color. |
| 822 | |
| 823 | ## in Animal |
| 824 | sub color { |
| 825 | $_[0]->{Color} |
| 826 | } |
| 827 | sub set_color { |
| 828 | $_[0]->{Color} = $_[1]; |
| 829 | } |
| 830 | |
| 831 | Note the alternate way of accessing the arguments: C<$_[0]> is used |
| 832 | in-place, rather than with a C<shift>. (This saves us a bit of time |
| 833 | for something that may be invoked frequently.) And now we can fix |
| 834 | that color for Mr. Ed: |
| 835 | |
| 836 | my $horse = Horse->named("Mr. Ed"); |
| 837 | $horse->set_color("black-and-white"); |
| 838 | print $horse->name, " is colored ", $horse->color, "\n"; |
| 839 | |
| 840 | which results in: |
| 841 | |
| 842 | Mr. Ed is colored black-and-white |
| 843 | |
| 844 | =head2 Summary |
| 845 | |
| 846 | So, now we have class methods, constructors, instance methods, instance |
| 847 | data, and even accessors. But that's still just the beginning of what |
| 848 | Perl has to offer. We haven't even begun to talk about accessors that |
| 849 | double as getters and setters, destructors, indirect object notation, |
| 850 | overloading, "isa" and "can" tests, the C<UNIVERSAL> class, and so on. |
| 851 | That's for the rest of the Perl documentation to cover. Hopefully, this |
| 852 | 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 |
| 858 | tutorial for those who already know objects), L<perltooc> (dealing |
| 859 | with class data), L<perlbot> (for some more tricks), and books such as |
| 860 | Damian Conway's excellent I<Object Oriented Perl>. |
| 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 |
| 865 | |
| 866 | =head1 COPYRIGHT |
| 867 | |
| 868 | Copyright (c) 1999, 2000 by Randal L. Schwartz and Stonehenge |
| 869 | Consulting Services, Inc. |
| 870 | |
| 871 | Copyright (c) 2009 by Michael F. Witten. |
| 872 | |
| 873 | Permission is hereby granted to distribute this document intact with |
| 874 | the Perl distribution, and in accordance with the licenses of the Perl |
| 875 | distribution; derived documents must include this copyright notice |
| 876 | intact. |
| 877 | |
| 878 | Portions of this text have been derived from Perl Training materials |
| 879 | originally appearing in the I<Packages, References, Objects, and |
| 880 | Modules> course taught by instructors for Stonehenge Consulting |
| 881 | Services, Inc. and used with permission. |
| 882 | |
| 883 | Portions of this text have been derived from materials originally |
| 884 | appearing in I<Linux Magazine> and used with permission. |