Hace un tiempo, mientras programaba sobre un proyecto que no era mío, noté que en varias ocasiones la persona que lo había hecho declaraba interfaces utilizando “IMyInterface< out T >” o “IMyInterface< in T >“. Como era la primera vez que veía una declaración así, se me ocurrió investigar pero encontré muy pocos lugares en donde la explicación fuera realmente clara. Así que me puse a hacer pruebas, a investigar más a fondo y terminé entendiendo cuál era su funcionamiento. Debido a esos problemas, decidí escribir acerca de esto llamado: Covarianza y Contravarianza.

Antes de arrancar, para explicar esto voy a usar una aplicación de consola. Podemos usar cualquier compilador como Visual Studio, Rider, etc, o, lo que voy a usar, un compilador online COMO ESTE:

Empecemos con algunas pequeñas cosillas. Imaginemos un ejemplo básico de herencia. Una clase padre y dos hijas:

public class Animal
{
}

public class Cat : Animal
{
}

public class Dog : Animal
{
}

Ahora… Si yo tuviera una variable de tipo “Animal” podría guardar dentro de ella instancias de tipo “Animal“, “Gato” o “Perro” (o cualquier instancia de clase que herede de “Animal“). Algo tan simple como esto:

Animal myAnimal = new Cat();

Hasta el momento, nada complicado… Ahora… Empecemos con algo un toque más grande. Imaginemos que usamos a estos animales dentro de una interfaz, como valor genérico. Probemos en una aplicación de consola simple.

public class Program
{	
    public static void Main()
    {
        IMyInterface< Animal > myAnimal = new GenericAnimal< Cat >();
    }
}

public interface IMyInterface< T > { }

public class Animal { }
public class Cat : Animal { }
public class Dog : Animal { }
public class GenericAnimal< T > : IMyInterface< T >{}

Lo que vamos a notar es que el compilador va a tirarnos un error, diciéndo que no podemos convertir GenericAnimal< Cat > en IMyInterface< Cat >. Pero… Por qué? Si Cat hereda de Animal?

A simple vista pareciera que esto debería funcionar y que no tiene sentido que tire error. La realidad es que el compilador sabe que Cat hereda de Animal, el problema es que no le estamos asegurando que todo lo que hagamos dentro de IMyInterface con un T como Cat lo vamos a poder hacer con un T como Animal. Suena complicado, no? Vamos a explicarlo de otra manera. Imaginemos este otro escenario:

using System.Collections.Generic;

public class Program
{	
    public static void Main()
    {
        List< Animal > myAnimals = new List< Cat >();
    }
}

public interface IMyInterface< T > { }

public class Animal { }
public class Cat : Animal { }
public class Dog : Animal { }
public class GenericAnimal< T > : IMyInterface< T >{}

Noten que el compilador tira exactamente el mismo error. Por qué?… Básicamente… El compilador diría algo como:

Y yo podría responderle algo como:

A lo cual el compilador, muy cortésmente, respondería:

Entonces… Para evitar que el proyecto se rompa en tiempo de ejecución, el compilador prefiere evitarlo diciéndote “eso no se puede, cambialo o no compilo. Hum“. Viéndolo de esa manera, quizás el planteo del compilador tiene algo de razón y nos está previniendo de un posible error. Pero el problema del compilador pasa por la seguridad: el compilador no está seguro de que vayamos a hacer lo correcto. Pero… Qué pasa si se lo aseguramos?

Es acá donde entra todo este tema de la “covarianza” y “contravarianza“. Empecemos por el primer concepto:

Este concepto se refiere básicamente a avisarle que si meto un GATO (subclase), o un PERRO (subclase), dentro de una lista o cualquier cosa, cuyo valor genérico sea ANIMAL (clase base), todo lo que haga con ellos va a poder hacerse también con una animal, como por ejemplo, CAMINAR. O sea que el compilador sabe que jamás voy a hacer cosas como hacer ladrar a un gato.

Para hacerlo, tengo que declarar la interfaz de la siguiente manera:

public interface IMyInterface< out T >
{
}

Pero el compilador, que no es tonto, se previene también de esto. Por eso, no va a dejar que declares ninguna property o método, que RECIBA como parámetro al valor de tipo T. O sea… Dentro de esa interfaz sólo puedo SACAR COSAS (de ahí el “out“), pero no puedo INGRESAR nada. Si intentamos crear una property o método que intente METER un valor dentro de la clase, el compilador nos va a tirar un error, qué más o menos va a significar:

De esta manera, el compilador asume que todo lo que esté adentro de esa clase, usado como valor T, sin importar de qué tipo sea, asume que todas las acciones que vamos a realizar van a ser propias del tipo de dato T que hayamos escogido. Por ende, al accederlo nos puede recomendar tranquilamente variables y métodos propias del tipo de dato T, porque asume que va a ser ÚNICO. No es que yo le digo que va a ser de ANIMAL y después le termino metiendo animales diferentes. No. Asume que eso no lo vamos a hacer, por ende nos bloquea la posibilidad de que lo hagamos. Así que cuando accedamos al tipo T (en el caso de que sea ANIMAL), nos va a sugerir cosas propias de la clase ANIMAL, o del tipo de dato que hayamos escogido para el valor T. Es como si dijera: “No necesitas que te muestre otra cosa… Total… Todo lo que podes hacer con cualquier tipo de animal (o una subclase de T), lo vas a poder hacer con un animal genérico (clase base T).

Entonces… Sólo puedo OBTENER datos, pero no puedo AGREGAR o INGRESAR ninguno. A esto se le dice COVARIANZA. EJ:

public class Program
{	
    public static void Main()
    {
        IMyInterface< Animal > myAnimals = new GenericAnimal< Cat >();
    }
}

public interface IMyInterface< out T >{}

public class Animal { }
public class Cat : Animal { }
public class Dog : Animal { }
public class GenericAnimal< T > : IMyInterface< T >{}

Estos serían dos ejemplos de uso, uno correcto y uno incorrecto, como para que vean un uso:

El segundo bloque de código tiraría un error, avisando que estás usando T como una CONTRAVARIANTE, porque estamos intentando pasar un parámetro, cuando al mismo tiempo le ASEGURAMOS (con el out que pusimos en la interfaz), que no vamos a hacerlo. Pero… Qué es una CONTRAVARIANTE?

Si entendieron bien el uso de las COVARIANTES, entonces no hay mucho que decir de esto más que: “es lo mismo, pero al revés“. En este caso, le vamos a decir al compilador que yo podría necesitar crear una GenericAnimal con un valor T que sea Cat, pero que puedo meterle adentro otro tipo de animal, como un perro.

En otras palabras… Es como decirle al compilador:

Entonces… Básicamente le estoy diciendo que, por ejemplo, si yo hago que el valor T sea un Cat, y por alguna razón se me ocurre meter ahí adentro un perro u otro animal, no voy a hacer con ese perro (u ese otro animal), algo que no pueda hacer con el Cat. Para hacerlo, escribo lo siguiente:

public interface< in T > IMyInterface
{
}

Ahora… Si yo intento crear una función dentro de la interfaz, que devuelva el tipo T, el compilador tira un error, ya que con esto le digo que SOLAMENTE voy a meter cosas (animales, por ejemplo), pero no voy a querer exponerlos de ninguna manera, por ende, desde afuera no los voy a necesitar acceder. Y si declarara algo que DEVUELVE un valor T, el compilador tiraría un error, qué básicamente nos estaría diciéndo:

Si el compilador no nos tirara ese error, nosotros podríamos hacer algo como esto:

public class Program
{	
    public static void Main()
    {
        IMyInterface< Cat > myAnimals = new GenericAnimal< Animal >();
    }
}

public interface IMyInterface< in T >
{
    T Get();
}

public class Animal { }
public class Cat : Animal { }
public class Dog : Animal{ }

public class GenericAnimal< T > : IMyInterface< T >
{	
    public T Get()
    {
        return default(T);
    }
}

O sea que podríamos meter un perro y luego querer obtenerlo para que ladre, pero arriba le dijimos que el valor T era de gatos. Hacerlo implicaría que un gato podría ladrar. Por ende, el compilador se asegura de que no hagas eso, prohibiéndolo en tiempo de compilación directamente. A esto se lo llama CONTRAVARIANZA. Y se refiere a que sólo voy a ingresar cosas, pero jamás voy a intentar usarlas desde afuera.

Pasando todo en limpio quedaría así:

Para este último caso, garantizar por medio del operador in al programa que todo lo que vamos a hacer con un objeto lo vamos a poder hacer con cualquiera nos permite también a nosotros evitar, más que nada cuando trabajamos en grupo, que se ingresen a la clase objetos que podrían romper el esquema.