6

Scala proporciona colecciones inmutables, como Set, List, Map. Entiendo que la inmutabilidad tiene ventajas en programas concurrentes. Sin embargo, ¿cuáles son exactamente las ventajas de la inmutabilidad en el procesamiento de datos normal?¿Cuáles son las ventajas reales de las colecciones inmutables?

¿Qué sucede si enumero subsets, permutations y combinations por ejemplo? ¿Las colecciones inmutables tienen alguna ventaja aquí?

Respuesta

10

¿Cuáles son exactamente las ventajas de la inmutabilidad en el procesamiento de datos normal?

En términos generales, los objetos inmutables son más fáciles/simples de razonar.

+3

Menos estado = menos análisis. –

+0

Que permite que las herramientas (es decir, los compiladores) realicen más optimizaciones – michid

+1

Estoy de acuerdo, y significa que el uso de objetos inmutables produce código que con frecuencia es más correcto la primera vez. Junto con el tipado estático, esto hace que el código de Scala requiera una depuración notablemente pequeña. –

7

Lo hace. Como está enumerando en una colección, presumiblemente querría estar seguro de que los elementos no se agregan o eliminan inadvertidamente mientras enumera.

La inmutabilidad es en gran medida un paradigma en la programación funcional. Hacer que las colecciones sean inmutables permite pensar en ellas de manera similar a los tipos de datos primitivos (es decir, modificar una colección o cualquier otro objeto para crear un objeto diferente así como agregar 2 a 3 no modifica 3, pero crea 5)

+0

Ese es un comentario muy interesante, parece que le da semántica "similar a una transacción" en sus datos, es decir, si hace 'por ((k, v) <- myMap) {algo (k, v)}' y alguien hace 'myMap + = k2 -> v2' dentro de' something', todavía estará iterando sobre una instantánea de lo que 'myMap' tenía cuando inició el ciclo. ¿Derecha? Nunca pensé en eso. –

4

Si sus datos no cambian después de la creación, use estructuras de datos inmutables. El tipo que elijas identificará la intención de uso. Algo más específico requeriría conocimiento sobre su espacio problema en particular.

Puede que realmente esté buscando un subconjunto, una permutación o un generador de combinación, y luego la discusión de las estructuras de datos es discutible.

Además, usted mencionó que comprende las ventajas concurrentes. Presumiblemente, está lanzando algún algoritmo en permutaciones y subconjuntos, y hay una buena posibilidad de que el algoritmo se pueda paralelizar en cierta medida. Si ese es el caso, usar estructuras inmutables por adelantado asegura que su implementación inicial del algoritmo X se transformará fácilmente en el algoritmo concurrente X.

6

Para expandir la respuesta de Matt: Desde mi experiencia personal puedo decir que implementa algoritmos basados ​​en árboles de búsqueda (por ejemplo, amplitud primero, profundidad primero, retroceso) usando colecciones mutables que terminan regularmente como una pila de mierda humeante: o se olvida de copiar una colección antes de una llamada recursiva o no puede recuperar los cambios correctamente si recupera la colección. En esa área, las colecciones inmutables son claramente superiores. Terminé escribiendo mi propia lista inmutable en Java cuando no pude resolver un problema con las colecciones de Java. Y he aquí, la primera implementación "inmutable" funcionó de inmediato.

+1

Espero que no hayas escrito la implementación inmutable de la lista en un momento muy reciente, ya que hemos tenido ['Collections # unmodifiableList()' (Java SE)] (http://download.oracle.com/javase/7/docs /api/java/util/Collections.html#unmodifiableList%28java.util.List%29) y ['ImmutableList' (Google Guava)] (http://docs.guava-libraries.googlecode.com/git-history/ v9.0/javadoc/com/google/common/collect/ImmutableList.html) por un tiempo. –

+1

'unmodifiableList' no es útil en absoluto, p. no puede obtener una lista con un elemento adicional atrás o así. La guayaba es genial, pero a veces exagerada. La mejor implementación de lista inmutable que conozco es de http://functionaljava.org – Landei

2

Tengo un par de ventajas a añadir a la lista:

  1. colecciones inmutables no pueden ser invalidadas por debajo suyo

    Es decir, es totalmente bien para tener miembros val pública inmutables de una clase Scala. Son de solo lectura por definición. Compare con Java donde no solo debe recordar hacer que el miembro sea privado sino también escribir un método get que devuelva una copia del objeto para que el original no sea modificado por el código de llamada.

  2. Las estructuras de datos inmutables son persistentes.Esto significa que la colección inmutable obtenida llamando al filter en su TreeSet en realidad comparte algunos de sus nodos con el original. Esto se traduce en ahorros de tiempo y espacio y compensa algunas de las penalidades incurridas al usar la inmutabilidad.

0

algunas de las ventajas inmutabilidad:

1 - más pequeño margen de error (que siempre sabe lo que hay en sus colecciones y Variables de lectura).

2 - puede escribir programas simultáneos sin preocuparse de que los hilos se pisen entre sí al modificar variables y colecciones.

Cuestiones relacionadas