Improved line and pagebreaking for chapter 7.

sections/advanced_oo.pod

@@ -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.

sections/blessed_references.pod

@@ -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
 

sections/chapter_07.pod

@@ -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>