Varianza, Covarianza y Contravarianza

En los sistemas de tipado estático, existe este concepto de varianza, que a veces puede entenderse muy fácil pero tampoco es tan intuitivo como parece.

Para ilustrar la varianza, vamos a definir una jerarquía de clases muy simple:

Y definimos un método o función que usa estos tipos:

Primero que nada, viéndolo desde fuera, ¿A qué tipo de variables podemos asignar lo que devuelve esta función?

Las primeras dos líneas son correctas, la tercera da un error. Esto es porque la función devuelve un valor de tipo B, y B es también un A. Pero no podemos asignar a una subclase de B, al menos no sin hacer un cast, pero no vamos a hacer casts en esta ocasión. B no es un C, por lo tanto la tercera línea no compila.

Hasta aquí todo bien. Ahora, ¿Qué le podemos pasar como argumento a esta función? Tiene un solo parámetro de tipo B. En esta ocasión, es alrevés:

No podemos pasar un A como argumento porque la función espera un B y un A no es un B. Podemos obviamente pasar un B, pero también podemos pasar cualquier subtipo de B.

Y por último: ¿Qué puede devolver realmente la función? Está declarada con un tipo de retorno B, por lo tanto puede devolver B o cualquier subtipo de B. Esta implementación es válida:

A partir de Java 5, cuando sobreescriben un método de una interfaz o superclase, pueden definir un tipo de retorno más específico que el del método original. Es decir pueden usar un subtipo, no tiene que ser forzosamente el tipo original. Esto significa que los tipos de retorno son covariantes:

Con los parámetros no se puede hacer algo similar, porque Java tiene sobrecarga de métodos, de modo que si en la clase Padre definimos   y en la clase Hijo definimos  , son dos métodos completamente distintos (y el método Hijo.otro no puede invocar a   porque no hay tal, dado que no está sobreescribiendo el método del mismo nombre en la clase Padre).

Ahora, donde se pone interesante el asunto (y cuando digo interesante, quiero decir complicado y confuso), es cuando intervienen los parámetros de tipo, mejor conocidos como generics. Imaginemos un contenedor muy simple:

En Java, los parámetros de tipo son invariantes por default. Entonces, ¿Qué pasa con esta función?

¿Las tres declaraciones son válidas? Siguiendo la misma lógica que para el ejemplo anterior, las primeras dos llamadas deberían ser válidas, ¿no? Y solamente la tercera debe fallar, ¿verdad?

Pues no.

Solamente la segunda llamada es válida. Las otras dos nos van a dar un error que nos ayuda en nada:

Pero, pero, pero...   es un  , ¿o no? Por lo tanto en donde puedo recibir un  , puede recibir un  , porque si un B es también un A, entonces un   OBVIO es también un  !

No.

Para empezar,   es una clase que contiene algo, de un tipo desconocido al momento de declarar esa clase; ese   no se sabe qué es, puede ser cualquier cosa. Pero, contrario a lo que se piensa inicialmente, un   no es un  . Tampoco es un  .

Recuerden lo que dije al principio: En Java, por default, los parámetros de tipo son invariantes. Esto quiere decir que no aplica nada de lo que ya conocen de herencia cuando se trata de generics.

Para que un   sea un  , el tipo de parámetro de Cont debe ser covariante. El lugar más obvio para definir la varianza de un tipo de parámetro, es en donde se declara; sin embargo, en Java no es así; la varianza se declara en donde se usa el tipo, no donde fue declarado. Eso significa que se define en donde se invoca  . WAT??? Les dije que se iba a poner interesante:

Ahora sí, solamente la tercera línea les da error. La segunda línea se pudo haber quedado simplemente como  , pero entonces no se interpreta como covariante. A poco no son fáciles e intuitivos los generics y esto de la varianza?

Las primeras dos líneas funcionan porque definen un Cont que es covariante en A y un Cont que es covariante en B. El tercero, pues aunque sea covariante en C, no compila porque la función devuelve un Cont que es covariante en B, y pues B no es C. Ahora sí es similar al primer ejemplo donde no usamos generics.

Hay una manera de hacer que la tercera línea compile:

Eso significa que tenemos una variable tipo Cont contravariante en C. Eso significa que se le puede asignar un Cont de C o cualquier supertipo de C, y el tipo de retorno de g es   y B es un supertipo de C, por tanto es válida la asignación.

Ahora vamos a ver qué pasa con los parámetros:

Afortunadamente podemos usar el operador diamante para no tener que teclear el argumento de tipo. <sarcasmo>UFFFFFF gracias Java 7</sarcasmo>.

Solamente la segunda línea es válida, las otras dos dan error. Esto es porque el parámetro de   es un Cont invariante en B. Lo intuitivo hubiera sido que la tercera línea también funcionara, no? Así como podemos pasarle un C a la función  , pues deberíamos poder pasarle un   a  ... para lograr esto, debemos hacer covariante el parámetro de g:

Ahora sí, la primera llamada no compila porque estamos pasando un   y la función espera un  , o dicho de manera más entendible, un  .

Sin embargo, esto no es lo más común cuando se trata de parámetros. Si bien es de lo más normal y esperado que   pueda invocarse pasándole un C, porque a fin de cuentas un C es también un B, la verdad es que los generics se usan comúnmente para clases contenedoras, por ejemplo una lista. Por eso le puse   a la clase de ejemplo. Lo lógico sería poder usar un contenedor de C en donde se espera un contenedor de A, y que a un contenedor de A se le puedan meter elementos de tipo A o cualquier subtipo de A.

Si cambian el parámetro para que sea contravariante, entonces la tercera llamada será la que tenga un error:

Hay que tener cuidado aquí. Mi clase Cont es un contenedor inmutable: se crea con un elemento que ya no se puede reemplazar. Por lo tanto, Cont puede ser covariante, ya que si se crea un  , se puede usar en donde se espera un   sin ningún problema. Si hacemos el contenedor mutable, entonces tendrá que ser invariante, ya que de otra forma si se pasa un   a código que espera un   y se mete un A al contenedor, puede ocurrir un error (porque A no es C).

Por otro lado, se pueden manejar contenedores contravariantes cuando solamente se les pasan elementos como parámetros. Supongamos que queremos un método que pueda meter un elemento en una lista de A, B o C:

Solamente la primera llamada es válida, porque el parámetro de la función es invariante. Lo intuitivo para que funcionaran las otras dos llamadas, pues sería hacer el parámetro covariante:

Pero al hacer esto ahora el error está en el código dentro del método, y el mensaje es bastante confuso. Lo que significa el error es que tenemos una lista covariante, por lo que cualquier método que tenga como valor de retorno el parámetro de tipo, se puede invocar sin problemas, pero no se pueden invocar los métodos que esperan argumentos de ese tipo.

Lo que realmente hay que hacer, es definir el parámetro como contravariante:

La definición del parámetro se puede interpretar como "Una lista de C o cualquier supertipo de C". Y ahora las tres invocaciones son válidas: el método puede meter un C en una lista de A, sin ningún problema.

Un ejemplo un poco más completo:

Tenemos una lista invariante en B, que podemos llenar con nuestro método, porque el método espera listas de C o un supertipo de C. Y luego podemos asignar esa lista a otra variable que es una lista de A o un subtipo de A. Si sacamos el primer elemento de listA, obtenemos un C, que es un subtipo de A. La seguridad de tipos no se ha roto en ningún momento.

Bueno pues espero que esto aclare un poco estos conceptos de varianza, covarianza y sobre todo, contravarianza.

Ya otro día les muestro cómo se hace todo esto en Ceylon. Hay diferencias importantes, como poder definir la varianza en donde se declaran los parámetros de tipo, pero también se puede definir en donde se usan.