From 43a04197ebec7f8b33aaf14e7da212f84b9e3f2a Mon Sep 17 00:00:00 2001 From: Alvin Alexander Date: Mon, 13 Apr 2020 13:58:24 -0600 Subject: [PATCH] In response to Issue #1677, the first two sections were in the wrong order, so I reversed them. I also simplified some other text. --- _overviews/scala-book/case-classes.md | 49 +++++++++++---------------- 1 file changed, 20 insertions(+), 29 deletions(-) diff --git a/_overviews/scala-book/case-classes.md b/_overviews/scala-book/case-classes.md index 0c36c6b424..a497e1e33a 100644 --- a/_overviews/scala-book/case-classes.md +++ b/_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. - - - - - - - -