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