Generando singletons

Question

Esto puede sonar como una idea extraña y todavía no lo he pensado bien.

Digamos que tiene una aplicación que termina requiriendo un cierto número de singleton para hacer algunas E/S, por ejemplo. Podrías escribir un singleton y básicamente reproducir el código tantas veces como sea necesario.

Sin embargo, como programadores se supone que tenemos que inventar soluciones que eviten la redundancia o la repetición de cualquier tipo. ¿Cuál sería la solución para hacer varias cosas que podrían actuar como singleton?

P.S: Esto es para un proyecto en el que no se puede usar un marco como Spring.

Answer 1

Usted podría introducir una abstracción de esta manera:

public abstract class Singleton<T> { 
    private T object; 

    public synchronized T get() { 
    if (object == null) { 
     object = create(); 
    } 
    return object; 
    } 

    protected abstract T create(); 
} 

Luego, para cada producto único, sólo tiene que escribir esto:

public final Singleton<Database> database = new Singleton<Database>() { 
    @Override 
    protected Database create() { 
    // connect to the database, return the Database instance 
    } 
}; 

public final Singleton<LogCluster> logs = new Singleton<LogCluster>() { 
    ... 

continuación, puede utilizar los únicos escribiendo database.get(). Si el singleton no se ha creado, se crea y se inicializa.

La razón la gente probablemente no hacen esto, y prefieren simplemente repetidamente escribir algo como esto:

private Database database; 

public synchronized Database getDatabase() { 
    if (database == null) { 
    // connect to the database, assign the database field 
    } 
    return database; 
} 

private LogCluster logs; 

public synchronized LogCluster getLogs() { 
    ... 

se debe a que, al final, es sólo una más línea de código para cada producto único, y la probabilidad de que el patrón de inicialización de singleton sea incorrecto es bastante baja.

Answer 2

¿Qué tal pasar un parámetro a la función que crea el singleton (por ejemplo, su nombre o especialización), que sepa crear un singleton para cada parámetro único?

Answer 3

Existe un patrón multiton. De todos modos, estoy 60% seguro de que la solución real al problema original es un RDBMS.

Answer 4

Sé que preguntó acerca de Java, pero aquí es una solución en PHP como un ejemplo:

abstract class Singleton 
{ 
    protected function __construct() 
    { 
    } 

    final public static function getInstance() 
    { 
     static $instances = array(); 

     $calledClass = get_called_class(); 

     if (!isset($instances[$calledClass])) 
     { 
      $instances[$calledClass] = new $calledClass(); 
     } 

     return $instances[$calledClass]; 
    } 

    final private function __clone() 
    { 
    } 
} 

A continuación, que acaba de escribir:

class Database extends Singleton {} 

Answer 5

Sin embargo, como programadores estamos se supone que debe aportar soluciones ingeniosas que eviten la redundancia o la repetición de cualquier tipo.

Eso no es correcto. Como programadores, se supone que debemos encontrar soluciones que cumplan con los siguientes criterios:

• cumplen con los requisitos funcionales; p.ej. realizar según lo requerido sin errores,
• se entregan dentro del plazo obligatorio,
• son mantenibles; p.ej. el siguiente desarrollador puede leer y modificar el código,
• funciona lo suficientemente rápido para la tarea en cuestión, y
• pueden reutilizarse en tareas futuras.

(Estos criterios son más o menos clasificadas por prioridad decreciente, aunque diferentes contextos pueden dictar un orden diferente.)

inventiva no es un requisito, y "evitar [ing] redundancia o repetición de ningún tipo" tampoco lo es. De hecho, ambos pueden ser claramente dañinos ... si el programador ignora los criterios reales.

Llevando esto a su pregunta. Solo debe buscar formas alternativas de hacer singletons si realmente va a hacer que el código sea más fácil de mantener. Las soluciones "inventivas" complicadas bien pueden regresar a mordida usted (o las personas que tienen que mantener su código en el futuro), incluso si logran reducir el número de líneas de código repetido.

Y como otros han señalado (por ejemplo, @BalusC), el pensamiento actual es que el patrón singleton debería ser evitado en muchas clases de aplicación.

Answer 6

@BalusC tiene razón, pero lo diré con más fuerza, los Singleton son malvados en todos los contextos. Webapps, aplicaciones de escritorio, etc. Simplemente no lo hagas.

Todo un singleton es en realidad un fajo de datos global. La información global es mala. Hace las pruebas unitarias apropiadas imposibles. Hace que rastrear bichos raros sea mucho, mucho más difícil.

El libro de la Banda de los Cuatro es totalmente erróneo aquí. O al menos obsoleto por una década y media.

Si solo desea una instancia, tenga una fábrica que solo fabrique una. Es fácil.