«Patrón singleton» revisited

Estoy leyendo un delicioso libro, «Effective Java», de Joshua Bloch, sobre buenas prácticas Java para programadores Java (el segundo capítulo, por ejemplo, empieza explicando cómo usar métodos de factoría estáticos y sus ventajas sobre los constructores típicos, para que os hagáis una idea…). El libro es una joya, de los que merece la pena leer junto a un buen café, tomando notas en los laterales, porque está cargadito de apuntes que reutilizarás en el futuro, seguro, al menos si programas en Java (sí, ya sé, «Java is evil», etc.. etc…. ) Enumera distintos ítems, (vamos a llamarles recetas), en las que indica cómo se hace tal cosa en Java y cómo se debería de hacer. En muchas ocasiones, las recetas están directamente relacionadas con patrones de diseño, soluciones a problemas comunes. En otras, con anti-patrones : soluciones que NO se deberían de adoptar ante problemas comunes.

Sólo un comentario más de presentación, extraído del prefacio, en palabras de James Gosling, el padre de Java: «I sure wish I had had this book ten years ago. Some might think that I don’t need any Java books, but I need this one.»

Bien, una vez hechas las introducciones, pasamos a la chicha. Uno de los puntos sobre el que ya hablamos en otro post de DiarioLinux trata sobre el patrón singleton. El caso es que Bloch recomienda seguir una plantilla para aplicar el patrón singleton diferente a la que recomienda el libro de Liskov (Program Development in Java). La recomendación (de Bloch) es la siguiente:


// Singleton with public final field
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public void leaveTheBuilding() { ... }
}
// como todo el mundo sabe "There's only one Elvis" :-)


Yo mismo recomendaba la plantilla de Liskov frente a la de Bloch… pero visto lo visto, y sabiendo que la recomendación de Liskov podría tener condiciones de carrera… ya no hay duda. Sin embargo, el propio Bloch indica que «un consumidor de ese código con suficientes privilegios podría invocar al constructor privado usando las capacidades de introspección de Java, con el método AccessibleObject.setAccessible», así que para evitar ese problema (hay que ser rebuscado de narices), recomienda esta otra forma:


// Singleton with static factory
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public static Elvis getInstance() { return INSTANCE; }
public void leaveTheBuilding() { ... }
}


que se parece muchísimo a la recomendación de Liskov, pero sin el problema de las condiciones de carrera.

Finalmente, llega la guinda. Bloch dice que todo lo anterior está muy bien y tal, pero que teniendo disponible Java 1.5 desde hace ya unos cuantos añitos, que nos podríamos simplificar todos un poco la vida mediante el uso de tipos enumerados (disponibles en Java desde la versión 1.5, o 5.0 para aquellos lectores más comercial-friendly):


// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}


«While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.» Amén 🙂

PD: buscando documentación sobre esto, me he encontrado casualmente con la receta que comento en un artículo de InformIT.