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