2

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.

PhD
  • 11,202
  • 14
  • 64
  • 112
  • Worried this could be too opinion-based, especially with multiple questions – D. Ben Knoble Mar 06 '17 at 18:25
  • @DavidBenKnoble - doing my best to keep it to the point - #2 would be a good balancing point to give an example. I know it's kinda open-ended but let's see if it gets closed :( – PhD Mar 06 '17 at 18:31
  • 2
    A very quick explanation: in the light of parametric polymorphism, type classes in general are much better way to achieve ad-hoc polymorphism than sub-typing. Sub-typing being what you define as OO/Java style classes. I know this is not a proper answer, but hopefully I gave you two terms to look up: ad-hoc vs parametric polymorphism. – pedrofurla Mar 06 '17 at 18:47
  • Oh, just realized you didn't mention ADTs. So another term you might want to look for is _algebraic data types_. Base traits are a very close (but not exact) implementation of ADTs. – pedrofurla Mar 06 '17 at 21:09
  • 1
    http://stackoverflow.com/questions/6730126/parametric-polymorphism-vs-ad-hoc-polymorphism – soote Mar 06 '17 at 23:15
  • 1
    @soote, this answer is gold – pedrofurla Mar 07 '17 at 01:22

1 Answers1

-2

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.

radumanolescu
  • 4,059
  • 2
  • 31
  • 44
  • I don't think your answer is particular good in addressing the question. See my comment on the question to see why. – pedrofurla Mar 06 '17 at 20:54
  • The OP is asking "when would you ever use a Java-style class? Why are case classes, abstract classes and traits not sufficient?" I have given an example of a situation where the use of a concrete class is useful. – radumanolescu Mar 06 '17 at 20:58
  • Yeah, can't totally disagree with that. – pedrofurla Mar 06 '17 at 21:10