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