In response to Issue #1677, the first two sections were in the wrong order, so I reversed them. I also simplified some other text. (#1682)

Author: alvinj

_overviews/scala-book/case-classes.md

@@ -1,5 +1,4 @@
 ---
-type: section
 layout: multipage-overview
 title: Case Classes
 description: This lesson provides an introduction to 'case classes' in Scala.
@@ -26,6 +25,23 @@ These features are all demonstrated in the following sections.
 
 
 
+## With `apply` you don’t need `new`
+
+When you define a class as a `case` class, you don’t have to use the `new` keyword to create a new instance:
+
+```scala
+scala> case class Person(name: String, relation: String)
+defined class Person
+
+// "new" not needed before Person
+scala> val christina = Person("Christina", "niece")
+christina: Person = Person(Christina,niece)
+```
+
+As discussed in the previous lesson, this works because a method named `apply` is generated inside `Person`’s companion object.
+
+
+
 ## No mutator methods
 
 Case class constructor parameters are `val` fields by default, so an *accessor* method is generated for each parameter:
@@ -35,7 +51,7 @@ scala> christina.name
 res0: String = Christina
 ```
 
-But, mutator methods are not generated:
+But, *mutator* methods are not generated:
 
 ```scala
 // can't mutate the `name` field
@@ -49,26 +65,9 @@ Because in FP you never mutate data structures, it makes sense that constructor
 
 
 
-## An `apply` method means you don’t need `new`
-
-When you define a class as a `case` class, you don’t have to use the `new` keyword to create a new instance:
-
-```scala
-scala> case class Person(name: String, relation: String)
-defined class Person
-
-// "new" not needed before Person
-scala> val christina = Person("Christina", "niece")
-christina: Person = Person(Christina,niece)
-```
-
-As discussed in the previous lesson, this works because a method named `apply` is generated inside `Person`’s companion object.
-
-
-
 ## An `unapply` method
 
-In the previous lesson on companion objects you saw how to write `unapply` methods. A great thing about case classes is that they automatically generate an `unapply` method, so you don’t have to write one.
+In the previous lesson on companion objects you saw how to write `unapply` methods. A great thing about a case class is that it automatically generates an `unapply` method for your class, so you don’t have to write one.
 
 To demonstrate this, imagine that you have this trait:
 
@@ -85,7 +84,7 @@ case class Student(name: String, year: Int) extends Person
 case class Teacher(name: String, specialty: String) extends Person
 ```
 
-Because those are defined as case classes — and a case class has a built-in `unapply` method — you can write a match expression like this:
+Because those are defined as case classes — and they have built-in `unapply` methods — you can write a match expression like this:
 
 ```scala
 def getPrintableString(p: Person): String = p match {
@@ -187,11 +186,3 @@ res0: Person = Person(Christina,niece)
 While all of these features are great benefits to functional programming, as they write in the book, [Programming in Scala](https://www.amazon.com/Programming-Scala-Updated-2-12/dp/0981531687/) (Odersky, Spoon, and Venners), “the biggest advantage of case classes is that they support pattern matching.” Pattern matching is a major feature of FP languages, and Scala’s case classes provide a simple way to implement pattern matching in match expressions and other areas.
 
 
-
-
-
-
-
-
-
-