El patr\u00f3n Singleton es uno de los m\u00e1s conocidos del cat\u00e1logo de Gang of Four \u2014 y tambi\u00e9n uno de los m\u00e1s malentendidos. Bien usado, resuelve problemas reales. Mal usado, se convierte en un generador de bugs sutiles, acoplamiento oculto y tests imposibles de escribir.<\/p>\n\n\n\n
En este post vamos a ver c\u00f3mo implementarlo correctamente en C#, cu\u00e1ndo tiene sentido usarlo, y cu\u00e1ndo deber\u00edas elegir otra alternativa.<\/p>\n\n\n\n
El Singleton garantiza que una clase tenga una sola instancia<\/strong> durante toda la vida de la aplicaci\u00f3n, y provee un punto de acceso global a esa instancia. Pertenece a la familia de patrones creacionales.<\/p>\n\n\n\n El caso de uso cl\u00e1sico: configuraci\u00f3n de la aplicaci\u00f3n, conexiones a recursos costosos, loggers, o cualquier componente del que realmente necesit\u00e9s una \u00fanica instancia.<\/p>\n\n\n\n En C# moderno, la forma can\u00f3nica de implementar un Singleton thread-safe es con \u00bfPor qu\u00e9 Si alguien puede heredar de tu clase Singleton, puede crear instancias adicionales a trav\u00e9s de la clase derivada, rompiendo la garant\u00eda del patr\u00f3n. Para entender por qu\u00e9 Thread-safe gracias al garantismo del CLR para inicializadores est\u00e1ticos. Pero la instancia se crea al cargar el tipo, aunque nunca se use.<\/p>\n\n\n\n Funciona, pero es verboso, dif\u00edcil de leer y f\u00e1cil de romper si olvid\u00e1s el Cuando implement\u00e1s un Singleton, segu\u00ed un orden consistente dentro de la clase:<\/p>\n\n\n\n Documentar la decisi\u00f3n es parte de la buena organizaci\u00f3n. Un comentario explicando por qu\u00e9<\/em> elegiste Singleton (y no DI) le ahorra horas de confusi\u00f3n a quien lea el c\u00f3digo despu\u00e9s.<\/p>\n\n\n\n El mejor Singleton es el que no tiene estado mutable. Las operaciones son stateless y solo operan sobre lo que reciben como par\u00e1metro:<\/p>\n\n\n\n Esto crea dependencias ocultas entre distintas partes de la aplicaci\u00f3n. Si alguien modifica La alternativa:<\/strong> si necesit\u00e1s estado compartido, us\u00e1 DI con servicios scoped\/singleton declarados expl\u00edcitamente, o patrones como CQRS con un store centralizado.<\/p>\n\n\n\n En aplicaciones ASP.NET Core modernas, la recomendaci\u00f3n es clara: registr\u00e1 tus servicios como singleton en el contenedor de DI en lugar de implementar el patr\u00f3n manualmente<\/strong>.<\/p>\n\n\n\n \u00bfPor qu\u00e9 DI es mejor en este contexto?<\/strong><\/p>\n\n\n\n \u00bfCu\u00e1ndo s\u00ed tiene sentido el Singleton cl\u00e1sico (est\u00e1tico)?<\/strong><\/p>\n\n\n\n El mayor problema de los Singletons cl\u00e1sicos es la testeabilidad. Si tu c\u00f3digo hace Si aun as\u00ed necesit\u00e1s un Singleton testeable, expon\u00e9 una interfaz:<\/p>\n\n\n\n En ASP.NET Core, esto se maneja mejor con El Singleton tiene mala fama en parte merecida \u2014 pero generalmente porque se usa donde no corresponde. La receta para usarlo bien es simple:<\/p>\n\n\n\n El patr\u00f3n no es el problema. El problema es usarlo como caj\u00f3n de sastre para todo lo que quer\u00e9s que sea global.<\/p>\n\n\n\n \u00bfUs\u00e1s Singleton est\u00e1tico o prefer\u00eds DI en tus proyectos? Contame en los comentarios.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" C\u00f3mo implementar correctamente el patr\u00f3n Singleton en C# con Lazy
\n\n\n\nLa implementaci\u00f3n moderna: Lazy<T><\/h2>\n\n\n\n
Lazy<T><\/code>:<\/p>\n\n\n\npublic sealed class Singleton\n{\n private static readonly Lazy<Singleton> _instance =\n new Lazy<Singleton>(() => new Singleton());\n\n public static Singleton Instance => _instance.Value;\n\n private Singleton() { }\n\n public void DoSomething() { \/* ... *\/ }\n}<\/code><\/pre>\n\n\n\nLazy<T><\/code>?<\/strong><\/p>\n\n\n\nInstance<\/code> por primera vez. Si nunca se usa, nunca se instancia.<\/li>\u00bfPor qu\u00e9 sealed?<\/h3>\n\n\n\n
sealed<\/code> cierra esa puerta.<\/p>\n\n\n\n\/\/ ✅ Correcto\npublic sealed class Singleton { }\n\n\/\/ ❌ Evitar \u2014 heredable\npublic class Singleton { }<\/code><\/pre>\n\n\n\n
\n\n\n\nEvoluci\u00f3n hist\u00f3rica: los enfoques anteriores<\/h2>\n\n\n\n
Lazy<T><\/code> es la mejor opci\u00f3n hoy, vale repasar c\u00f3mo se implementaba antes:<\/p>\n\n\n\n1. Eager initialization (est\u00e1tico)<\/h3>\n\n\n\n
public sealed class Singleton\n{\n private static readonly Singleton _instance = new Singleton();\n public static Singleton Instance => _instance;\n private Singleton() { }\n}<\/code><\/pre>\n\n\n\n2. Double-checked locking manual<\/h3>\n\n\n\n
public sealed class Singleton\n{\n private static volatile Singleton? _instance;\n private static readonly object _lock = new object();\n\n public static Singleton Instance\n {\n get\n {\n if (_instance == null)\n {\n lock (_lock)\n {\n if (_instance == null)\n _instance = new Singleton();\n }\n }\n return _instance;\n }\n }\n\n private Singleton() { }\n}<\/code><\/pre>\n\n\n\nvolatile<\/code>. Hoy no hay raz\u00f3n para elegir este enfoque sobre Lazy<T><\/code><\/strong>.<\/p>\n\n\n\n
\n\n\n\nOrganizaci\u00f3n del c\u00f3digo: estructura recomendada<\/h2>\n\n\n\n
\/\/\/ <summary>\n\/\/\/ Singleton para configuraci\u00f3n de la aplicaci\u00f3n.\n\/\/\/ Usa Lazy<T> para thread safety autom\u00e1tico.\n\/\/\/ Consider\u00e1 DI como alternativa si necesit\u00e1s testeabilidad.\n\/\/\/ <\/summary>\npublic sealed class AppConfiguration\n{\n \/\/ 1. Instancia est\u00e1tica privada\n private static readonly Lazy<AppConfiguration> _instance =\n new Lazy<AppConfiguration>(() => new AppConfiguration());\n\n \/\/ 2. Acceso p\u00fablico est\u00e1tico\n public static AppConfiguration Instance => _instance.Value;\n\n \/\/ 3. Constructor privado\n private AppConfiguration()\n {\n LoadConfiguration();\n }\n\n \/\/ 4. Campos inmutables (si los necesit\u00e1s)\n private readonly string _connectionString;\n public string ConnectionString => _connectionString;\n\n \/\/ 5. M\u00e9todos p\u00fablicos\n public string GetSetting(string key) { \/* ... *\/ return string.Empty; }\n\n \/\/ 6. Helpers privados\n private void LoadConfiguration() { \/* leer appsettings, etc. *\/ }\n}<\/code><\/pre>\n\n\n\n
\n\n\n\nLas reglas de oro<\/h2>\n\n\n\n
✅ Hac\u00e9 esto: Singleton sin estado (o inmutable)<\/h3>\n\n\n\n
public sealed class MathHelper\n{\n private static readonly Lazy<MathHelper> _instance =\n new Lazy<MathHelper>(() => new MathHelper());\n\n public static MathHelper Instance => _instance.Value;\n private MathHelper() { }\n\n \/\/ Sin estado \u2014 solo l\u00f3gica pura\n public double CalcularDistancia(Point a, Point b) =>\n Math.Sqrt(Math.Pow(b.X - a.X, 2) + Math.Pow(b.Y - a.Y, 2));\n\n public double CalcularIVA(decimal monto, double porcentaje) =>\n (double)monto * porcentaje \/ 100;\n}<\/code><\/pre>\n\n\n\n❌ Evit\u00e1 esto: estado global mutable<\/h3>\n\n\n\n
\/\/ ❌ Anti-patr\u00f3n: estado global mutable\npublic sealed class AppState\n{\n private static readonly Lazy<AppState> _instance =\n new Lazy<AppState>(() => new AppState());\n\n public static AppState Instance => _instance.Value;\n\n public string? UsuarioActual { get; set; } \/\/ Estado mutable \u2014 problema\n public int ContadorSesiones { get; set; } \/\/ Estado mutable \u2014 problema\n}<\/code><\/pre>\n\n\n\nUsuarioActual<\/code> en un thread y otro lo lee, ten\u00e9s una race condition. Y en tests, el estado del test anterior contamina el siguiente.<\/p>\n\n\n\n
\n\n\n\nEl elefante en la habitaci\u00f3n: Singleton vs Dependency Injection<\/h2>\n\n\n\n
\/\/ En Program.cs\nbuilder.Services.AddSingleton<ILogger, AppLogger>();\nbuilder.Services.AddSingleton<ICacheService, MemoryCacheService>();\n\n\/\/ En tu servicio \u2014 inyectado, no accedido globalmente\npublic class PedidoService\n{\n private readonly ILogger _logger;\n private readonly ICacheService _cache;\n\n public PedidoService(ILogger logger, ICacheService cache)\n {\n _logger = logger;\n _cache = cache;\n }\n}<\/code><\/pre>\n\n\n\nILogger<\/code> en tests sin tocar el Singleton real.<\/li>
\n\n\n\nConsideraciones para tests<\/h2>\n\n\n\n
MiSingleton.Instance.HacerAlgo()<\/code>, no pod\u00e9s reemplazarlo con un mock en tests.<\/p>\n\n\n\npublic interface IAppLogger\n{\n void Log(string mensaje);\n void LogError(Exception ex, string contexto);\n}\n\npublic sealed class AppLogger : IAppLogger\n{\n private static readonly Lazy<AppLogger> _instance =\n new Lazy<AppLogger>(() => new AppLogger());\n\n public static IAppLogger Instance => _instance.Value;\n\n private AppLogger() { }\n\n public void Log(string mensaje) { \/* ... *\/ }\n public void LogError(Exception ex, string contexto) { \/* ... *\/ }\n}\n\n\/\/ En producci\u00f3n:\nAppLogger.Instance.Log(\"Pedido creado\");\n\n\/\/ En tests: pod\u00e9s mockear IAppLogger sin usar el Singleton real\nvar mockLogger = new Mock<IAppLogger>();<\/code><\/pre>\n\n\n\n
\n\n\n\nInicializaci\u00f3n asincr\u00f3nica: un caso especial<\/h2>\n\n\n\n
Lazy<T><\/code> no soporta constructores async. Si tu Singleton necesita inicializaci\u00f3n asincr\u00f3nica (por ejemplo, cargar datos de una base de datos), no lo hagas en el constructor. Us\u00e1 un m\u00e9todo de inicializaci\u00f3n expl\u00edcito:<\/p>\n\n\n\npublic sealed class DatabaseConfig\n{\n private static readonly Lazy<DatabaseConfig> _instance =\n new Lazy<DatabaseConfig>(() => new DatabaseConfig());\n\n public static DatabaseConfig Instance => _instance.Value;\n\n private string? _connectionString;\n private bool _initialized;\n\n private DatabaseConfig() { }\n\n \/\/ Inicializaci\u00f3n async separada\n public async Task InitializeAsync()\n {\n if (_initialized) return;\n _connectionString = await LoadFromSecretsManagerAsync();\n _initialized = true;\n }\n\n private async Task<string> LoadFromSecretsManagerAsync()\n {\n \/\/ Llamada async real\n await Task.Delay(100); \/\/ simulaci\u00f3n\n return \"Server=...;Database=...;\";\n }\n}\n\n\/\/ Uso:\nvar config = DatabaseConfig.Instance;\nawait config.InitializeAsync(); \/\/ Llamado expl\u00edcitamente al arranque<\/code><\/pre>\n\n\n\nIHostedService<\/code> o llamando al init en el startup pipeline.<\/p>\n\n\n\n
\n\n\n\nResumen: cu\u00e1ndo s\u00ed, cu\u00e1ndo no<\/h2>\n\n\n\n
Situaci\u00f3n<\/th> Recomendaci\u00f3n<\/th><\/tr><\/thead> App ASP.NET Core con DI<\/td> Us\u00e1 AddSingleton()<\/code> en el container<\/td><\/tr>Librer\u00eda de utilidades stateless<\/td> Singleton con Lazy<T><\/code> ✅<\/td><\/tr>Estado mutable compartido<\/td> Evit\u00e1 Singleton, busc\u00e1 otra soluci\u00f3n<\/td><\/tr> L\u00f3gica de negocio<\/td> Nunca Singleton \u2014 us\u00e1 DI<\/td><\/tr> Necesit\u00e1s testeabilidad<\/td> Expon\u00e9 interfaz o us\u00e1 DI<\/td><\/tr> Script\/herramienta sin DI<\/td> Singleton con Lazy<T><\/code> puede ser OK<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nConclusi\u00f3n<\/h2>\n\n\n\n
sealed<\/code> + constructor privado<\/strong> siempre.<\/li>Lazy<T><\/code><\/strong> para thread safety sin drama.<\/li>AddSingleton()<\/code> te da los mismos beneficios con mucha m\u00e1s flexibilidad.<\/li><\/ol>\n\n\n\n