El poder de Option: Más allá del pattern matching

Una de las primeras cosas a las que le tomamos gusto cuando aprende Scala, sobre todo si venimos de Java, es al pattern matching, aunque una de las cosas que desconciertan un poco es la manera en que funcionan los mapas.

En Java, si tenemos un java.util.Map simplemente le pedimos el valor para una llave, y nos devuelve el valor, o null si no lo tiene. O si el mapa acepta nulos, entonces puede devolvernos null si es que tiene null guardado bajo la llave que indicamos. ¿Cómo podemos diferenciar entre el caso en que el mapa no tiene la llave, o si tiene almacenado null bajo esa llave? Podemos verificar usando containsKey.

Entonces, tenemos los siguientes casos:

¿De verdad nos gusta hacer esto en Java? En la práctica, casi no tenemos mapas donde guardemos null, incluso algunos lo consideran una mala práctica. Pero puede darse el caso... pero normalmente tenemos solamente algo como esto:

Y a partir de ahí ya estamos seguros que tenemos un X. Pero bueno, los que llevamos tiempo en Java ya estamos acostumbrados a lidiar así con los mapas. Y luego llegamos a Scala y resulta que es algo completamente distinto:

var x = mapa("X")

Me devuelve el valor almacenado bajo la llave "X", o arroja una excepción si el mapa no tiene esa llave. Qué molesto tener que poner cada acceso a un mapa en un try-catch! Pero hay otra manera:

var x = mapa.get("X")

Pero resulta que el método get del mapa en Scala no devuelve el valor directamente, sino una cosa llamada Option.

Option básico

Esta clase abstracta Option puede tener dos encarnaciones en la práctica: Some y None. None pues significa que no hay nada, y Some es un contenedor de un objeto (que puede ser null, por cierto). De modo que con esa última línea de código, x puede ser None o puede ser Some(algo), donde algo es el objeto almacenado en el mapa, el que realmente nos interesa.

Entonces, leyendo un poco nos encontramos con que podemos hacer algo así, si queremos obtener el mismo comportamiento del último ejemplo que puse en Java, donde obtenemos el valor y si no está lo creamos y almacenamos:

Si el mapa tiene el valor, entraremos al caso de Some(x) donde simplemente devolvemos el valor contenido en el Some. Si no tiene el valor, entramos al caso None, en donde creamos el objeto que necesitamos, lo ponemos en el mapa y lo devolvemos, usando el método apply, el cual no arrojará excepción en este caso porque acabamos de poner el valor en el mapa.

Más allá del pattern matching

Pero Option no nada más es un simple contenedor de valores. Tiene varios métodos muy útiles, que nos permiten encadenar la ejecución de distintas funciones, cada una operando sobre el resultado de la anterior. Un ejemplo es el método map. Supongamos que tenemos un mapa cuyos valores son cadenas y queremos obtener una de esas cadenas, pero en mayúscula y alrevés. Al final haremos pattern matching pero sólo sobre el resultado final, no tenemos que estar manejando condiciones intermedias:

Si el mapa tiene una cadena bajo la llave indicada, obtendremos un Option, sobre el cual invocamos map con la función anónima _.toUpperCase, la cual invocará sobre la cadena contenida en el Some; el resultado de eso será otro Some pero que ahora contiene la cadena en mayúsculas; a ese le invocaremos map con la función anónima _.reverse y el resultado será otro Some que contiene la cadena alrevés. De este modo, si la cadena original era "hola", al final tenemos "ALOH" y sobre eso se hace el match.

Si el mapa no tuviera una cadena bajo la llave indicada, entonces devuelve None. Cuando se invoca map sobre None, no se ejecuta la función que recibe como parámetro, simplemente se devuelve None.

Las funciones que se pasan al método map pueden incluso devolver un objeto de una clase distinta. Por ejemplo si hacemos algo así:

mapa.get("llave").map(_.length)

Obtendremos al final un Option con la longitud de la cadena (un Int).

Option tiene varios métodos que resultan muy útiles para operar directamente sobre los valores sin tener que estar comprobando si los tenemos o no, lo cual nos ahorra el insertar varios if's. Algunos ejemplos son filter, orElse, getOrElse, orNull:

Este tipo de cosas es lo que nos permite usar un estilo de programación más declarativo, en vez de imperativo. Regresando al ejemplo de obtener un objeto de un mapa y agregarlo en caso de no estar, resulta que los mapas en Scala son animales bastante más sofisticados que los mapas de Java. En Scala, un mapa también tiene varios métodos muy útiles como collect, exists, filter, find, getOrElse y getOrElseUpdate, entre otros. Este último nos sirve precisamente para realizar esa operación que ya vimos en Java y también en Scala con pattern matching, pero en un solo paso:

Si el mapa contiene la llave "X", devolverá el valor de la misma, ya no como un Option sino directamente el valor; pero si no tiene un valor bajo esa llave, entonces ejecuta la función que se le pasa como segundo parámetro, almacena el resultado de la misma bajo la llave solicitada, y lo devuelve. Esta última versión no sólo es más breve que la de 4 líneas en Java y sobre todo que la de 5 líneas en Scala, sino que por el nombre del método queda más claro lo que está haciendo.

En fin, este tipo de cosas son las que he ido descubriendo en mis exploraciones de Scala, espero les sean de utilidad.