¿Cómo se implementa el patrón de diseño Singleton en Visual Basic, qué se debe tener en cuenta para la seguridad en subprocesos y en qué se diferencia la implementación clásica de la variante perezosa (lazy)?

Respuesta.

El patrón Singleton garantiza que una clase tenga solo una instancia y proporciona un punto de acceso global a ella. En VB.NET, se suele usar un constructor privado y una propiedad estática para almacenar la única instancia:

Public Class Singleton
    Private Shared _instance As Singleton
    Private Sub New()
        ' Constructor privado
    End Sub
    Public Shared ReadOnly Property Instance() As Singleton
        Get
            If _instance Is Nothing Then
                _instance = New Singleton()
            End If
            Return _instance
        End Get
    End Property
End Class

Seguridad en subprocesos: En un entorno multihilo, es posible que se creen dos instancias cuando se accede simultáneamente. Solución: usar un bloqueo o la construcción Lazy(Of T):

' Implementación perezosa y segura para subprocesos
Public Class Singleton
    Private Shared ReadOnly _instance As New Lazy(Of Singleton)(Function() New Singleton())
    Private Sub New()
    End Sub
    Public Shared ReadOnly Property Instance() As Singleton
        Get
            Return _instance.Value
        End Get
    End Property
End Class

Diferencia:

• El Singleton clásico crea la instancia en el primer acceso, pero requiere sincronización manual.
• La variante "perezosa" utiliza mecanismos integrados de .NET para crear la instancia de manera segura para subprocesos.

Pregunta con trampa.

¿Por qué es peligroso este código para implementar Singleton?

Public Shared ReadOnly Property Instance() As Singleton
    Get
        If _instance Is Nothing Then
            _instance = New Singleton()
        End If
        Return _instance
    End Get
End Property

Respuesta: En un entorno multihilo, puede haber una situación en la que dos hilos vean simultáneamente que _instance es Nothing y ambos creen un objeto. Por lo tanto, este enfoque no es completamente seguro para subprocesos. Se recomienda usar Lazy(Of T) o SyncLock para bloqueo.

Ejemplos de errores reales debido a la falta de conocimiento de los matices del tema.

---

Historia

Sistema ERP: El logger Singleton al iniciarse desde servicios a veces se creaba dos veces, se perdían los logs. La razón fue la falta de sincronización en la propiedad, aunque la aplicación era multihilo.

---

Historia

Aplicación Windows Forms: En el proyecto se trasladó el trabajo con la base de datos a Singleton, pero no se implementó la inicialización perezosa. Al iniciar la aplicación, se producía una conexión pesada, ralentizando la carga de la UI para todos.

---

Historia

Plugin de plataforma periodística: Intentaron usar una variable estática en un módulo para Singleton, no protegida contra el acceso multihilo, como resultado en la fase de carga caliente aparecieron varias instancias del controlador de correo electrónico, lo que provocó correos duplicados.