This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
8c2cfcce8cf1d6dad041e5cbb5c8702456bf6e1e
[perl5.git] / pod / perlootut.pod
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 object
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.
66
67 The methods associated with a file might include C<rename()> and
68 C<write()>.
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
77 name for a category (like "File"), and a class also defines the
78 behavior of objects in that category.
79
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
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
88 used. Here's our "class declaration" for the C<File> class:
89
90   package File;
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
96   my $hostname = File->new(
97       path          => '/etc/hostname',
98       content       => "foo\n",
99       last_mod_time => 1304974868,
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
122   print blessed($hash);      # undef
123   print blessed($hostname);  # File
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
132   my $file = File->new(...);
133
134 =head2 Methods
135
136 You already learned that a B<method> is a subroutine that operates on
137 an object. You can think of a method as the things that an object can
138 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
144   sub print_info {
145       my $self = shift;
146
147       print "This file is at ", $self->path, "\n";
148   }
149
150   $larry->print_path;
151   # The file is at /etc/hostname
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
161   sub print_info {
162       my $self   = shift;
163       my $prefix = shift // "This file is at ";
164
165       print $prefix, ", ", $self->path, "\n";
166   }
167
168   $larry->print_info("The file is located at ");
169   # The file is located at /etc/hostname
170
171 =head2 Attributes
172
173 Each class can define its B<attributes>. When we instantiate an object,
174 we assign values to those attributes. For example, every C<File> object
175 has a path. Attributes are sometimes called B<properties>.
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
183 saw this earlier in the C<print_info()> example, which calls C<<
184 $self->path >>.
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,
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.
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
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 they share a
207 common interface.
208
209 While the two classes may differ in many ways, when it comes to the
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!>
213
214 Polymorphism is one of the key concepts of object-oriented design.
215
216 =head2 Inheritance
217
218 B<Inheritance> lets you create a specialized version of an existing
219 class. Inheritance lets the new class to reuse the methods and
220 attributes of another class.
221
222 For example, we could create an C<File::MP3> class which B<inherits>
223 from C<File>. An C<File::MP3> B<is-a> I<more specific> type of C<File>.
224 All mp3 files are files, but not all files are mp3 files.
225
226 We often refer to inheritance relationships as B<parent-child> or
227 C<superclass/subclass> relationships. Sometimes we say that the child
228 has an B<is-a> relationship with its parent class.
229
230 C<File> is a B<superclass> of C<File::MP3>, and C<File::MP3> is a
231 B<subclass> of C<File>.
232
233   package File::MP3;
234
235   use parent 'File';
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, but 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
247 C<File::MP3::FixedBitrate> and C<File::MP3::VariableBitrate> classes to
248 distinguish between different types of mp3 file.
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
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',
263   );
264
265   $cage->print_info;
266   # The file is at mp3s/My-Body-Is-a-Cage.mp3
267
268 If we wanted to include the mp3's title in the greeting, we could
269 override the method:
270
271   package File::MP3;
272
273   use parent 'File';
274
275   sub print_info {
276       my $self = shift;
277
278       print "This file is at ", $self->path, "\n";
279       print "Its title is ", $self->title, "\n";
280   }
281
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
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
288 first (C<File::MP3> in this case). If that class defines the method,
289 then that class's version of the method is called. If not, Perl looks
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>.
293
294 If C<File> inherited from C<DataSource>, which inherited from C<Thing>,
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
299   package File::MP3;
300
301   use parent 'File';
302
303   sub print_info {
304       my $self = shift;
305
306       $self->SUPER::print_info();
307       print "Its title is ", $self->title, "\n";
308   }
309
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.
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
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
352 then be B<composed> of several other objects.
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
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
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
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
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
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
498 new C<File>.
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
533 classes. This lets you ask questions like "what methods does the File
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, all of its
592 I<required> dependencies ship with the Perl core, and it can run
593 without a compiler. If you do have a compiler, C<Mouse> will use it to
594 compile some of its code for a speed boost.
595
596 Finally, it ships with a 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
617 Here's our C<File> class with C<Class::Accessor>:
618
619   package File;
620   use Class::Accessor 'antlers';
621
622   has path          => ( is => 'ro' );
623   has content       => ( is => 'ro' );
624   has last_mod_time => ( is => 'ro' );
625
626   sub print_info {
627       my $self = shift;
628
629       print "This file is at ", $self->path, "\n";
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
649 Here's our C<File> class once more:
650
651   package File;
652   use Object::Tiny qw( path content last_mod_time );
653
654   sub print_info {
655       my $self = shift;
656
657       print "This file is at ", $self->path, "\n";
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