¿Cómo puedo evitar/refactorizar los singletons malos en la práctica?

Question

Después de leer detenidamente los datos sobre singletons (el código huele, no el patrón) Me pregunto:

¿Cómo puedo refactorizar mi código para deshacerme de ellos?

A pesar de que casi todos aceptaron que los singletons malos son, bueno, malos, no pude encontrar ningún consejo práctico sobre cómo reemplazarlos. O es muy trivial o muy difícil.

Hay algunas maneras en que puedo pensar, pero todo parece inflar mi código tremendamente.

Por ejemplo, supongamos que tengo una clase "global" AppConfig que contiene información sobre la licencia del producto y describe las funciones disponibles para el usuario.

Lo que puedo pensar:

• crear una clase base común para todos y cada clase de mis proyectos, que contiene una instancia AppConfig. (MALO: Imposible para los casos en los que ya tiene una clase base, por ejemplo, formularios)
• Cree una interfaz común con un método setAppConfig.
• Crear una AppConfigFactory mundial que puede crear AppConfig instancias (BAD: Sólo cambia el problema a otra clase)
• pase la instancia como parámetro para cada método que lo necesita. (BAD: Código hinchazón)
• ...

¿Qué puedo hacer yo?

EDIT: Aclaración: He identificado un single simple malo en mi código. Ahora quiero refactorizar mi código para eliminarlo. Estoy pidiendo consejos e ideas generales sobre cómo lograr esto.

Answer 1

Usar inyección de dependencias e inversión de marco de control: esto puede requerir una refactorización significativa. Luego, usando la dependencia de constructor o propiedad, solicite el "singleton"; idealmente, no lo pide todo, ya que según el principio de Demeter, solo debe pedir lo que realmente necesita (en su caso, la licencia). información).

Intento distinguir entre Singleton (el antipattern que oculta las variables globales) y singleton (es decir, algo que solo necesita uno). Un singleton verdadero se crea una vez al comienzo del programa (o en su fábrica) y se pasa a los objetos que lo necesitan.

Answer 2

¿Qué tal si la clase tiene solo miembros estáticos? Al igual que, en lugar de esto (código C#):

class AppConfig 
{ 
    public static readonly AppConfig Instance; 

    private AppConfig() { } 
    static AppConfig() 
    { 
     Instance = new AppConfig(); 
    } 

    public string SomeConfigParam { get; set; } 
} 

hacer esto:

static class AppConfig 
{ 
    public static string SomeConfigParam { get; set; } 
} 

Singleton sólo tienen sentido si se necesita pasar la instancia alrededor - como parámetros a funciones o valores en una colección. System.DBNull en .NET es un buen ejemplo de singleton. Si se trata simplemente de un almacén global de datos al que todos deberían poder acceder, las clases estáticas hacen que el código sea más corto y simple.

Answer 3

Usted dice

Crear una AppConfigFactory mundial que puede crear instancias appconfig (malo: sólo desplaza el problema a otra clase)

En mi opinión, esto es, en realidad, no está mal del todo. La opinión del cliente es que le pide a un objeto de fábrica la configuración que debería usar. Lo hace no sabe que es un singleton! De un golpe, el singleton-ness queda encapsulado en la fábrica. [Pragmáticamente, la fábrica bien puede terminar como un Singleton, pero todo tiene que arrancar, ¿verdad?]

Ahora, si completa el acceso a fábrica usando técnicas de inyección de dependencias es un refinamiento, lo fundamental es que solo un objeto es cuidando la creación de estos objetos AppConfig, solo la fábrica sabe si hay uno o muchos.

Y eso me lleva a otra teoría de mascotas ... no existe el número 1, cuando comienzas parece un Singleton, luego la conplexidad crece, y encuentras un escenario donde parte de tu aplicación (para ejemplo) utiliza una configuración y otra parte utiliza una diferente (por ejemplo, en transición dinámica entre versiones). La fábrica puede ocultar esa complejidad.

Answer 4

Pase el AppConfig a través del método setAppConfig() o el constructor, si el objeto necesita la configuración de la aplicación a lo largo de su vida útil. Si la asociación entre el AppConfig global y el objeto es condicional (es decir, se requiere solo en ciertos métodos), páselo como un argumento adicional.