¿Cuál es la diferencia entre un patrón de Singleton y una clase estática en Java?

Question

¿Cómo se diferencia un singleton de una clase con solo campos estáticos?

Answer 1

Casi cada vez que escribo una clase estática, termino deseando haberlo implementado como una clase no estática. Considere:

• Se puede extender una clase no estática. El polimorfismo puede ahorrar mucha repetición.
• Una clase no estática puede implementar una interfaz, que puede ser útil cuando desee separar la implementación de la API.

Debido a estos dos puntos, las clases no estáticas permiten escribir pruebas de unidades más confiables para los elementos que dependen de ellas, entre otras cosas.

Sin embargo, un patrón singleton está solo a medio paso de las clases estáticas. Usted tipo de obtiene estos beneficios, pero si accede a ellos directamente dentro de otras clases a través de `ClassName.Instance ', está creando un obstáculo para acceder a estos beneficios. Al igual que ph0enix señaló, es mucho mejor utilizar un patrón de inyección de dependencia. De esta forma, se puede decir a un marco DI que una clase en particular es (o no es) un singleton. Obtienes todos los beneficios de la burla, las pruebas unitarias, el polimorfismo y mucha más flexibilidad.

Answer 2

Al menos puede reemplazarlo más fácilmente por un simulacro o un talón para probar la unidad. Pero no soy un gran admirador de los singleton por exactamente la razón que estás describiendo: son variables globales disfrazadas.

Answer 3

Un singleton se puede inicializar perezosamente, por ejemplo.

Answer 4

Un singleton es una clase con solo una instancia, forzada. Esa clase puede tener estado (sí sé que las variables estáticas mantienen el estado), no todas las variables o métodos miembros deben ser estáticos.

Una variación sería un pequeño grupo de estos objetos, lo que sería imposible si todos los métodos fueran estáticos.

Answer 5

La diferencia es independiente del idioma. Singleton es por definición: "Asegúrese de que una clase tenga solo una instancia y proporcione un punto de acceso global a ella." Una clase llena de solo campos estáticos no es igual a singleton, pero tal vez en su escenario de uso brinden la misma funcionalidad. Pero como JRL dijo que la iniciación perezosa es una diferencia.

Answer 6

Una clase singleton tendrá una instancia que generalmente es una y solo una por cargador de clases. Por lo tanto, puede tener métodos regulares (no estáticos) y se pueden invocar en esa instancia particular.

Aunque es una clase con solo métodos estáticos, realmente no hay necesidad de crear una instancia (por esta razón, la mayoría de las personas/frameworks hacen que este tipo de clases de Util sean abstractas). Simplemente invocará los métodos en clase directamente.

Answer 7

Lo primero que se le viene a la mente es que si desea utilizar una clase con solo métodos y atributos estáticos en lugar de un singleton, tendrá que usar el inicializador estático para inicializar correctamente ciertos atributos. Ejemplo:

class NoSingleton { 
    static { 
    //initialize foo with something complex that can't be done otherwise 
    } 
    static private foo; 
} 

Esto se ejecutará en el tiempo de carga de la clase que probablemente no sea la que desea. Usted tiene más control sobre este shebang completo si lo implementa como singleton. Sin embargo, creo que usar singletons no es una buena idea en ningún caso.

Answer 8

NOTA: Los ejemplos están en C#, ya que eso es con lo que estoy más familiarizado, pero el concepto debería aplicarse a Java de la misma manera.

Ignorando el debate sobre cuándo es apropiado usar objetos Singleton, una diferencia principal que conozco es que un objeto Singleton tiene una instancia que puede pasar.

Si usa una clase estática, se conecta estrictamente a una implementación particular, y no hay forma de alterar su comportamiento en tiempo de ejecución.

Mal diseño usando clase estática:

public class MyClass 
{ 
    public void SomeMethod(string filename) 
    { 
     if (File.Exists(filename)) 
     // do something 
    } 
} 

Alternativamente, usted podría tener su constructor toma en una instancia de una interfaz en particular en su lugar. En producción, podría usar una implementación de Singleton de esa interfaz, pero en las pruebas unitarias, simplemente puede burlarse de la interfaz y alterar su comportamiento para satisfacer sus necesidades (haciendo que arroje alguna excepción oscura, por ejemplo).

public class MyClass 
{ 
    private IFileSystem m_fileSystem; 

    public MyClass(IFileSystem fileSystem) 
    { 
     m_fileSystem = fileSystem; 
    } 

    public void SomeMethod(string filename) 
    { 
     if (m_fileSystem.FileExists(filename)) 
     // do something 
    } 
} 

Esto no quiere decir que las clases estáticas son siempre malas, pero no es un gran candidato para cosas como sistemas de archivos, bases de datos, conexiones y otras dependencias de la capa inferior.

Answer 9

Una de las principales ventajas de los singleton es que puede implementar interfaces y heredar de otras clases. A veces tiene un grupo de singletons que proporcionan una funcionalidad similar en la que desea implementar una interfaz común, pero son responsables de un recurso diferente.

Answer 10

Singleton Class: Singleton Class es una clase de la cual solo existe una sola instancia por cargador de clases.

Helper Class (Clase con solo campos/métodos estáticos): No existe ninguna instancia de esta clase. Solo se puede acceder directamente a los campos y métodos como constantes o métodos auxiliares.

Estas pocas líneas de este blog lo describe muy bien:

En primer lugar el patrón Singleton es muy útil si desea crear una instancia de una clase. Para mi clase de asistente , realmente no queremos instanciar cualquier copia de la clase. La razón por la cual no se debe utilizar una clase Singleton se debe a que para esta clase ayudante no utilizamos ningún variables. La clase Singleton sería ser útil si contenía un conjunto de variables que que queríamos sólo un conjunto de y los métodos utilizados esos variables, pero en nuestra clase de ayuda que no utiliza ninguna variable aparte de las aprobadas en los (que hacemos final). Por esta razón no creo que queremos una instancia singleton porque no queremos ninguna variable y no queremos que nadie instantianting esta clase. Así que si no quieres que nadie crear instancias de la clase, que es normalmente si usted tiene algún tipo de ayudante/clase utils entonces utilizar el lo que llamo la clase estática, una clase con un constructor privada y sólo consiste en métodos estáticos sin ningún ninguna variable.

Answer 11

Vamos a resumir :)

La diferencia esencial es: La forma de existencia de un singleton es un objeto, no es estática. Esto condujo a las siguientes cosas:

• Singleton se puede ampliar. Estático no.
• La creación de Singleton puede no ser segura en caso de subprocesamiento si no se implementa correctamente. Estático no.
• Singleton se puede pasar como un objeto. Estático no.
• Singleton puede ser basura recolectada. Estático no.
• ¡Singleton es mejor que la clase estática!
• Más aquí, pero no me he dado cuenta todavía :)

Por último, pero no menos importante, cada vez que se va a poner en práctica un conjunto unitario, por favor considere que rediseñar su idea de no usar este objeto a Dios (créanme, tenderás a poner todas las cosas "interesantes" en esta clase) y usarás una clase normal llamada "Contexto" o algo así.

Answer 12

Creo que lo importante es 'objeto' en la programación orientada a objetos. Excepto en algunos casos, deberíamos restringirnos al uso de clases estáticas. Los casos son:

1. Cuando crear un objeto no tiene sentido. Me gusta los métodos de java.lang.Math. Podemos usar la clase como un objeto. Porque el comportamiento de Math métodos de clase no depende del estado de los objetos que se crearán en esta clase.
2. Códigos que deben utilizarse conjuntamente por más de un método de objeto, los códigos que no llegan a las variables del objeto y es probable que se cierre fuera puede ser métodos estáticos

Otra cosa importante es Singleton es extensible. Singleton se puede extender. En la clase Math, utilizando los métodos finales, se ha evitado la creación y extensión del objeto de esta clase. Lo mismo es cierto para la clase java.lang.System. Sin embargo, la clase Runtime es un único objeto, no un método estático. En este caso, puede anular los métodos de herencia de la clase Runtime para diferentes propósitos.

Puede retrasar la creación de un objeto Singleton hasta que sea necesario (carga lenta). Sin embargo, para las clases de métodos estáticos, no existe una condición. Si llega a cualquier miembro estático de la clase, la clase se cargará en la memoria.

Como resultado, el beneficio más básico para la clase de método estático es que no tiene que crear un objeto, pero cuando se utiliza incorrectamente, eliminará su código de orientado a objetos.