6 Moose::Cookbook::Basics::Recipe2 - A simple B<BankAccount> example
13 has 'balance' => (isa => 'Int', is => 'rw', default => 0);
16 my ($self, $amount) = @_;
17 $self->balance($self->balance + $amount);
21 my ($self, $amount) = @_;
22 my $current_balance = $self->balance();
23 ($current_balance >= $amount)
24 || confess "Account overdrawn";
25 $self->balance($current_balance - $amount);
28 package CheckingAccount;
31 extends 'BankAccount';
33 has 'overdraft_account' => (isa => 'BankAccount', is => 'rw');
35 before 'withdraw' => sub {
36 my ($self, $amount) = @_;
37 my $overdraft_amount = $amount - $self->balance();
38 if ($self->overdraft_account && $overdraft_amount > 0) {
39 $self->overdraft_account->withdraw($overdraft_amount);
40 $self->deposit($overdraft_amount);
46 The first recipe demonstrated how to build very basic Moose classes,
47 focusing on creating and manipulating attributes. The objects in that
48 recipe were very data-oriented, and did not have much in the way of
49 behavior (i.e. methods). In this recipe, we expand upon the concepts
50 from the first recipe to include some real behavior. In particular, we
51 show how you can use a method modifier to implement new behavior for a
54 The classes in the SYNOPSIS show two kinds of bank account. A simple
55 bank account has one attribute, the balance, and two behaviors,
56 depositing and withdrawing money.
58 We then extend the basic bank account in the CheckingAccount
59 class. This class adds another attribute, an overdraft account. It
60 also adds overdraft protection to the withdraw method. If you try to
61 withdraw more than you have, the checking account attempts to
62 reconcile the difference by withdrawing money from the overdraft
65 The first class, B<BankAccount>, introduces a new attribute feature, a
68 has 'balance' => (isa => 'Int', is => 'rw', default => 0);
70 This says that a B<BankAccount> has a C<balance> attribute, which has
71 a C<Int> type constraint, a read/write accessor, and a default value
72 of C<0>. This means that every instance of B<BankAccount> that is
73 created will have its C<balance> slot initialized to C<0>, unless some
74 other value is provided to the constructor.
76 The C<deposit> and C<withdraw> methods should be fairly
77 self-explanatory, as they are just plain old Perl 5 OO.
79 As you know from the first recipe, the keyword C<extends> sets a
80 class's superclass. Here we see that B<CheckingAccount> C<extends>
81 B<BankAccount>. The next line introduces yet another new attribute
82 feature, class-based type constraints:
84 has 'overdraft_account' => (isa => 'BankAccount', is => 'rw');
86 Up until now, we have only seen the C<Int> type constraint, which (as
87 we saw in the first recipe) is a builtin type constraint. The
88 C<BankAccount> type constraint is new, and was actually defined the
89 moment we created the B<BankAccount> class itself. In fact, Moose
90 creates a corresponding type constraint for every class in your
93 This means that in the first recipe, constraints for both C<Point> and
94 C<Point3D> were created. In this recipe, both C<BankAccount> and
95 C<CheckingAccount> type constraints are created automatically. Moose
96 does this as a convenience so that your classes and type constraint
97 can be kept in sync with one another. In short, Moose makes sure that
98 it will just DWIM (3).
100 In B<CheckingAccount>, we see another method modifier, the C<before>
103 before 'withdraw' => sub {
104 my ($self, $amount) = @_;
105 my $overdraft_amount = $amount - $self->balance();
106 if ($self->overdraft_account && $overdraft_amount > 0) {
107 $self->overdraft_account->withdraw($overdraft_amount);
108 $self->deposit($overdraft_amount);
112 Just as with the C<after> modifier from the first recipe, Moose will
113 handle calling the superclass method (in this case C<<
114 BankAccount->withdraw >>).
116 The C<before> modifier will (obviously) run I<before> the code from
117 the superclass is run. Here, C<before> modifier implements overdraft
118 protection by first checking if there are available funds in the
119 checking account. If not (and if there is an overdraft account
120 available), it transfers the amount needed into the checking
123 As with the method modifier in the first recipe, we could use
124 C<SUPER::> to get the same effect:
127 my ($self, $amount) = @_;
128 my $overdraft_amount = $amount - $self->balance();
129 if ($self->overdraft_account && $overdraft_amount > 0) {
130 $self->overdraft_account->withdraw($overdraft_amount);
131 $self->deposit($overdraft_amount);
133 $self->SUPER::withdraw($amount);
136 The benefit of taking the method modifier approach is we do not need
137 to remember to call C<SUPER::withdraw> and pass it the C<$amount>
138 argument when writing C<< CheckingAccount->withdraw >>.
140 This is actually more than just a convenience for forgetful
141 programmers. Using method modifiers helps isolate subclasses from
142 changes in the superclasses. For instance, if B<<
143 BankAccount->withdraw >> were to add an additional argument of some
144 kind, the version of B<< CheckingAccount->withdraw >> which uses
145 C<SUPER::withdraw> would not pass that extra argument correctly,
146 whereas the method modifier version would automatically pass along all
149 Just as with the first recipe, object instantiation uses the C<new>
150 method, which accepts named parameters.
152 my $savings_account = BankAccount->new( balance => 250 );
154 my $checking_account = CheckingAccount->new(
156 overdraft_account => $savings_account,
159 And as with the first recipe, a more in-depth example can be found in
160 the F<t/000_recipes/basics/002_recipe.t> test file.
164 The aim of this recipe was to take the knowledge gained in the first
165 recipe and expand upon it with a more realistic use case. The next
166 recipe will expand on Moose attributes to create a behaviorally
167 sophisticated class defined almost entirely by its attributes.
175 If you're paying close attention, you might realize that there's a
176 circular loop waiting to happen here. A smarter example would have to
177 make sure that we don't accidentally create a loop between the
178 checking account and its overdraft account.
182 In reality, this creation is sensitive to the order in which modules
183 are loaded. In more complicated cases, you may find that you need to
184 explicitly declare a class type before the corresponding is loaded.
188 Moose does not attempt to encode a class's is-a relationships within
189 the type constraint hierarchy. Instead, Moose just considers the class
190 type constraint to be a subtype of C<Object>, and specializes the
191 constraint check to allow for subclasses. This means that an instance
192 of B<CheckingAccount> will pass a C<BankAccount> type constraint
193 successfully. For more details, please refer to the
194 L<Moose::Util::TypeConstraints> documentation.
198 If the overdraft account does not have the amount needed, it will
199 throw an error. Of course, the overdraft account could also have
200 overdraft protection. See note 1.
210 The BankAccount example in this recipe is directly taken from the
211 examples in this chapter of "Practical Common Lisp":
213 L<http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html>
219 Stevan Little E<lt>stevan@iinteractive.comE<gt>
221 =head1 COPYRIGHT AND LICENSE
223 Copyright 2006-2008 by Infinity Interactive, Inc.
225 L<http://www.iinteractive.com>
227 This library is free software; you can redistribute it and/or modify
228 it under the same terms as Perl itself.