Post Brief TOC
- Introduction
- Scala’s Case Class Benefit-6
- Advantages of Scala’s Case Classes
- Case Class Parameters
- Case Class Parameters with “var”
- Limitation of Case Class Parameters
- Case Object Vs Object(Normal Object)
- Case Class/Object is Serializable
- Case Classes may be abstract
- Case Class/Object usage in Real-time Projects
- Case Classes in Inheritance
Introduction
I have already discussed about Scala Case Class and Case Object basics in my previous post. Before going through this post, please read my previous post at: “Scala Case Class and Case Object Basics”
In this post, we are going to discuss some Advanced Concepts and Real-time Projects usage about Scala Case Class and Case Object. Please practice each example without fail to get some confidence on this concept.
Scala’s Case Class Benefit-6
As we discussed in my previous post at “Scala Case Class and Case Object Basics” in “Scala’s Case Class Benefit-2” section, Case Class parameters are by-default “val” that means they are constants.
Because of this feature, by nature Scala’s Case Classes are Immutable. Once we create an instance of a Case Class, we cannot update it’s parameters.
NOTE:- If we want to develop Immutable classes in Java, we need to follow some set of rules. However in Scala, it is easy to develop Immutable classes.
Advantages of Scala’s Case Classes
Scala’s Case Classes have the following advantages:
- By default, they are Immutable.
- They avoid lot of boilerplate code.
- They ease the development process and improve Productivity.
- They are very easy to use in Pattern Matching.
Case Class Parameters
In Scala’s Older versions, We can create Case Classes without Parameters. However, it’s NOT possible in recent Scala Releases. If we try to create a Case Class without Parameters or Fields, we will get compile-time error as shown below:
This has been deprecated since Scala version 2.7.7. It is removed in 2.11.1.
|
1 2 3 4 5 6 |
scala> case class CreditCard :1: error: case classes without a parameter list are not allowed; use either case objects or case classes with an explicit `()' as a parameter list. case class CreditCard |
So Scala Version 2.11.1 on-wards, we cannot create Case Classes without parameters.
If we don’t have any parameters, then We can create Case Class using empty parenthesis as shown blow:
|
1 2 3 4 |
scala> case class CreditCard() defined class CreditCard |
Or it’s always advisable to use Case Object in this case.
|
1 2 3 4 |
scala> case object CreditCard defined object CreditCard |
Case Class Parameters with “var”
As we know, by default Case Class Parameters are val. Even though, it is not recommended to change this nature, but we can change Case Class Parameters from val to var as shown below:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
scala> case class Book(var name:String) defined class Book scala> var book1 = Book("FP In Scala") book1: Book = Book(FP In Scala) scala> book1.name res0: String = FP In Scala scala> book1.name = "FP In Java" book1.name: String = FP In Java scala> book1.name res1: String = FP In Java |
As we know, “var” means variables. We can change it’s values.
By Default, Scala Compiler generates only getters for Case Class Parameters. However, if we use “var” to Case Class Parameters, Scala Compiler generates both setters and getters.
Limitation of Case Class Parameters
Before Scala Version 2.11.1, Scala Case Classes support maximum of 22 parameters only. If we use more than 22, we will get compile-time error.
However, this limitation has been removed in Scala Version 2.11.1. Now, Scala Case Classes supports more than 22 Parameters.
|
1 2 3 4 5 6 |
scala> case class Names(a1:String,a2:String,a3:String,a4:String,a5:String,a6:String,a7:String,a8:String,a9:String,a10:String, a11:String,a12:String,a13:String,a14:String,a15:String,a16:String,a17:String,a18:String,a19:String,a20:String, a21:String,a22:String,a23:String,a24:String,a25:String,a26:String,a27:String,a28:String,a29:String,a30:String) defined class Names |
That means we can use any number of Parameters in Case Classes.
Case Object Vs Object(Normal Object)
Normal object is created using “object” keyword. By default, it’s a singleton object.
|
1 2 3 |
object MyNormalObject |
Case Object is created using “case object” keywords. By default, it’s also a singleton object
|
1 2 3 |
case object MyCaseObject |
By Default, Case Object gets toString and hashCode methods. But normal object cannot.
By Default, Case Object is Serializable. But normal object is not.
Case Class/Object is Serializable
Yes, By Default, Case Object is Serializable. But normal object is not. We can prove this by using isInstanaceOf method as shown below:
|
1 2 3 4 5 6 7 8 9 10 |
scala> object MyNormalObject defined object MyNormalObject scala> MyNormalObject.isInstanceOf[Serializable] res0: Boolean = false scala> case object MyCaseObject defined object MyCaseObject scala> MyCaseObject.isInstanceOf[Serializable] res1: Boolean = true |
We can prove it in another way. If we decompile the class file, we can observe the following code.
|
1 2 3 4 5 |
public class Person implements scala.Product.scala.Serializable { // Data and methods } |
Case Classes may be abstract
Before Scala Version 2.7.0, we cannot create Case Classes as Abstract. However Scala Version 2.7.0 on-wards, Case Classes may be Abstract. We can create them as Abstract using “abstract” modifier as shown below:
|
1 2 3 4 |
scala> abstract case class Card(id:Int) defined class Card |
We should use “abstract” modifier before “case” modifier only like “abstract case class”. If we use it in other way, we will get compile-time error as shown below:
|
1 2 3 4 5 6 |
scala> case abstract class Card(id:Int) :1: error: illegal start of definition case abstract class Card(id:Int) ^ |
Case Class/Object usage in Real-time Projects
If you are new to Scala Development, you should know this point to get Scala Jobs and easy to start Scala Development Projects.
In Real-time Projects, we use Case Classes to define application MODEL objects (Here model means M in MVC. In other words, Model means POJO, Java Bean etc).
Case Classes in Inheritance
In this section, We will discuss Case Classes in Inheritance scenarios one by one with some examples.
-
- Case Class can NOT extend another Case class.
Before Scala Version 2.7.0, a Case Class cannot extend from other Case Class. However, They allowed to create a Case class by extending another case class in Scala Version 2.7.0 as shown below:
|
1 2 3 4 |
case class Foo(x: Int) case class Bar(override val x: Int, y: Int) extends Foo(x) |
However, they have removed this feature in recent Scala Versions. So a Case Class cannot extend another Case class.
|
1 2 3 4 5 6 7 |
scala> case class Foo(x: Int) defined class Foo scala> case class Bar(override val x: Int, y: Int) extends Foo(x) :12: error: case class Bar has case ancestor Foo, but case-to-case inheritance is prohibited. To overcome this limitation, use extractors to pattern match on non-leaf nodes. case class Bar(override val x: Int, y: Int) extends Foo(x) |
NOTE:- In Scala Language, case-to-case inheritance is prohibited.
- Case Class can extend another Class or Abstract Class.
|
1 2 3 4 5 6 |
scala> abstract class Card(id:Int) defined class Card scala> case class DebitCard(id:Int,name:String,cvv:Int) extends Card(id) defined class DebitCard |
- A Case Class or Case Object can extend a Trait.
|
1 2 3 4 5 6 7 8 |
scala> trait Event defined trait Event scala> case object SimpleEvent extends Event defined object SimpleEvent scala> case class ComplexEvent() extends Event defined class ComplexEvent |
I hope, this much information is enough to work on Scala-based projects. However, there are many more concepts to discuss about Case Classes. If anybody interested to know more, please drop me a comment below.
NOTE:- We will discuss about “How to use Case Class/Object in Pattern Matching” to understand the main benefit of Case Class/Object concept in my coming post “Scala Pattern Matching In-Depth (Coming soon).
That’s it all about Scala Case Class and Case Object. We will discuss some more Scala concepts in my coming posts.
Please drop me a comment if you like my post or have any typo errors/issues/suggestions.