Convert some SvREFCNT_dec's to SvREFCNT_dec_NN's for efficiency
[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.
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 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.
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 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.
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> data structure (aka "a
114 referent") is an object. We sometimes say that an object has been
115 "blessed into a class".
116
117 Once a referent has been blessed, the C<blessed> function from the
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
123   print blessed($hash);      # undef
124   print blessed($hostname);  # File
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
133   my $file = File->new(...);
134
135 =head2 Methods
136
137 You already learned that a B<method> is a subroutine that operates on
138 an object. You can think of a method as the things that an object can
139 I<do>. If an object is a noun, then methods are its verbs (save, print,
140 open).
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
146   sub print_info {
147       my $self = shift;
148
149       print "This file is at ", $self->path, "\n";
150   }
151
152   $file->print_info;
153   # The file is at /etc/hostname
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
163   sub print_info {
164       my $self   = shift;
165       my $prefix = shift // "This file is at ";
166
167       print $prefix, ", ", $self->path, "\n";
168   }
169
170   $file->print_info("The file is located at ");
171   # The file is located at /etc/hostname
172
173 =head2 Attributes
174
175 Each class can define its B<attributes>. When we instantiate an object,
176 we assign values to those attributes. For example, every C<File> object
177 has a path. Attributes are sometimes called B<properties>.
178
179 Perl has no special syntax for attributes. Under the hood, attributes
180 are often stored as keys in the object's underlying hash, but don't
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
185 saw this earlier in the C<print_info()> example, which calls C<<
186 $self->path >>.
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
190 sets it. Another term for a setter is B<mutator>
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,
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.
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
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
208 method might produce different output for each class, but they share a
209 common interface.
210
211 While the two classes may differ in many ways, when it comes to the
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!>
215
216 Polymorphism is one of the key concepts of object-oriented design.
217
218 =head2 Inheritance
219
220 B<Inheritance> lets you create a specialized version of an existing
221 class. Inheritance lets the new class reuse the methods and attributes of
222 another class.
223
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.
227
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
232 C<File> is a B<superclass> of C<File::MP3>, and C<File::MP3> is a
233 B<subclass> of C<File>.
234
235   package File::MP3;
236
237   use parent 'File';
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
245 with multiple inheritance, but in a cleaner way.
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
249 C<File::MP3::FixedBitrate> and C<File::MP3::VariableBitrate> classes to
250 distinguish between different types of mp3 file.
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
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',
265   );
266
267   $cage->print_info;
268   # The file is at mp3s/My-Body-Is-a-Cage.mp3
269
270 If we wanted to include the mp3's title in the greeting, we could
271 override the method:
272
273   package File::MP3;
274
275   use parent 'File';
276
277   sub print_info {
278       my $self = shift;
279
280       print "This file is at ", $self->path, "\n";
281       print "Its title is ", $self->title, "\n";
282   }
283
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
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
290 first (C<File::MP3> in this case). If that class defines the method,
291 then that class's version of the method is called. If not, Perl looks
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>.
295
296 If C<File> inherited from C<DataSource>, which inherited from C<Thing>,
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
301   package File::MP3;
302
303   use parent 'File';
304
305   sub print_info {
306       my $self = shift;
307
308       $self->SUPER::print_info();
309       print "Its title is ", $self->title, "\n";
310   }
311
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.
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
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.
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
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
353 then be B<composed> of several other objects.
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
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
391 =item *
392
393 The system being designed is large, or is likely to become large.
394
395 =item *
396
397 The data can be aggregated into obvious structures, especially if
398 there's a large amount of data in each aggregate.
399
400 =item *
401
402 The various types of data aggregate form a natural hierarchy that
403 facilitates the use of inheritance and polymorphism.
404
405 =item *
406
407 You have a piece of data on which many different operations are
408 applied.
409
410 =item *
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
416 =item *
417
418 It's likely you'll have to add new data types later.
419
420 =item *
421
422 The typical interactions between pieces of data are best represented by
423 operators.
424
425 =item *
426
427 The implementation of individual components of the system is likely to
428 change over time.
429
430 =item *
431
432 The system design is already object-oriented.
433
434 =item *
435
436 Large numbers of other programmers will be using your code modules.
437
438 =back
439
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
465 Here is our C<File> class using C<Moose>:
466
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
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
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
496 new C<File>.
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
531 classes. This lets you ask questions like "what methods does the File
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
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.
593
594 Finally, it ships with a C<Mouse::Tiny> module that takes most of
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
615 Here's our C<File> class with C<Class::Accessor>:
616
617   package File;
618   use Class::Accessor 'antlers';
619
620   has path          => ( is => 'ro' );
621   has content       => ( is => 'ro' );
622   has last_mod_time => ( is => 'ro' );
623
624   sub print_info {
625       my $self = shift;
626
627       print "This file is at ", $self->path, "\n";
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
647 Here's our C<File> class once more:
648
649   package File;
650   use Object::Tiny qw( path content last_mod_time );
651
652   sub print_info {
653       my $self = shift;
654
655       print "This file is at ", $self->path, "\n";
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
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
728 write your classes by hand, there's really no reason to do that with
729 modern Perl.
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