5 Moose::Manual::Concepts - Moose OO concepts
7 =head1 MOOSE CONCEPTS (VS "OLD SCHOOL" Perl)
9 In the past, you may not have thought too much about the difference
10 between packages and classes, attributes and methods, constructors and
11 methods, etc. With Moose, these are all conceptually separate things,
12 even though under the hood they're implemented with plain old Perl.
14 Our meta-object protocol (aka MOP) provides well-defined introspection
15 features for each of those concepts, and Moose in turn provides
16 distinct sugar for each of them. Moose also introduces additional
17 concepts such as roles, method modifiers, and declarative delegation.
19 Knowing what these concepts mean in Moose-speak, and how they used to
20 be done in old school Perl 5 OO is a good way to start learning to use
25 When you say "use Moose" in a package, you are making your package a
26 class. At its simplest, a class will consist simply of attributes
27 and/or methods. It can also include roles, method modifiers, and more.
29 A class I<has> zero or more B<attributes>.
31 A class I<has> zero or more B<methods>.
33 A class I<has> zero or more superclasses (aka parent classes). A
34 class inherits from its superclass(es).
36 A class I<has> zero or more B<method modifiers>. These modifiers can
37 apply to its own methods or methods that are inherited from its
40 A class I<does> (and I<consumes>) zero or more B<roles>.
42 A class I<has> a B<constructor> and a B<destructor>. These are
43 provided for you "for free" by Moose.
45 The B<constructor> accepts named parameters corresponding to the
46 class's attributes and uses them to initialize an B<object instance>.
48 A class I<has> a B<metaclass>, which in turn has B<meta-attributes>,
49 B<meta-methods>, and B<meta-roles>. This metaclass I<describes> the
52 A class is usually analogous to a category of nouns, like "People" or
58 # now it's a Moose class!
62 An attribute is a property of the class that defines it. It I<always>
63 has a name, and it I<may have> a number of other properties.
65 These properties can include a read/write flag, a B<type>, accessor
66 method names, B<delegations>, a default value, and more.
68 Attributes I<are not> methods, but defining them causes various
69 accessor methods to be created. At a minimum, a normal attribute will
70 always have a reader accessor method. Many attributes also other
71 methods such as a writer method, clearer method, and predicate method
74 An attribute may also define B<delegations>, which will create
75 additional methods based on the delegation mapping.
77 By default, Moose stores attributes in the object instance, which is a
78 hashref, I<but this is invisible to the author of a Moose-based
79 class>! It is best to think of Moose attributes as "properties" of
80 the I<opaque> B<object instance>. These properties are accessed
81 through well-defined accessor methods.
83 An attribute is something that the class's members have. For example,
84 People have first and last names. Users have passwords and last login
94 A B<method> is very straightforward. Any subroutine you define in your
97 B<Methods> correspond to verbs, and are what your objects can do. For
98 example, a User can login.
104 A role is something that a class I<does>. We also say that classes
105 I<consume> roles. For example, a Machine class might do the Breakable
106 role, and so could a Bone class. A role is used to define some concept
107 that cuts across multiple unrelated classes, like "breakability", or
110 A role I<has> zero or more B<attributes>.
112 A role I<has> zero or more B<methods>.
114 A role I<has> zero or more B<method modifiers>.
116 A role I<has> zero or more B<required methods>.
118 A required method is not implemented by the role. Required methods say
119 "to use this Role you must implement this method".
121 A role I<has> zero or more B<excluded roles>.
123 An excluded role is a role that the role doing the excluding says it
124 cannot be combined with.
126 Roles are I<composed> into classes (or other roles). When a role is
127 composed into a class, its attributes and methods are "flattened" into
128 the class. Roles I<do not> show up in the inheritance hierarchy. When
129 a role is composed, its attributes and methods appear as if they were
130 defined I<in the consuming class>.
132 Role are somewhat like mixins or interfaces in other OO languages.
151 =head2 Method modifiers
153 A B<method modifier> is a hook that is called when a named method is
154 called. For example, you could say "before calling C<login()>, call
155 this modifier first". Modifiers come in different flavors like
156 "before", "after", "around", and "augment", and you can apply more
157 than one modifier to a single method.
159 Method modifiers are often used as an alternative to overriding a
160 method in a parent class. They are also used in roles as a way of
161 modifying methods in the consuming class.
163 Under the hood, a method modifier is just a plain old Perl subroutine
164 that gets called before or after (or around, etc.) some named method.
166 before 'login' => sub {
170 warn "Called login() with $pw\n";
175 Moose also comes with a (miniature) type system. This allows you to
176 define types for attributes. Moose has a set of built-in types based
177 on what Perl provides, such as C<Str>, C<Num>, C<Bool>, C<HashRef>, etc.
179 In addition, every class name in your application can also be used as
180 a type name. We saw an example using C<DateTime> earlier.
182 Finally, you can define your own types, either as subtypes or entirely
183 new types, with their own constraints. For example, you could define a
184 type C<PosInt>, a subtype of C<Int> which only allows positive numbers.
188 Moose attributes provide declarative syntax for defining
189 delegations. A delegation is a method which calls some method on an
190 attribute to do its real work.
194 A constructor creates an B<object instance> for the class. In old
195 school Perl, this was usually done by defining a method called
196 C<new()> which in turn called C<bless> on a reference.
198 With Moose, this C<new()> method is created for you, and it simply
199 does the right thing. You should never need to define your own
202 Sometimes you want to do something whenever an object is created. In
203 those cases, you can provide a C<BUILD()> method in your class. Moose
204 will call this for you after creating a new object.
208 This is a special method called when an object instance goes out of
209 scope. You can specialize what your class does in this method if you
210 need to, but you usually don't.
212 With old school Perl 5, this is the C<DESTROY()> method, but with
213 Moose it is the C<DEMOLISH()> method.
215 =head2 Object instance
217 An object instance is a specific noun in the class's "category". For
218 example, one specific Person or User. An instance is created by the
219 class's B<constructor>.
221 An instance has values for its attributes. For example, a specific
222 person has a first and last name.
224 In old school Perl 5, this is often a blessed hash reference. With
225 Moose, you should never need to know what your object instance
226 actually is. (Okay, it's usually a blessed hashref with Moose, too.)
228 =head2 Moose vs old school summary
234 A package with no introspection other than mucking about in the symbol
237 With Moose, you get well-defined declaration and introspection.
241 Hand-written accessor methods, symbol table hackery, or a helper
242 module like C<Class::Accessor>.
244 With Moose, these are declaratively defined, and distinct from
249 These are pretty much the same in Moose as in old school Perl.
253 C<Class::Trait> or C<Class::Role>, or maybe C<mixin.pm>.
255 With Moose, they're part of the core feature set, and are
256 introspectable like everything else.
258 =item * Method Modifiers
260 Could only be done through serious symbol table wizardry, and you
261 probably never saw this before (at least in Perl 5).
265 Hand-written parameter checking in your C<new()> method and accessors.
267 With Moose, you define types declaratively, and then use them by name
272 C<Class::Delegation> or C<Class::Delegator>, but probably even more
275 With Moose, this is also declarative.
279 A C<new()> method which calls C<bless> on a reference.
281 Comes for free when you define a class with Moose.
285 A C<DESTROY()> method.
287 With Moose, this is called C<DEMOLISH()>.
289 =item * Object Instance
291 A blessed reference, usually a hash reference.
293 With Moose, this is an opaque thing which has a bunch of attributes
294 and methods, as defined by its class.
296 =item * Immutabilization
298 Moose comes with a feature called "immutabilization". When you make
299 your class immutable, it means you're done adding methods, attributes,
300 roles, etc. This lets Moose optimize your class with a bunch of
301 extremely dirty in-place code generation tricks that speed up things
302 like object construction and so on.
308 A metaclass is a class that describes classes. With Moose, every class
309 you define gets a C<meta()> method. It returns a L<Moose::Meta::Class>
310 object, which has an introspection API that can tell you about the
313 my $meta = User->meta();
315 for my $attribute ( $meta->get_all_attributes ) {
316 print $attribute->name(), "\n";
318 if ( $attribute->has_type_constraint ) {
319 print " type: ", $attribute->type_constraint->name, "\n";
323 for my $method ( $meta->get_all_methods ) {
324 print $method->name, "\n";
327 Almost every concept we defined earlier has a meta class, so we have
328 L<Moose::Meta::Class>, L<Moose::Meta::Attribute>,
329 L<Moose::Meta::Method>, L<Moose::Meta::Role>,
330 L<Moose::Meta::TypeConstraint>, L<Moose::Meta::Instance>, and so on.
332 =head1 BUT I NEED TO DO IT MY WAY!
334 One of the great things about Moose is that if you dig down and find
335 that it does something the "wrong way", you can change it by extending
336 a metaclass. For example, you can have arrayref based objects, you can
337 make your constructors strict (no unknown parameters allowed!), you can
338 define a naming scheme for attribute accessors, you can make a class a
339 Singleton, and much, much more.
341 Many of these extensions require surprisingly small amounts of code,
342 and once you've done it once, you'll never have to hand-code "your way
343 of doing things" again. Instead you'll just load your favorite
349 use MooseX::StrictConstructor
356 So you're sold on Moose. Time to learn how to really use it.
358 If you want to see how Moose would translate directly old school Perl
359 5 OO code, check out L<Moose::Unsweetened>. This might be helpful for
360 quickly wrapping your brain around some aspects of "the Moose way".
362 Obviously, the next thing to read is the rest of the L<Moose::Manual>.
364 After that we recommend that you start with the L<Moose::Cookbook>. If
365 you work your way through all the recipes under the basics section,
366 you should have a pretty good sense of how Moose works, and all of its
369 After that, check out the Role recipes. If you're really curious, go
370 on and read the Meta and Extending recipes, but those are mostly there
371 for people who want to be Moose wizards and change how Moose works.
375 Dave Rolsky E<lt>autarch@urth.orgE<gt>
377 =head1 COPYRIGHT AND LICENSE
379 Copyright 2008-2009 by Infinity Interactive, Inc.
381 L<http://www.iinteractive.com>
383 This library is free software; you can redistribute it and/or modify
384 it under the same terms as Perl itself.