uc/lc consistency, typo and style fixes for Moose::Manual documents
[gitmo/Moose.git] / lib / Moose / Manual / BestPractices.pod
CommitLineData
696cf5df 1=pod
2
f7435595 3=head1 NAME
4
5Moose::Manual::BestPractices - Get the most out of Moose
6
fd8a7262 7=head1 RECOMMENDATIONS
8
3bfacd05 9Moose has a lot of features, and there's definitely more than one way
10to do it. However, we think that picking a subset of these features
11and using them consistently makes everyone's life easier.
12
13Of course, as with any list of "best practices", these are really just
14opinions. Feel free to ignore us.
15
d67ce58f 16=head2 C<no Moose> and immutabilize
fd8a7262 17
18We recommend that you end your Moose class definitions by removing the
19Moose sugar and making your class immutable.
20
21 package Person;
22
23 use Moose;
24
25 # extends, roles, attributes, etc.
26
27 # methods
28
29 no Moose;
30
31 __PACKAGE__->meta->make_immutable;
32
33 1;
34
0c39debe 35The C<no Moose> bit is simply good code hygiene, and making classes
3bfacd05 36immutable speeds up a lot of things, most notably object construction.
37
d67ce58f 38=head2 Always call C<SUPER::BUILDARGS>
fd8a7262 39
3bfacd05 40If you override the C<BUILDARGS> method in your class, make sure to
41play nice and call C<SUPER::BUILDARGS> to handle cases you're not
0f62a437 42checking for explicitly.
3bfacd05 43
44The default C<BUILDARGS> method in L<Moose::Object> handles both a
45list and hashref of named parameters correctly, and also checks for a
46I<non-hashref> single argument.
47
d67ce58f 48=head2 Don't use the C<initializer> feature
3bfacd05 49
50Don't know what we're talking about? That's fine.
51
d67ce58f 52=head2 Use C<builder> instead of C<default> most of the time
3bfacd05 53
54Builders can be inherited, they have explicit names, and they're just
55plain cleaner.
56
57However, I<do> use a default when the default is a non-reference,
58I<or> when the default is simply an empty reference of some sort.
59
60Also, keep your builder methods private.
fd8a7262 61
0c39debe 62=head2 Use C<lazy_build>
fd8a7262 63
3bfacd05 64Lazy is good, and often solves initialization ordering problems. It's
65also good for deferring work that may never have to be done. If you're
66going to be lazy, use I<lazy_build> to save yourself some typing and
67standardize names.
fd8a7262 68
d67ce58f 69=head2 Consider keeping clearers and predicates private
fd8a7262 70
3bfacd05 71Does everyone I<really> need to be able to clear an attribute?
72Probably not. Don't expose this functionality outside your class
73by default.
b6477964 74
3bfacd05 75Predicates are less problematic, but there's no reason to make your
76public API bigger than it has to be.
fd8a7262 77
d67ce58f 78=head2 Default to read-only, and consider keeping writers private
fd8a7262 79
3bfacd05 80Making attributes mutable just means more complexity to account for in
81your program. The alternative to mutable state is to encourage users
82of your class to simply make new objects as needed.
fd8a7262 83
3bfacd05 84If you I<must> make an attribute read-write, consider making the
85writer a separate private method. Narrower APIs are easy to maintain,
86and mutable state is trouble.
b6477964 87
d67ce58f 88=head2 Think twice before changing an attribute's type in a subclass
541027c5 89
3bfacd05 90Down this path lies great confusion. If the attribute is an object
91itself, at least make sure that it has the same interface as the type
92of object in the parent class.
93
d67ce58f 94=head2 Use L<MooseX::AttributeHelpers> instead of C<auto_deref>
3bfacd05 95
dc747917 96The C<auto_deref> feature is a bit troublesome. Directly exposing a
3bfacd05 97complex attribute is ugly. Instead, consider using
0c39debe 98L<MooseX::AttributeHelpers> to define an API that exposes those pieces
3bfacd05 99of functionality that need exposing. Then you can expose just the
100functionality that you want.
541027c5 101
d67ce58f 102=head2 Namespace your types
541027c5 103
3bfacd05 104Use some sort of namespacing convention for type names. We recommend
105something like "MyApp.Type.Foo". I<Never> use "::" as the namespace
106separator, since that overlaps with actual class names.
541027c5 107
d67ce58f 108=head2 Coercion instead of unions
541027c5 109
3bfacd05 110Consider using a type coercion instead of a type union. This was
111covered at length in L<Moose::Manual::Types>.
112
d67ce58f 113=head2 Define all your types in one module
3bfacd05 114
115Define all your types and coercions in one module. This was also
116covered in L<Moose::Manual::Types>.
117
118=head1 AUTHOR
119
120Dave Rolsky E<lt>autarch@urth.orgE<gt>
121
122=head1 COPYRIGHT AND LICENSE
123
2840a3b2 124Copyright 2009 by Infinity Interactive, Inc.
3bfacd05 125
126L<http://www.iinteractive.com>
127
128This library is free software; you can redistribute it and/or modify
129it under the same terms as Perl itself.
130
131=cut