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