Permalink
Browse files

Improved line and pagebreaking for chapter 7.

  • Loading branch information...
1 parent 2a42cc5 commit 456d6fe186ae84fc0556dd1b888e58ccf807a659 @chromatic committed Dec 8, 2011
Showing with 166 additions and 165 deletions.
  1. +9 −10 sections/advanced_oo.pod
  2. +12 −17 sections/blessed_references.pod
  3. +8 −4 sections/chapter_07.pod
  4. +109 −107 sections/moose.pod
  5. +28 −27 sections/reflection.pod
View
@@ -21,7 +21,7 @@ with code declared elsewhere?
X<OO; is-a>
X<OO; has-a>
-Inheritance is one tool. It's not the only tool. Although C<Car> may extend
+Inheritance is but one of many tools. Although C<Car> may extend
C<Vehicle::Wheeled> (an I<is-a relationship>), it's likely better for C<Car> to
I<contain> contain several C<Wheel> objects as instance attributes (a I<has-a
relationship>).
@@ -35,15 +35,14 @@ entities are easier to understand, test, and maintain.
X<OO; single responsibility principle>
-When you design your object system, model the problem in terms of
-responsibilities--the behavior each entity must provide. For example, an
-C<Employee> object may represent specific information about a person's name,
-contact information, and other personal data, while a C<Job> object may
-represent business responsibilities. Separating these entities in terms of
-their responsibilities allows the C<Employee> class to consider only the
-problem of managing information specific to who the person is and the C<Job>
-class to represent what the person does. (Two C<Employee>s may have a
-C<Job>-sharing arrangement, for example.)
+When you design your object system, consider the responsibilities of each
+entity. For example, an C<Employee> object may represent specific information
+about a person's name, contact information, and other personal data, while a
+C<Job> object may represent business responsibilities. Separating these
+entities in terms of their responsibilities allows the C<Employee> class to
+consider only the problem of managing information specific to who the person is
+and the C<Job> class to represent what the person does. (Two C<Employee>s may
+have a C<Job>-sharing arrangement, for example.)
When each class has a single responsibility, you improve the encapsulation of
class-specific data and behaviors and reduce coupling between classes.
@@ -72,9 +72,9 @@ references are most common, but you can bless any type of reference:
=end programlisting
-Whereas classes built with Moose define their own object attributes
-declaratively, Perl 5's default OO is lax. A class representing basketball
-players which stores jersey number and position might use a constructor like:
+Moose classes define object attributes declaratively, but Perl 5's default OO
+is lax. A class representing basketball players which stores jersey number and
+position might use a constructor like:
=begin programlisting
@@ -83,7 +83,6 @@ players which stores jersey number and position might use a constructor like:
sub new
{
my ($class, %attrs) = @_;
-
bless \%attrs, $class;
}
}
@@ -94,33 +93,29 @@ players which stores jersey number and position might use a constructor like:
=begin programlisting
- my $joel = Player->new(
- number => 10,
- position => 'center',
- );
+ my $joel = Player->new( number => 10,
+ position => 'center' );
- my $dante = Player->new(
- number => 33,
- position => 'forward',
- );
+ my $dante = Player->new( number => 33,
+ position => 'forward' );
=end programlisting
-The object's methods can access hash elements directly:
+The class's methods can access object attributes as hash elements directly:
=begin programlisting
sub format
{
my $self = shift;
- return '#' . $self->{number} . ' plays ' . $self->{position};
+ return '#' . $self->{number}
+ . ' plays ' . $self->{position};
}
=end programlisting
-... but so can any other code. If external code violates attribute
-encapsulation, you can never change the object's internal representation
-without breaking external code. Accessor methods are safer:
+... but so can any other code, so any change to the object's internal
+representation may break other code. Accessor methods are safer:
=begin programlisting
View
@@ -5,11 +5,15 @@ you must manage. Our only hope to manage this complexity is to exploit
abstraction (treating similar things similarly) and encapsulation (grouping
related details together).
+X<OO>
+X<objects>
+X<OO; classes>
+X<classes>
+
Functions alone are insufficient for large problems. Several techniques group
-functions into units of related behaviors--one popular technique is object
-orientation. Perl 5's default object system is flexible, but minimal. You can
-build great things on top of it, but it provides little assistance for some
-basic tasks.
+functions into units of related behaviors. One popular technique is I<object
+orientation> (OO), or I<object oriented programming> (OOP), where programs work
+with I<objects>--discrete, unique entities with their own identities.
L<moose>
Oops, something went wrong.

0 comments on commit 456d6fe

Please sign in to comment.