Singleton
Un objeto único coordina acceso a un recurso y evita duplicar costos.
Qué problema resuelve
Cuando múltiples módulos crean sus propias instancias se duplican conexiones, se fragmenta la configuración y se rompen invariantes globales.
Por qué existe
Centralizar recursos compartidos
Es útil cuando un servicio, logger, caché o registro debe existir solo una vez para mantener consistencia y reducir consumo.
- Libera al resto del sistema de saber cómo se instancia
- Permite cachés o pools globales sin dependencias cíclicas
Analogía
Un control de acceso
Piénsalo como el switch general de un estudio: si cada quien instalara su propio switch podrías quemar el sistema.
Dónde NO usarlo
Cuando necesitas escalabilidad horizontal
Si tu aplicación requiere instancias aisladas por petición o pruebas paralelas, el Singleton introduce acoplamiento y estado global difícil de controlar.
- Evítalo en código que debería ser puro o fácilmente testeable
- Prefiere inyección de dependencias cuando puedas
Ventajas
- Elimina configuraciones duplicadas
- Simplifica el consumo de recursos compartidos
- Permite lazy loading del recurso
Desventajas
- Aumenta el acoplamiento global
- Dificulta las pruebas unitarias
- Puede convertirse en cuello de botella
Antes de implementarlo, evalúa si una fábrica o un contenedor de dependencias resuelve mejor el problema.
class Logger {
private static instance: Logger | null = null;
private constructor() {}
static getInstance() {
if (!Logger.instance) {
Logger.instance = new Logger();
}
return Logger.instance;
}
log(message: string) {
console.info(`[log] ${message}`);
}
}
export function useLogger() {
const logger = Logger.getInstance();
logger.log("Se emite un mensaje desde un Singleton");
}