El patrón arquitectónico singleton, es un modelo muy conocido de diseño de soluciones de software. Básicamente es conocido por ser un patrón de creación de instancias únicas para toda una aplicación software. Sin embargo, existen algunas advertencias en su uso que nos gustaría compartir contigo. A continuación, te presentarémos por qué el singleton es considerado un antipatrón de diseño.

1. Introducción

Singleton, como su nombre lo indica es un “solterón”, puesto a que es una instancia única y se mantiene fuera de ser parte de alguna colección de objetos.

Su creación principalmente está delegada a su propio constructor. En otras palabras, es una clase que se crea a sí misma. Y su papel es ampliamente conocido y popular al momento de definit utilidades en los proyectos, por ejemplo, el uso de loggers, funciones auxiliares como calculos o cifrado de cadenas, entre otras.

1. Diagrama de clases

1. Composición

El singleton consiste en lo siguiente:

• La instancia de sí mismo, final, estática, y privada.
• Un constructor privado, que sobreescribe el constructor por defecto, peviniendo su creación por otras clases.
• Una función de retorno de la instancia.

1. Implementación

public class MySingleton {
    private static final MySingleton INSTANCE = new MySingleton();

    private MySingleton (){}

    public MySingleton getInstance(){
        return INSTANCE;
    }
}

1. Uso

public class App {
    public static void main(String[] args){
        MySingleton singleton;
        singleton.getInstance();
    }
}

1. Ventajas

• Es un patrón simple de implementar.
• Poco costo de implementación.
• Facil acceso en cualquier punto del sistema.

1. Desventajas

El patrón singleton no es un patrón recomendado, hay multiples artículos que recomiendan que no se use, a continuación veremos las razónes por las cuales no debe ser usado.

• No es posible determinar en qué punto de una aplicación se llama el singleton, ergo, se crea instancia, lo que implica carencia de control de la creación de dicho singleton.
• El manejo de la información por lo general es inflexible. Por ejemplo, si se usa una unica instancia para llamados sin control como hilos o llamados http, no se puede determinar el estado del objeto facilmente, lo que implica que no se tiene control alguno de la información de los datos contenidos en la instancia.
• Si es necesario clonar un objeto, se pierde el objetivo de este patrón que es mantener una única instancia de objeto.
• Por todo lo anterior, singleton es un patrón muy dificil de realizar testing.

1. Cuando usarlo

Es posible implementarlo cuando un framework exige la creación de un objeto tipo sigleton para su administración (como es el caso de los beans en springboot), ya que se delega (tercerización) la administración del mismo.

En aplicaciones sin frameworks, es posible usarlos en programas donde no sea necesaria su concurrencia y no sean de gran tamaño.

1. Alternativas

El patrón de inyección de dependencias provee una forma ordenada y responsable de la creación de objetos a travéz de una aplicación. Puesto que provee una única manera de administrar los objetos creados necesarios, este patrón permite tener control de la creación de objetos y de la transmision de la información de forma más limpia.

1. Conclusiones

El patrón singleton debe ser usado con precaución y, de ser posible, es mejor hallar alternativas para su uso. Recomendamos fuertemente no usarlo puesto que hay mejores alternativas a su uso. De todas maneras es necesario considerar su uso en aplicaciones donde no sea imprescindible la concurrencia así como no sea necesario tener tan presente la creación de la instancia de singleton.

Si te gustó el contenido, y consideras aceptable el estar al tanto de las publicaciones, suscríbete a las redes sociales que administramos en el pie de página o registrate para recibir correos acerca de nuevos posts. Así también, si consideras que omitimos algo, o quieres que profundicemos en un tema específico, notifícanos en los comentarios.