software - ¿Donde las clases de casos NO deben usarse en Scala?

scala vs java

Question

Las clases de casos en Scala son clases estándar mejoradas con coincidencia de patrones, iguales, ... (¿o me equivoco?). Además, no requieren ninguna palabra clave "nueva" para su instanciación. Me parece que son más simples de definir que las clases regulares (¿o me equivoco de nuevo?).

Hay muchas páginas web que indican dónde se deben usar (sobre todo acerca de la coincidencia de patrones). Pero, ¿dónde deberían evitarse? ¿Por qué no los usamos en todas partes?

Answer 1

Hay muchos lugares donde las clases de casos no son adecuadas:

• Cuando uno desea ocultar la estructura de datos.
• Como parte de una jerarquía de tipos de más de dos o tres niveles.
• Cuando el constructor requiera consideraciones especiales.
• Cuando el extractor requiere consideraciones especiales.
• Cuando la igualdad y el código hash requieren consideraciones especiales.

A veces, estos requisitos aparecen al final del diseño y requieren uno para convertir una clase de caso en una clase normal. Dado que los beneficios de una clase de casos realmente no son tan grandes, aparte de los pocos casos especiales para los que fueron diseñados especialmente, mi propia recomendación es que no se convierta en una clase de casos a menos que haya un uso claro para ellos.

O, en otras palabras, no diseñar en exceso.

Answer 2

Heredar de las clases de casos es problemático. Supongamos que tienes un código así:

case class Person(name: String) { }

case class Homeowner(address: String,override val name: String)
  extends Person(name) { }

scala> Person("John") == Homeowner("1 Main St","John")
res0:  Boolean = true

scala> Homeowner("1 Main St","John") == Person("John")
res1: Boolean = false

Quizás esto es lo que quieres, pero normalmente quieres a == b si y solo si b == a. Desafortunadamente, el compilador no puede arreglar esto sensiblemente de forma automática.

Esto empeora aún más porque el hashCode of Person("John") no es el mismo que el hashCode of Homeowner("1 Main St","John") , por lo que ahora es igual a actos raros y hashCode es raro.

Siempre que sepa qué esperar, la herencia de las clases de casos puede dar resultados comprensibles, pero se ha visto como una forma incorrecta (y, por lo tanto, ha quedado obsoleta en 2.8).

Answer 3

Puede ser tentador usar clases de casos porque quiere que toString / equals / hashCode sea gratis. Esto puede causar problemas, así que evita hacerlo.

Desearía que hubiera una anotación que te permita obtener esas cosas útiles sin hacer una clase de caso, pero tal vez sea más difícil de lo que parece.

Answer 4

Una desventaja que se menciona en la Programación en Scala es que debido a las cosas generadas automáticamente para las clases de casos, los objetos se vuelven más grandes que para las clases normales, por lo que si la eficiencia de la memoria es importante, es posible que desee usar clases regulares.