martes 26 de enero de 2010

Patrones de diseo: Singleton

En este artculo vamos a ver uno de los patrones creacionales ms comunes, el Singleton. Este patrn garantiza que una clase slo tenga una instancia, y proporciona un punto de acceso global a ella. Este patrn se suele utilizar cuando una clase controla el acceso a un recurso fsico nico o cuando hay datos que deben estar disponibles para todos los objetos de la aplicacin. El patrn Singleton se implementa mediante una clase con un constructor privado. Existir un mtodo que crear una instancia del objeto llamando al constructor slo si todava no existe ninguna. Se pueden producir problemas en programas con mltiples hilos de ejecucin, si dos hilos de ejecucin intentan crear la instancia al mismo tiempo y sta no existe todava. Para que slo uno de ellos pueda crear el objeto se puede utilizar exclusin mutua (synchronized) en el mtodo de creacin de la clase que implementa el patrn. Habra que decir tambin que si existen varios cargadores de clases para la aplicacin puede existir una instancia de la clase en cada uno de ellos, aunque la instancia sea nica dentro de ese cargador. Una implementacin correcta del patrn Singleton en Java podra ser la siguiente, propuesta por el investigador Bill Pough:
public class Singleton { // Private constructor private Singleton() {} prevents instantiation from other classes

/** * SingletonHolder is loaded on the first execution of Singleton.getInstance() * or the first access to SingletonHolder.INSTANCE, not before. */ private static class SingletonHolder { private static final Singleton INSTANCE = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.INSTANCE; }

A pesar de que es ampliamente utilizado, existe una corriente contraria al uso de este patrn debido a los problemas que introduce. En esta pgina Scout Densmore expone los problemas que Brian Button achaca a los Singletons. A continuacin, hago una adaptacin de lo ah se dice:

Los Singletons normalmente se usan para proporcionar un puto de acceso global para un servicio. De esta forma no hace falta pasar una referencia a este servicio, lo que viene a ser como usar una variable global. Al final lo que ocurre

es que las dependencias de diseo permanecen ocultas dentro del cdigo y no son visibles al examinar las interfaces. Hace falta inspeccionar el cdigo para entender qu objetos estn usando las clases.

Los Singletons permiten limitar la creacin de los objetos. Esto es cierto, pero ahora se estn mezclando dos responsabilidades diferentes en la misma clase. Una clase no debera preocuparse de si es o no un Singleton, sino que slo debera preocuparse por sus responsabilidades de negocio. Para limitar la creacin de clases se deberan crear factoras u otros objetos que limiten la creacin. De esta forma, cada objeto mantendra una responsabilidad mejor definida.

Los Singletons promueven el acoplamiento fuerte entre clases. Un acoplamiento flojo entre clases permite sustituir implementaciones alternativas de las clases colaboradoras en las pruebas. Una mejor alternativa es modificar el diseo para pasar referencias a los objetos en las clases y mtodos, de forma que se reduzca el acoplamiento.

Los Singletons mantienen el estado hasta la finalizacin del programa. Este estado persistente es perjudicial para las pruebas unitarias, puesto que cada prueba debe ser independiente de las dems. Si esto no se cumple, podra llevar a situaciones donde las pruebas fallen donde no deben y a que se estn ocultando errores. Esto se puede evitar pasando referencias a objetos a las clases y mtodos.

Es por ello que parece un patrn de diseo a evitar dentro de lo posible.