When programming with 'idiomatic' Scala is the use of 'concrete classes' optional/redundant?

Question

I've just moved into the functional programming domain and am working with Scala.

After getting mentored with the Type Classes pattern by a senior engineer, I'm trying to wrap my head around the "need" for concrete classes when designing scala programs.

I was told by the engineer that in the last 3+ years of Scala programming he's never had to use "classes" like you would in the OOP/Java land. Just traits, case classes and 'objects' implementing the traits and the occasional use for abstract classes.

This leads me to the following questions:

1. If following the idiomatic type classes approach like above, is the use of "classes" (i.e., concrete classes like in Java) substantially downplayed (or rendered moot)? I.e., if you need to do something imperative, only then do they matter, else can be downplayed, almost completely.

2. If #1 is not entirely true, what's a good counterexample?

3. I understand that the above pattern comes from Haskell and is more functional in nature. Does that mean, that although Scala is a hybrid language, if you choose the purely functional (a.k.a. idiomatic) approach, then the OOP classes really take a backseat?

I understand how abstract classes could still be useful owing to constructor parameters. However, my question is around the need to organize code via classes as in the OOP land.

Answer 1

A case class cannot extend another case class, so if there is any chance that some class in the future might need to extend a given class C, then C should not be a case class.