| 1 | =encoding utf8 |
| 2 | |
| 3 | =for comment |
| 4 | Consistent formatting of this file is achieved with: |
| 5 | perl ./Porting/podtidy pod/perlootut.pod |
| 6 | |
| 7 | =head1 NAME |
| 8 | |
| 9 | perlootut - Object-Oriented Programming in Perl Tutorial |
| 10 | |
| 11 | =head1 DATE |
| 12 | |
| 13 | This document was created in February, 2011. |
| 14 | |
| 15 | =head1 DESCRIPTION |
| 16 | |
| 17 | This document provides an introduction to object-oriented programming |
| 18 | in Perl. It begins with a brief overview of the concepts behind object |
| 19 | oriented design. Then it introduces several different OO systems from |
| 20 | L<CPAN|http://search.cpan.org> which build on top of what Perl |
| 21 | provides. |
| 22 | |
| 23 | By default, Perl's built-in OO system is very minimal, leaving you to |
| 24 | do most of the work. This minimalism made a lot of sense in 1994, but |
| 25 | in the years since Perl 5.0 we've seen a number of common patterns |
| 26 | emerge in Perl OO. Fortunately, Perl's flexibility has allowed a rich |
| 27 | ecosystem of Perl OO systems to flourish. |
| 28 | |
| 29 | If you want to know how Perl OO works under the hood, the L<perlobj> |
| 30 | document explains the nitty gritty details. |
| 31 | |
| 32 | This document assumes that you already understand the basics of Perl |
| 33 | syntax, variable types, operators, and subroutine calls. If you don't |
| 34 | understand these concepts yet, please read L<perlintro> first. You |
| 35 | should also read the L<perlsyn>, L<perlop>, and L<perlsub> documents. |
| 36 | |
| 37 | =head1 OBJECT-ORIENTED FUNDAMENTALS |
| 38 | |
| 39 | Most object systems share a number of common concepts. You've probably |
| 40 | heard terms like "class", "object, "method", and "attribute" before. |
| 41 | Understanding the concepts will make it much easier to read and write |
| 42 | object-oriented code. If you're already familiar with these terms, you |
| 43 | should still skim this section, since it explains each concept in terms |
| 44 | of Perl's OO implementation. |
| 45 | |
| 46 | Perl's OO system is class-based. Class-based OO is fairly common. It's |
| 47 | used by Java, C++, C#, Python, Ruby, and many other languages. There |
| 48 | are other object orientation paradigms as well. JavaScript is the most |
| 49 | popular language to use another paradigm. JavaScript's OO system is |
| 50 | prototype-based. |
| 51 | |
| 52 | =head2 Object |
| 53 | |
| 54 | An B<object> is a data structure that bundles together data and |
| 55 | subroutines which operate on that data. An object's data is called |
| 56 | B<attributes>, and its subroutines are called B<methods>. An object can |
| 57 | be thought of as a noun (a person, a web service, a computer). |
| 58 | |
| 59 | An object represents a single discrete thing. For example, an |
| 60 | object might represent a person. The attributes for a person object |
| 61 | might include name, birth date, and country of residence. If we created |
| 62 | an object to represent Larry Wall, Perl's creator, that object's name |
| 63 | would be "Larry Wall", born on "September 27, 1954", and living in |
| 64 | "USA". |
| 65 | |
| 66 | The methods associated with a person might include C<print_greeting()> |
| 67 | and C<calculate_age()>. |
| 68 | |
| 69 | In Perl most objects are hash references, but the OO systems we |
| 70 | recommend keep you from having to worry about this. In practice, it's |
| 71 | best to consider an object's internal data structure opaque. |
| 72 | |
| 73 | =head2 Class |
| 74 | |
| 75 | A B<class> defines the behavior of a category of objects. A class is a |
| 76 | name for a category (like "Person"), and a class also defines the |
| 77 | behavior of objects in that category. |
| 78 | |
| 79 | All objects belong to a specific class. For example, our Larry Wall |
| 80 | object belongs to the C<Person> class. When we want to create a |
| 81 | specific object, we start with its class, and B<construct> or |
| 82 | B<instantiate> an object. A specific object is often referred to as an |
| 83 | B<instance> of a class. |
| 84 | |
| 85 | In Perl, any package can be a class. The difference between a package |
| 86 | which is a class and one which isn't is based on how the package is |
| 87 | used. Here's our "class declaration" for the Person class: |
| 88 | |
| 89 | package Person; |
| 90 | |
| 91 | In Perl, there is no special keyword for constructing an object. |
| 92 | However, most OO modules on CPAN use a method named C<new()> to |
| 93 | construct a new object: |
| 94 | |
| 95 | my $larry = Person->new( |
| 96 | name => 'Larry Wall', |
| 97 | birth_date => '1954-09-27', |
| 98 | country_code => 'us', |
| 99 | ); |
| 100 | |
| 101 | (Don't worry about that C<< -> >> operator, it will be explained |
| 102 | later.) |
| 103 | |
| 104 | =head3 Blessing |
| 105 | |
| 106 | As we said earlier, most Perl objects are hash references, but an |
| 107 | object can be a reference to any Perl data type (scalar, array, etc.). |
| 108 | Turning a plain reference into an object is done by B<blessing> that |
| 109 | reference using Perl's C<bless> function. |
| 110 | |
| 111 | While we strongly suggest you don't build your objects from scratch, |
| 112 | you should know the term B<bless>. A B<blessed> reference is an object. |
| 113 | We sometimes say that an object has been "blessed into a class". |
| 114 | |
| 115 | Once a reference has been blessed, the C<blessed> function from the |
| 116 | L<Scalar::Util> core module can tell us its class name. This subroutine |
| 117 | returns an object's class when passed an object, and false otherwise. |
| 118 | |
| 119 | use Scalar::Util 'blessed'; |
| 120 | |
| 121 | print blessed($hash); # undef |
| 122 | print blessed($larry); # Person |
| 123 | |
| 124 | =head3 Constructor |
| 125 | |
| 126 | A B<constructor> creates a new object. In Perl, a class's constructor |
| 127 | is just another method, unlike some other languages, which provide |
| 128 | syntax for constructors. Most Perl classes use C<new> as the name for |
| 129 | their constructor: |
| 130 | |
| 131 | my $file = File->new(); |
| 132 | |
| 133 | =head2 Methods |
| 134 | |
| 135 | You already learned that a B<method> is a subroutine that operates on |
| 136 | an object's data. You can think of a method as the things that an |
| 137 | object can I<do>. |
| 138 | |
| 139 | In Perl, methods are simply subroutines that live in a class's package. |
| 140 | Methods are always written to receive the object as their first |
| 141 | argument: |
| 142 | |
| 143 | sub print_greeting { |
| 144 | my $self = shift; |
| 145 | |
| 146 | print "Hello, ", $self->name, "\n"; |
| 147 | } |
| 148 | |
| 149 | $larry->print_greeting; # Hello, Larry Wall |
| 150 | |
| 151 | What makes a method special is I<how it's called>. The arrow operator |
| 152 | (C<< -> >>) tells Perl that we are calling a method. |
| 153 | |
| 154 | When we make a method call, Perl arranges for the method's B<invocant> |
| 155 | to be passed as the first argument. B<Invocant> is a fancy name for the |
| 156 | thing on the left side of the arrow. The invocant can either be a class |
| 157 | name or an object. We can also pass additional arguments to the method: |
| 158 | |
| 159 | sub print_greeting { |
| 160 | my $self = shift; |
| 161 | my $greeting = shift // "Hello"; |
| 162 | |
| 163 | print $greeting, ", ", $self->name, "\n"; |
| 164 | } |
| 165 | |
| 166 | $larry->print_greeting("Yo, Wassup"); # Yo, Wassup, Larry Wall |
| 167 | |
| 168 | =head2 Attributes |
| 169 | |
| 170 | Each class can define its B<attributes>. When we instantiate an object, |
| 171 | we assign values to those attributes. For example, every C<Person> |
| 172 | object has a name. Attributes are sometimes called B<properties>. |
| 173 | |
| 174 | Perl has no special syntax for attributes. Under the hood, attributes |
| 175 | are often stored as keys in the object's hash reference, but don't |
| 176 | worry about this. |
| 177 | |
| 178 | We recommend that you only access attributes via B<accessor> methods. |
| 179 | These are methods that can get or set the value of each attribute. We |
| 180 | saw this earlier in the C<print_greeting()> example, which calls C<< |
| 181 | $self->name >>. |
| 182 | |
| 183 | You might also see the terms B<getter> and B<setter>. These are two |
| 184 | types of accessors. A getter gets the attribute's value, while a setter |
| 185 | sets it. |
| 186 | |
| 187 | Attributes are typically defined as read-only or read-write. Read-only |
| 188 | attributes can only be set when the object is first created, while |
| 189 | read-write attributes can be altered at any time. |
| 190 | |
| 191 | The value of an attribute may itself be another object. For example, |
| 192 | instead of returning its birth date as a string, the C<Person> class |
| 193 | could return a L<DateTime> object representing that date. |
| 194 | |
| 195 | It's possible to have a class that does not expose any publicly |
| 196 | settable attributes. Not every class has attributes and methods. |
| 197 | |
| 198 | =head2 Polymorphism |
| 199 | |
| 200 | B<Polymorphism> is a fancy way of saying that objects from two |
| 201 | different classes share an API. For example, we could have C<Person> |
| 202 | and C<Animal> classes which both have a C<speak()> method. This method |
| 203 | might produce different output for each class, but the basic API is the |
| 204 | same. |
| 205 | |
| 206 | While the two classes may differ in many ways, when it comes to the |
| 207 | C<speak()> method, they are the same. This means that we can try to |
| 208 | call the C<speak()> method on an object of either class, and B<we don't |
| 209 | have to know what class the object belongs to!> |
| 210 | |
| 211 | Polymorphism is one of the key concepts of object-oriented design. |
| 212 | |
| 213 | =head2 Inheritance |
| 214 | |
| 215 | B<Inheritance> is a way to specialize an existing class. It allows one |
| 216 | class to reuse the methods and attributes of another class. |
| 217 | |
| 218 | We often refer to inheritance relationships as B<parent-child> or |
| 219 | C<superclass/subclass> relationships. Sometimes this is called an |
| 220 | B<is-a> relationship. |
| 221 | |
| 222 | Inheritance is best used to create a specialized version of a class. |
| 223 | For example, we could create an C<Employee> class which B<inherits> |
| 224 | from C<Person>. An C<Employee> B<is-a> I<more specific> type of |
| 225 | C<Person>. All employees are persons, but not all persons are |
| 226 | employees. |
| 227 | |
| 228 | C<Person> is a B<superclass> of C<Employee>, and C<Employee> is a |
| 229 | B<subclass> of C<Person>. |
| 230 | |
| 231 | package Employee; |
| 232 | |
| 233 | use parent 'Person'; |
| 234 | |
| 235 | The L<parent> module is one of several ways that Perl lets you define |
| 236 | inheritance relationships. |
| 237 | |
| 238 | Perl allows multiple inheritance, which means that a class can inherit |
| 239 | from multiple parents. While this is possible, we strongly recommend |
| 240 | against it. Generally, you can use B<roles> to do everything you can do |
| 241 | with multiple inheritance in a cleaner way. |
| 242 | |
| 243 | Note that there's nothing wrong with defining multiple subclasses of a |
| 244 | given class. This is both common and safe. For example, we might define |
| 245 | C<Employee::Permanent> and C<Employee::Temporary> classes to |
| 246 | distinguish between different types of employees. |
| 247 | |
| 248 | =head3 Overriding methods and method resolution |
| 249 | |
| 250 | Inheritance allows two classes to share code. By default, every method |
| 251 | in the parent class is also available in the child. The child can |
| 252 | explicitly B<override> a parent's method to provide its own |
| 253 | implementation. For example, if we have an C<Employee> object, it has |
| 254 | the C<print_greeting()> method from person: |
| 255 | |
| 256 | my $larry = Employee->new( |
| 257 | name => 'Larry Wall', |
| 258 | birth_date => '1954-09-27', |
| 259 | country_code => 'us', |
| 260 | job_title => 'Hacker Extraordinaire', |
| 261 | ); |
| 262 | |
| 263 | $larry->print_greeting; # Hello, Larry Wall |
| 264 | |
| 265 | If we wanted to include the employee's job title in the greeting, we |
| 266 | could override the method: |
| 267 | |
| 268 | package Employee; |
| 269 | |
| 270 | use parent 'Person'; |
| 271 | |
| 272 | sub print_greeting { |
| 273 | my $self = shift; |
| 274 | |
| 275 | print "Hello, ", $self->name, " - ", $self->job_title, "\n"; |
| 276 | } |
| 277 | |
| 278 | $larry->print_greeting; # Hello, Larry Wall - Hacker Extraordinaire |
| 279 | |
| 280 | The process of determining what method should be used is called |
| 281 | B<method resolution>. What Perl does is look at the object's class |
| 282 | first (C<Employee> in this case). If that class defines the method, |
| 283 | then that class's version of the method is called. If not, Perl looks |
| 284 | at each parent class in turn. For C<Employee>, its only parent is |
| 285 | C<Person>. If C<Employee> does not define the method, but C<Person> |
| 286 | does, then Perl calls the method in C<Person>. |
| 287 | |
| 288 | If C<Person> inherited from C<Animal>, which inherited from C<Thing>, |
| 289 | then Perl would keep looking "up the chain" if necessary. |
| 290 | |
| 291 | It is possible to explicitly call a parent method from a child: |
| 292 | |
| 293 | package Employee; |
| 294 | |
| 295 | use parent 'Person'; |
| 296 | |
| 297 | sub print_greeting { |
| 298 | my $self = shift; |
| 299 | |
| 300 | $self->SUPER::print_greeting(); |
| 301 | |
| 302 | print "Your job is ", $self->job_title, "\n"; |
| 303 | } |
| 304 | |
| 305 | The C<SUPER::> bit tells Perl to look for the C<print_greeting()> in |
| 306 | the C<Employee> class's inheritance chain. When it finds the parent |
| 307 | class that implements this method, the method is called. |
| 308 | |
| 309 | We mentioned multiple inheritance earlier. The main problem with |
| 310 | multiple inheritance is that it greatly complicates method resolution. |
| 311 | See L<perlobj> for more details. |
| 312 | |
| 313 | =head2 Encapsulation |
| 314 | |
| 315 | B<Encapsulation> is the idea that an object is opaque. When another |
| 316 | developer uses your class, they don't need to know I<how> it is |
| 317 | implemented, they just need to know I<what> it does. |
| 318 | |
| 319 | Encapsulation is important for several reasons. First, it allows you to |
| 320 | separate the public API from the private implementation. This means you |
| 321 | can change that implementation without breaking the API. |
| 322 | |
| 323 | Second, when classes are well encapsulated, they become easier to |
| 324 | subclass. Ideally, a subclass uses the same APIs to access object data |
| 325 | that its parent class uses. In reality, subclassing sometimes involves |
| 326 | violating encapsulation, but a good API can minimize the need to do |
| 327 | this. |
| 328 | |
| 329 | We mentioned earlier that most Perl objects are implemented as hash |
| 330 | references under the hood. The principle of encapsulation tells us that |
| 331 | we should not rely on this. Instead, we should use accessor methods to |
| 332 | access the data in that hash reference. The object systems that we |
| 333 | recommend below all automate the generation of accessor methods. If you |
| 334 | use one of them, you should never have to access the object as a hash |
| 335 | reference directly. |
| 336 | |
| 337 | =head2 Composition |
| 338 | |
| 339 | In object-oriented code, we often find that one object references |
| 340 | another object. This is called B<composition>, or a B<has-a> |
| 341 | relationship. |
| 342 | |
| 343 | Earlier, we mentioned that the C<Person> class's C<birth_date> accessor |
| 344 | could return a L<DateTime> object. This is a perfect example of |
| 345 | composition. We could go even further, and make objects for name and |
| 346 | country as well. The C<Person> class would then be B<composed> of |
| 347 | several other objects. |
| 348 | |
| 349 | =head2 Roles |
| 350 | |
| 351 | B<Roles> are something that a class I<does>, rather than something that |
| 352 | it I<is>. Roles are relatively new to Perl, but have become rather |
| 353 | popular. Roles are B<applied> to classes. Sometimes we say that classes |
| 354 | B<consume> roles. |
| 355 | |
| 356 | Roles are an alternative to inheritance for providing polymorphism. |
| 357 | Let's assume we have two classes, C<Radio> and C<Computer>. Both of |
| 358 | these things have on/off switches. We want to model that in our class |
| 359 | definitions. |
| 360 | |
| 361 | We could have both classes inherit from a common parent, like |
| 362 | C<Machine>, but not all machines have on/off switches. We could create |
| 363 | a parent class called C<HasOnOffSwitch>, but that is very artificial. |
| 364 | Radios and computers are not specializations of this parent. This |
| 365 | parent is really a rather ridiculous creation. |
| 366 | |
| 367 | This is where roles come in. It makes a lot of sense to create a |
| 368 | C<HasOnOffSwitch> role and apply it to both classes. This role would |
| 369 | define a known API like providing C<turn_on()> and C<turn_off()> |
| 370 | methods. |
| 371 | |
| 372 | Perl does not have any built-in way to express roles. In the past, |
| 373 | people just bit the bullet and used multiple inheritance. Nowadays, |
| 374 | there are several good choices on CPAN for using roles. |
| 375 | |
| 376 | =head1 PERL OO SYSTEMS |
| 377 | |
| 378 | As we mentioned before, Perl's built-in OO system is very minimal, but |
| 379 | also quite flexible. Over the years, many people have developed systems |
| 380 | which build on top of Perl's built-in system to provide more features |
| 381 | and convenience. |
| 382 | |
| 383 | We strongly recommend that you use one of these systems. Even the most |
| 384 | minimal of them eliminates a lot of repetitive boilerplate. There's |
| 385 | really no good reason to write your classes from scratch in Perl. |
| 386 | |
| 387 | If you are interested in the guts underlying these systems, check out |
| 388 | L<perlobj>. |
| 389 | |
| 390 | =head2 Moose |
| 391 | |
| 392 | L<Moose> bills itself as a "postmodern object system for Perl 5". Don't |
| 393 | be scared, the "postmodern" label is a callback to Larry's description |
| 394 | of Perl as "the first postmodern computer language". |
| 395 | |
| 396 | C<Moose> provides a complete, modern OO system. Its biggest influence |
| 397 | is the Common Lisp Object System, but it also borrows ideas from |
| 398 | Smalltalk and several other languages. C<Moose> was created by Stevan |
| 399 | Little, and draws heavily from his work on the Perl 6 OO design. |
| 400 | |
| 401 | C<Moose> provides a number of features: |
| 402 | |
| 403 | =over 4 |
| 404 | |
| 405 | =item * Declarative sugar |
| 406 | |
| 407 | C<Moose> provides a layer of declarative "sugar" for defining classes. |
| 408 | That sugar is just a set of exported functions that make declaring how |
| 409 | your class works simpler and more palatable. This lets you describe |
| 410 | I<what> your class is, rather than having to tell Perl I<how> to |
| 411 | implement your class. |
| 412 | |
| 413 | Here's a simple but complete C<Moose> class: |
| 414 | |
| 415 | package Person; |
| 416 | use Moose; |
| 417 | |
| 418 | has name => ( is => 'ro' ); |
| 419 | has birth_date => ( is => 'ro' ); |
| 420 | has country_code => ( is => 'ro' ); |
| 421 | |
| 422 | sub print_greeting { |
| 423 | my $self = shift; |
| 424 | |
| 425 | print "Hello, ", $self->name, "\n"; |
| 426 | } |
| 427 | |
| 428 | The C<has()> subroutine declares an attribute, and C<Moose> |
| 429 | automatically creates accessors for these attributes. It also takes |
| 430 | care of creating a C<new()> method for you. This constructor knows |
| 431 | about the attributes you declared, so you can set them when creating a |
| 432 | new C<Person>. |
| 433 | |
| 434 | =item * Roles built-in |
| 435 | |
| 436 | C<Moose> lets you define roles the same way you define classes: |
| 437 | |
| 438 | package HasOnOfSwitch; |
| 439 | use Moose::Role; |
| 440 | |
| 441 | has is_on => ( |
| 442 | is => 'rw', |
| 443 | isa => 'Bool', |
| 444 | ); |
| 445 | |
| 446 | sub turn_on { |
| 447 | my $self = shift; |
| 448 | $self->is_on(1); |
| 449 | } |
| 450 | |
| 451 | sub turn_off { |
| 452 | my $self = shift; |
| 453 | $self->is_on(0); |
| 454 | } |
| 455 | |
| 456 | =item * A miniature type system |
| 457 | |
| 458 | In the example above, you can see that we passed C<< isa => 'Bool' >> |
| 459 | to C<has()> when creating our C<is_on> attribute. This tells C<Moose> |
| 460 | that this attribute must be a boolean value. If we try to set it to an |
| 461 | invalid value, our code will throw an error. |
| 462 | |
| 463 | =item * Full introspection and manipulation |
| 464 | |
| 465 | Perl's built-in introspection features are fairly minimal. C<Moose> |
| 466 | builds on top of them and creates a full introspection layer for your |
| 467 | classes. This lets you ask questions like "what methods does the Person |
| 468 | class implement?" It also lets you modify your classes |
| 469 | programmatically. |
| 470 | |
| 471 | =item * Self-hosted and extensible |
| 472 | |
| 473 | C<Moose> describes itself using its own introspection API. Besides |
| 474 | being a cool trick, this means that you can extend C<Moose> using |
| 475 | C<Moose> itself. |
| 476 | |
| 477 | =item * Rich ecosystem |
| 478 | |
| 479 | There is a rich ecosystem of C<Moose> extensions on CPAN under the |
| 480 | L<MooseX|http://search.cpan.org/search?query=MooseX&mode=dist> |
| 481 | namespace. In addition, many modules on CPAN already use C<Moose>, |
| 482 | providing you with lots of examples to learn from. |
| 483 | |
| 484 | =item * Many more features |
| 485 | |
| 486 | C<Moose> is a very powerful tool, and we can't cover all of its |
| 487 | features here. We encourage you to learn more by reading the C<Moose> |
| 488 | documentation, starting with |
| 489 | L<Moose::Manual|http://search.cpan.org/perldoc?Moose::Manual>. |
| 490 | |
| 491 | =back |
| 492 | |
| 493 | Of course, C<Moose> isn't perfect. |
| 494 | |
| 495 | C<Moose> can make your code slower to load. C<Moose> itself is not |
| 496 | small, and it does a I<lot> of code generation when you define your |
| 497 | class. This code generation means that your runtime code is as fast as |
| 498 | it can be, but you pay for this when your modules are first loaded. |
| 499 | |
| 500 | This load time hit can be a problem when startup speed is important, |
| 501 | such as with a command-line script or a "plain vanilla" CGI script that |
| 502 | must be loaded each time it is executed. |
| 503 | |
| 504 | Before you panic, know that many people do use C<Moose> for |
| 505 | command-line tools and other startup-sensitive code. We encourage you |
| 506 | to try C<Moose> out first before worrying about startup speed. |
| 507 | |
| 508 | C<Moose> also has several dependencies on other modules. Most of these |
| 509 | are small stand-alone modules, a number of which have been spun off |
| 510 | from C<Moose>. C<Moose> itself, and some of its dependencies, require a |
| 511 | compiler. If you need to install your software on a system without a |
| 512 | compiler, or if having I<any> dependencies is a problem, then C<Moose> |
| 513 | may not be right for you. |
| 514 | |
| 515 | =head3 Mouse |
| 516 | |
| 517 | If you try C<Moose> and find that one of these issues is preventing you |
| 518 | from using C<Moose>, we encourage you to consider L<Mouse> next. |
| 519 | C<Mouse> implements a subset of C<Moose>'s functionality in a simpler |
| 520 | package. For all features that it does implement, the end-user API is |
| 521 | I<identical> to C<Moose>, meaning you can switch from C<Mouse> to |
| 522 | C<Moose> quite easily. |
| 523 | |
| 524 | C<Mouse> does not implement most of C<Moose>'s introspection API, so |
| 525 | it's often faster when loading your modules. Additionally, it has no |
| 526 | I<required> non-core dependencies and can run without a compiler. If |
| 527 | you do have a compiler, C<Mouse> will use it to compile some of its |
| 528 | code for a speed boost. |
| 529 | |
| 530 | Finally, it ships with a C<C<Mouse>::Tiny> module that takes most of |
| 531 | C<Mouse>'s features and bundles them up in a single module file. You |
| 532 | can copy this module file into your application's library directory for |
| 533 | easy bundling. |
| 534 | |
| 535 | The C<Moose> authors hope that one day C<Mouse> can be made obsolete by |
| 536 | improving C<Moose> enough, but for now it provides a worthwhile |
| 537 | alternative to C<Moose>. |
| 538 | |
| 539 | =head2 Class::Accessor |
| 540 | |
| 541 | L<Class::Accessor> is the polar opposite of C<Moose>. It provides very |
| 542 | few features, nor is it self-hosting. |
| 543 | |
| 544 | It is, however, very simple, pure Perl, and it has no non-core |
| 545 | dependencies. It also provides a "Moose-like" API on demand for the |
| 546 | features it supports. |
| 547 | |
| 548 | Even though it doesn't do much, it is still preferable to writing your |
| 549 | own classes from scratch. |
| 550 | |
| 551 | Here's our C<Person> class with C<Class::Accessor>: |
| 552 | |
| 553 | package Person; |
| 554 | use Class::Accessor 'antlers'; |
| 555 | |
| 556 | has name => ( is => 'ro' ); |
| 557 | has birth_date => ( is => 'ro' ); |
| 558 | has country_code => ( is => 'ro' ); |
| 559 | |
| 560 | sub print_greeting { |
| 561 | my $self = shift; |
| 562 | |
| 563 | print "Hello, ", $self->name, "\n"; |
| 564 | } |
| 565 | |
| 566 | The C<antlers> import flag tells C<Class::Accessor> that you want to |
| 567 | define your attributes using C<Moose>-like syntax. The only parameter |
| 568 | that you can pass to C<has> is C<is>. We recommend that you use this |
| 569 | Moose-like syntax if you choose C<Class::Accessor> since it means you |
| 570 | will have a smoother upgrade path if you later decide to move to |
| 571 | C<Moose>. |
| 572 | |
| 573 | Like C<Moose>, C<Class::Accessor> generates accessor methods and a |
| 574 | constructor for your class. |
| 575 | |
| 576 | =head2 Object::Tiny |
| 577 | |
| 578 | Finally, we have L<Object::Tiny>. This module truly lives up to its |
| 579 | name. It has an incredibly minimal API and absolutely no dependencies |
| 580 | (core or not). Still, we think it's a lot easier to use than writing |
| 581 | your own OO code from scratch. |
| 582 | |
| 583 | Here's our C<Person> class once more: |
| 584 | |
| 585 | package Person; |
| 586 | use Object::Tiny qw( name birth_date country_code ); |
| 587 | |
| 588 | sub print_greeting { |
| 589 | my $self = shift; |
| 590 | |
| 591 | print "Hello, ", $self->name, "\n"; |
| 592 | } |
| 593 | |
| 594 | That's it! |
| 595 | |
| 596 | With C<Object::Tiny>, all accessors are read-only. It generates a |
| 597 | constructor for you, as well as the accessors you define. |
| 598 | |
| 599 | =head2 Role::Tiny |
| 600 | |
| 601 | As we mentioned before, roles provide an alternative to inheritance, |
| 602 | but Perl does not have any built-in role support. If you choose to use |
| 603 | Moose, it comes with a full-fledged role implementation. However, if |
| 604 | you use one of our other recommended OO modules, you can still use |
| 605 | roles with L<Role::Tiny> |
| 606 | |
| 607 | C<Role::Tiny> provides some of the same features as Moose's role |
| 608 | system, but in a much smaller package. Most notably, it doesn't support |
| 609 | any sort of attribute declaration, so you have to do that by hand. |
| 610 | Still, it's useful, and works well with C<Class::Accessor> and |
| 611 | C<Object::Tiny> |
| 612 | |
| 613 | =head2 OO System Summary |
| 614 | |
| 615 | Here's a brief recap of the options we covered: |
| 616 | |
| 617 | =over 4 |
| 618 | |
| 619 | =item * L<Moose> |
| 620 | |
| 621 | C<Moose> is the maximal option. It has a lot of features, a big |
| 622 | ecosystem, and a thriving user base. We also covered L<Mouse> briefly. |
| 623 | C<Mouse> is C<Moose> lite, and a reasonable alternative when Moose |
| 624 | doesn't work for your application. |
| 625 | |
| 626 | =item * L<Class::Accessor> |
| 627 | |
| 628 | C<Class::Accessor> does a lot less than C<Moose>, and is a nice |
| 629 | alternative if you find C<Moose> overwhelming. It's been around a long |
| 630 | time and is well battle-tested. It also has a minimal C<Moose> |
| 631 | compatibility mode which makes moving from C<Class::Accessor> to |
| 632 | C<Moose> easy. |
| 633 | |
| 634 | =item * L<Object::Tiny> |
| 635 | |
| 636 | C<Object::Tiny> is the absolute minimal option. It has no dependencies, |
| 637 | and almost no syntax to learn. It's a good option for a super minimal |
| 638 | environment and for throwing something together quickly without having |
| 639 | to worry about details. |
| 640 | |
| 641 | =item * L<Role::Tiny> |
| 642 | |
| 643 | Use C<Role::Tiny> with C<Class::Accessor> or C<Object::Tiny> if you |
| 644 | find yourself considering multiple inheritance. If you go with |
| 645 | C<Moose>, it comes with its own role implementation. |
| 646 | |
| 647 | =back |
| 648 | |
| 649 | =head2 Other OO Systems |
| 650 | |
| 651 | There are literally dozens of other OO-related modules on CPAN besides |
| 652 | those covered here, and you're likely to run across one or more of them |
| 653 | if you work with other people's code. |
| 654 | |
| 655 | In addition, plenty of code in the wild does all of its OO "by hand", |
| 656 | using just the Perl built-in OO features. If you need to maintain such |
| 657 | code, you should read L<perlobj> to understand exactly how Perl's |
| 658 | built-in OO works. |
| 659 | |
| 660 | =head1 CONCLUSION |
| 661 | |
| 662 | As we said before, Perl's minimal OO system has lead to a flourishing |
| 663 | of OO systems on CPAN. While you can still drop down to the bare metal |
| 664 | and write your classes by hand, there's really no reason to do that in |
| 665 | 2011. |
| 666 | |
| 667 | For small systems, L<Object::Tiny> and L<Class::Accessor> both provide |
| 668 | minimal object systems that take care of basic boilerplate for you. |
| 669 | |
| 670 | For bigger projects, L<Moose> provides a rich set of features that will |
| 671 | let you focus on implementing your business logic. |
| 672 | |
| 673 | We encourage you to play with and evaluate L<Moose>, |
| 674 | L<Class::Accessor>, and L<Object::Tiny> to see which OO system is right |
| 675 | for you. |
| 676 | |
| 677 | =cut |