El planteamiento de la historia: la humanidad se abastece de energía con fusión nuclear y obtiene el necesario Helio-3 de la superficie lunar (ya que en la Tierra es un elemento extraño). En la Luna hay una base operada por una sola persona, Sam, que está a punto de finalizar un contrato de tres años y así poder volver a casa. Su trabajo es resolver problemas puntuales con las “cosechadoras” de Helio-3 y cargar las bombonas del producto para enviarlas a la Tierra en una lanzadera. En los tres años sólo se ha comunicado en tiempo real con un robot no antropomórfico, GERTY, ya que las comunicaciones con la Tierra se hacen a través de un remoto satélite y la demora en la señal es tanta que se limita a enviar y recibir mensajes grabados en vídeo. Sam tiene una hija muy pequeña, que no llegó a ver nacer, y una esposa que le echa de menos.  La soledad hace estragos en Sam: empieza a tener visiones. Tras una salida con un vehículo lunar en la que experimenta alucinaciones, sufre un accidente y el vehículo queda inmovilizado. Cuando despierta en la base lunar se le informa de que puede haber sufrido lesiones cerebrales y debe seguir un proceso de rehabilitación. Sam cree haber oído a GERTY hablando en tiempo real con la Tierra sobre un accidente en la superficie lunar, así que decide saltarse la prohibición y salir para ver qué ha ocurrido. Y hasta aquí podemos contar sin empezar con los spoilers.

La ambientación, fantástica: deudora de pelis como “2001: Una odisea en el espacio”, “Naves silenciosas” o “Atmósfera Cero”. El tema de fondo, los problemas típicos de algunos cuentos de Stanislaw Lem o, especialmente, de Philip K. Dick: el problema de la identidad. ¿Qué es ser uno mismo? ¿Hasta qué punto podemos traicionarnos a nosotros mismos? Cuando llevaba un cuarto de peli pensaba que el argumento tiraría por Solaris (buenas pelis, tanto en la versión de Tarkovsky (1972) como en la de Soderbergh (2002)) o Esfera (mala peli de Barry Levinson (1998)). Pero no, la historia consigue tirar por un derrotero original.

La peli se toma en serio a sí misma. Nada de posmodernismo, nada de guiños al espectador, nada de “te cuento esto, pero tú y yo sabemos que es mentira”. Ya tenía ganas. Y para ser una peli del género “¡qué malas son las grandes empresas!”, no está nada mal. Quiero decir que muchas pelis de ese género se pierden al recrearse en ese tema para ganarse la complicidad del espectador, lo que resulta aburrido e insustancial. Esta emplea el asunto como parte de paisaje, pero sabe bien que la historia que interesa es otra. La empresa malvada propicia las condiciones para que surja un planteamiento ético interesante, pero que no se centra en la maldad de esa empresa, sino en asuntos muchos más jugosos.

Lo de las operaciones in situ por parte del “repo man”, pase, pero el tono entre farsa y peli de acción barata nunca acaba de encontrar un punto de equilibrio con lo que se quiere contar. Pero no es eso lo que más me disgustó: me pareció peor el descarado plagio de Minority Report. Veámos (cuidado, que hay spoilers): Tipo trabaja para un sistema moralmente impresentable, pero acepta lo que hay y tira adelante; tipo pasa de verdugo a víctima y es perseguido por sus antiguos compañeros; tipo llega a momento en el que ocurre algo malo y, a partir de entonces, todo sale a pedir de boca; tipo se sale con la suya milagrosamente y desmonta “el sistema” malvado. Hasta aquí, el paralelismo con  Minority Report es evidente. Pero la copia va más allá (ojo, que ahora sí que va un spoiler del copón). Desde el momento en que ocurre algo malo, todo sucede en la cabeza del protagonista. Lo que en Minority Report apenas se apunta, en Repo Men se subraya tanto que se pierde cualquier efecto sorpresa. Lo que en Minority Report se deja a la reflexión del espectador, en Repo Men se explicita hasta la nausea. Sí, también en Minority Report ocurre que cuando a Anderton (Tom Cruise) lo atrapan, entra en un mundo de sueños en el que es feliz. Lo dice Gideon, el guarda de la prisión, cuando mete a Anderton en el “ataúd”: “It’s actually kind of a rush. They say you have visions… that your life flashes before your eyes… that all your dreams come true.” El resto de la peli ocurre en la cabeza de Anderton, de ahí que todo se resuelva con situaciones inverosímiles y muy felizmente. Spielberg lo deja apuntado y no subraya que el final es un falso final. El espectador puede irse a casa con el falso final feliz como final real de la peli. Pero el espectador que cae en la cuenta, se lleva el final pesimista. No está mal. En Repo Men el final se anuncia desde la mitad del metraje (o un poco antes): tan pronto aparece un anuncio del producto “M.5 Neural Net” uno sabe exactamente qué va a pasar. Y pasa eso que se espera, claro. El metraje se hace entonces insufrible: ya sabes cómo acaba todo y sólo queda ver una sucesión de escenas violentas y gore sin demasiado interés (con su “homenaje” a la escena del martillo de Old Boy, de Chan-wook Park, incluido). Un rollo.

Los objetos inmutables tienen una ventaja: dos o más instancias con el mismo valor pueden compartir memoria. El ahorro no sólo es de memoria: también lo es de tiempo. La creación (y posterior destrucción) de los objetos cuesta tiempo. Las cadenas, por ejemplo, son objetos inmutables. Los literales de cadena que aparecen en nuestro programa reciben un tratamiento especial por el que se garantiza que dos cadenas idénticas se almacenen en memoria una sola vez. Las variables a las que asignamos ese literal de cadena son, pues, referencias a la misma zona de memoria. Es decir, este fragmento de código muestra el valor true por pantalla:

string a = "una cadena";
string b = "una cadena";
Console.WriteLine(object.ReferenceEquals(a, b));
System.Console.Read();

Bloch advierte contra el uso de bucles como éste:

for (int i = 0; i < 100; i++)
{
     String a = new String("una cadena");
}

En Java, el bucle crearía 100 instancias diferentes de “una cadena”. En C# no se puede cometer ese error porque el constructor String no está sobrecargado para aceptar una cadena como argumento.

C# ofrece una posibilidad que no encontramos en Java: la definición de structs. Un struct es un tipo valor y la memoria que consumen las variables de tipo valor es de pila, no del heap manejado (salvo cuando el tipo valor está “boxed”, claro está). Un nuevo tipo valor se define como una clase: con campos, propiedades, métodos, etc, pero tiene algunas restricciones y se ha de ir con cuidado con algún cambio semántico en operaciones como la asignación. Una restricción es que no se puede especializar la clase (no hay herencia). Y la asignación de un valor struct almacenado en una variable a otra variable hace una copia de memoria (y no es una simple copia de referencia). Lo mismo ocurre con el paso de tipos valor a funciones como argumento. Esto hace que resulte conveniente limitar los tipos valor a datos con menos de, digamos, una treintena de bytes. Un consejo es que, si se puede, los tipos valor se limiten a codificar valores inmutables. Eso simplifica la semántica de las operaciones. Si los struct se usan para representar objetos inmutables y su tamaño es poco, resultan muy eficientes: no se pide memoria manejada, lo que ahorra el consumo de memoria extra de las referencias que requieren los objetos convencionales, y reducen el tiempo necesario para la gestión de la memoria consumida. Al programa en Java echo de menos la posibilidad de usar tipos valor, especialmente en combinación con genéricos cuando implemento colecciones. Me duele ver el consumo de memoria que supone gestionar una lista de enteros, que en los genéricos de Java pasa por hacer boxing de cada dato. En C# se puede usar una lista de enteros “primitivos” (en la jerga de C# no son primitivos, sino tipos valor). Y se puede, también, definir un tipo valor propio que suministrar como tipo al instanciar una colección genérica. Pero me estoy alejando del tema central. Sigamos.

El resto de la entrada de Bloch se dedica a sugerir que los objetos de tamaño grande o construcción costosa que son de naturaleza “constante” y se crean cada vez que se llama a un método, se creen una sola vez como campos estáticos. La construcción e inicialización de esos objetos se podría hacer en un bloque de código marcado con static. C# permite hacer algo similar, pero con un constructor estático para la clase. Los constructores estáticos no tienen parámetros y se invocan con total garantía antes de que se instancia cualquier elemento de la clase.

Finalmente, Bloch sugiere evitar la construcción de esos objetos si no son absolutamente necesarios. Es decir, podría darse el caso de que construyésemos esos objetos para evitar que las llamadas a un método lo creen una y otra vez, pero que el método en cuestión no se llamara nunca al ejecutar un programa. La construcción del objeto estático hubiese resultado en una pérdida absurda de memoria y tiempo. C# nos auxiliaría aquí con el tipo de datos Lazy<T>.

Finalmente, el autor de Effective Java advierte del peligro que supone el autoboxing inadvertido de tipos primitivos. Puede tener un grave impacto en la eficiencia. El mismo peligro se tiene en C#. En cualquier caso, el peligro es algo menor en C# porque los tipos valor se pueden usar sin “boxing” en estructuras de datos genéricas. No ocurre lo mismo en Java.

Nuevamente C# ofrece una solución más elegante. Se declara la clase como estática y en paz: “public static class { …”. No hace falta declarar un constructor privado y se es explícito en la intención: la clase es estática, por lo que no es instanciable y sólo contiene métodos o datos estáticos.

Bloch propone en su libro el abandono de una práctica Java en favor de otra que sólo se ha hecho posible desde la aparición de Java 1.5.  El nuevo método pasa por usar tipos enumerados. Este es un campo en el que Java ofrece un modelo sustancialmente diferente del de C#. En C# los tipos enumerados son conjuntos de constantes de algún tipo entero (excepto char). En Java, el tipo enumerado define una clase nueva de la que las constantes son instancias de sólo lectura. Esa nueva clase puede contener campos y métodos, como cualquier otra clase. Implementar el singleton resulta sencillo: se define un tipo enumerado con un único valor, que será la instancia única. Bloch comenta que esa aproximación ofrece ventajas, como la adición gratuita de maquinaria de serialización y resistencia a ataques por reflexión. Pero hay algo que no me gusta si se sigue la propuesta al pie de la letra: la clase debe implementarse pensando en que sólo será usada como singleton. Se puede dar un rodeo y montar como tipo enumerado una clase con un campo de sólo lectura que sea, precisamente, de la clase que ofrece el verdadero servicio y que se diseñó sin seguir el patrón en cuestión. Pero la sintaxis se complicará al acceder a la instancia que nos interesa, ya que ahora será un campo de la instancia de tipo enumerado que ofrece el punto de entrada. Y un último problema, que a mi juicio no es menor: no tenemos control del proceso de instanciación. La instancia se inicializará cuando Java lo considere oportuno, y sospecho (no estoy seguro) de que esto ocurrirá al inicio del programa. Si el objeto único tiene un proceso de construcción pesado, puede que no deseemos que se construya hasta que se use efectivamente. De ese modo aligeramos el tiempo de arranque del programa y, si nadie hiciese un acceso al singleton, evitaríamos completamente su construcción.

C# 4.0 ofrece un nuevo tipo de datos genérico que parece apropiado para implementar los singleton: Lazy<T>. Si deseamos una instancia de tipo T, Lazy<T> se asegura de que sólo se instancie cuando se accede a ella por primera vez.

public class SingletonClass
{
    static Lazy<SingletonClass> Instance = new Lazy<SingletonClass>();

    public readonly int n = 1;
}

public class Clase
{
    public static void Main(string[] args)
    {
        System.Console.WriteLine(SingletonClass.Instance.Value.n);
        System.Console.Read();
    }
}

Si no gusta tener que acceder a través de Value, se puede dar un rodeo:

public class SingletonClass
{
    static Lazy<SingletonClass> instance = new Lazy<SingletoClass>();
    public static SingletonClass Instance { get { return instance.Value; } }

    public readonly int n = 1;
}

public class Clase
{
    public static void Main(string[] args)
    {
        System.Console.WriteLine(SingletonClass.Instance.n);
        System.Console.Read();
    }
}

No parece un gran avance: podíamos hacer algo parecido fijandoel tipo de instance a T e inicializándolo a null. La propiedad Instance, antes de devolver el valor de instance, miraría si instance es null y, de ser el caso, inicializaría instance.  Pero hay una ventaja adicional en el uso de Lazy<T>: si nuestro programa tiene hebras, Lazy<T> se asegura de que la instancia no se cree dos veces. Controlar esto a mano es pesado. Finalmente, con ciertas sobrecargas del constructor podemos controlar con qué método (una función anónima, por ejemplo) se construye la instancia, lo que permite, por ejemplo, recurrir a factorías en la inicialización del singleton o pasar al constructor parámetros.

Como apunta el libro de Bloch, los constructores con un elevado número de parámetros son problemáticos. Muchos de sus parámetros suelen tener valores por defecto. Cuando es el caso, resulta tedioso para el programador tener que suministrar explícitamente estos valores por defecto, así que el diseñador de la clase suele sobrecargar el constructor de la clase. Un ejemplo:

public class Clase
{
    public Clase(int par1, int par2)
    {
        ...
    }

    public Clase(int par1)
    {
        this(par1, 0);
    }
}

Todo un problema: el perfil de cada constructor debe ser diferente, y eso no siempre es posible. Pongamos por caso este constructor:

public class Clase
{
    public Clase(int par1, int par2, int par3)
    {
    }
}

Supongamos que par2 puede tomar 0 como valor por defecto y que par3 puede tomar 1 como valor defecto. Podemos definir estos constructores:

public class Clase
{
    public Clase(int par1, int par2, int par3)
    {
        ...
    }

    public Clase(int par1, int par2)
    {
        this(par1, par2, 1);
    }

    public Clase(int par1)
    {
        this(par1, 0);
    }
}

El usuario puede omitir el valor de par3 u omitir el valor de par2 y par3, pero no puede omitir sólo el valor de par2. Y hay una pega adicional: el valor por defecto se ha codificado en cuerpo del constructor, lo que dificulta la legibilidad.

C# 4.0 soluciona el problema con el uso de parámetros con valor por defecto y parámetros con nombre. En C# 4.0 codificaríamos un único constructor:

public class Clase
{
    public Clase(int par1, int par2=0, int par3=1)
    {
        ...
    }

Todas estas instanciaciones de objetos de la clase Clase son ahora legítimas:

var o1 = new Clase(1, 10, 20);
var o2 = new Clase(1, 10); //par 3 vale 1
var o3 = new Clase(1); // par2 vale 0 y par3 vale 1
var o4 = new Clase(1, par2: 2); // par2 vale 2 y par3 vale 1
var o5 = new Clase(1, par2: 2, par3: 4); // par2 vale 2 y par3 vale 4
var o6 = new Clase(1, par3: 4); // par2 vale 0 y par3 vale 4
var o7 = new Clase(1, par3: 4, par2: 10); // par2 vale 10 y par3 vale 4

Los parámetros con nombre no sólo son útiles para ahorrarnos sobrecargas de constructores. En cualquier método con más de, digamos, tres parámetros, poder dar nombre a los argumentos cuando se hace una invocación aumenta la legibilidad del código.

Los builder siguen resultando útiles en ciertos contextos, pero en muchos otros dejan de ser necesarios con esta característica de C# 4.0.

¡Ah! Una restricción: los valores por defecto deben ser evaluables en tiempo de compilación. Eso obliga a dar algún que otro rodeo cuando se quiere suministrar un valor por defecto calculado en tiempo de ejecución.

1. Puede usarse un nombre que indique el modo en que actúa la factoría, o partir de qué (tipos de) datos opera.
2. Pueden reciclar memoria (usar algún tipo de cache), ya que no están obligados a devolver una instancia nueva.
3. Pueden devolver instancias de subclasses de aquella de la que el método factoría estático forma parte.
4. Eliminan la verbosidad cuando se usan tipos genéricos. (En todo caso, esa reducción de verbosidad se beneficia del borrado –erasure- de tipos en que se apoya el sistema de genéricos de Java, y parece un poco chapucero (o, cuando menos, poco elegante).

Y entre las limitaciones tenemos:

1. Las clases sin constructores protegidos o públicos no pueden “subclasarse”, y a fin de cuentas la directriz propone suprimir estos tipos de constructor para promover los métodos factoría estáticos.
2. No destacan en la documentación suficientemente, es decir, son indistinguibles de otros métodos estáticos.

Las ventajas 1, 2 y 3 de Java también lo son de C#. Nada que objetar. Pero la cuarta ventaja es irrelevante en C#. La verbosidad suele reducirse gracias al mecanismo de inferencia de tipos accesible con la palabra reservada “var”.

C#, con su uso de las clausuras (funciones anónimas) lleva más lejos la idea del uso de métodos factoría. Gracias a ellas, no es necesario definirlas como métodos estáticos: podemos definirlas al vuelo allí donde sean necesarias. Si es menester pasar a un método una factoría que devuelve una cola circular a partir de su capacidad, podríamos usar como argumento una lambda función ad hoc:

void NecesitoConstruirUnaColaCircular(Func creaColaCircular)
{
    var colaCircular = creaColaCircular(100);
...
}
...
NecesitoConstruirUnaColaCircular(n => ColaCircular(n));

En el momento de invocar el método, definimos la factoría y la suministramos como argumento. El sistema permite reciclar una ColaCircular que ya tengamos:

var miCola = new ColaCircular(100);
// Llamada 1
NecesitoConstruirUnaColaCircular(n => miCola);
//Llamada 2
NecesitoConstruirUnaColaCircular(n => miCola);

Nótese que las dos llamadas usan la misma cola circular. Esto permite reducir las peticiones de memoria manejada.

El ejemplo que he puesto puede extenderse a funciones anónimas que devuelvan cualquier clase que implemente una interfaz, naturalmente, con lo que la factoría estática no tiene por qué depender de una clase. En Java no podemos hacer eso: el método estático deberá definirse en el cuerpos de una clase, nunca en el de una interfaz.

Esperemos que Java incorpore clausuras en la versión 7. Hoy no se entiende un lenguaje de programación que no las ofrezca.

Lo que me interesa es mantener apuntes sobre .NET y C#, aunque ya veremos cómo va evolucionando (o muriendo de inanición) esto.