ventajas significado pattern patron diseño desventajas codigo design-patterns static singleton

design-patterns - significado - ventajas y desventajas del patron de diseño singleton



¿Diferencia entre la clase estática y el patrón singleton? (30)

  1. Carga lenta
  2. Soporte de interfaces, para que se pueda proporcionar una implementación separada.
  3. Capacidad de devolver el tipo derivado (como una combinación de lazyloading y la implementación de la interfaz)

¿Qué diferencia real (es decir, práctica) existe entre una clase estática y un patrón singleton?

Ambos pueden invocarse sin instanciación, ambos proporcionan solo una "Instancia" y ninguno de ellos es seguro para subprocesos. ¿Hay alguna otra diferencia?

  1. Los objetos Singleton se almacenan en Heap , pero los objetos estáticos se almacenan en la pila .
  2. Podemos clonar (si el diseñador no lo rechazó) el objeto singleton, pero no podemos clonar el objeto de clase estática.
  3. Las clases Singleton siguen los OOP (principios orientados a objetos), las clases estáticas no.
  4. Podemos implementar una interface con una clase Singleton, pero los métodos estáticos de una clase (o, por ejemplo, una static class C #) no pueden.

  1. Podemos crear el objeto de la clase singleton y pasarlo al método.

  2. Singleton clase no tiene ninguna restricción de herencia.

  3. No podemos disponer los objetos de una clase estática, pero podemos singleton class.

¿Qué te hace decir que un método singleton o estático no es seguro para subprocesos? Por lo general, ambos deben implementarse para ser seguros para subprocesos.

La gran diferencia entre un singleton y un montón de métodos estáticos es que singletons puede implementar interfaces (o derivar de clases base útiles, aunque eso es menos común, en mi experiencia), por lo que puede pasar el singleton como si fuera "simplemente otro". "implementación.

Aquí hay un buen artículo: http://javarevisited.blogspot.com.au/2013/03/difference-between-singleton-pattern-vs-static-class-java.html

Clases estáticas

  • una clase que tiene todos los métodos estáticos .
  • Mejor rendimiento (los métodos estáticos están unidos en tiempo de compilación)

  • no se pueden anular los métodos, pero se puede usar la ocultación de métodos. ( ¿Qué está ocultando el método en Java? Incluso la explicación de JavaDoc es confusa )

    public class Animal { public static void foo() { System.out.println("Animal"); } } public class Cat extends Animal { public static void foo() { // hides Animal.foo() System.out.println("Cat"); } }

Semifallo

En resumen, solo usaría clases estáticas para mantener métodos util y usar Singleton para todo lo demás.

Ediciones

Bueno, un singleton es solo una clase normal que se crea una instancia, pero solo una vez e indirectamente desde el código del cliente. La clase estática no es instanciada. Que yo sepa, los métodos estáticos (la clase estática debe tener métodos estáticos) son más rápidos que los no estáticos.

Editar:
Descripción de la regla de rendimiento de FxCop: "Los métodos que no acceden a los datos de instancia o los métodos de instancia de llamada pueden marcarse como estáticos (Compartidos en VB). Después de hacerlo, el compilador emitirá sitios de llamadas no virtuales a estos miembros, lo que evitará una verificación en el tiempo de ejecución para cada llamada que asegure que el puntero del objeto actual no es nulo. Esto puede resultar en una ganancia de rendimiento mensurable para el código sensible al rendimiento. En algunos casos, el hecho de no tener acceso a la instancia del objeto actual representa un problema de corrección ".
Realmente no sé si esto se aplica también a los métodos estáticos en clases estáticas.

Cuando quiero una clase con funcionalidad completa, por ejemplo, hay muchos métodos y variables, uso singleton;

Si quiero una clase con solo uno o dos métodos, p. Ej., La clase MailService, que tiene solo un método SendMail (), uso una clase estática y un método.

Desde la perspectiva del cliente, el comportamiento estático es conocido por el cliente, pero el comportamiento de Singleton se puede completar oculto para un cliente. El cliente nunca puede saber que hay una sola instancia con la que está jugando una y otra vez.

El patrón Singleton tiene varias ventajas sobre las clases estáticas. Primero, un singleton puede extender clases e implementar interfaces, mientras que una clase estática no puede (puede extender clases, pero no hereda sus miembros de instancia). Un singleton se puede inicializar de forma perezosa o asincrónica, mientras que una clase estática generalmente se inicializa cuando se carga por primera vez, lo que lleva a posibles problemas en el cargador de clases. Sin embargo, la ventaja más importante, sin embargo, es que los singletons pueden manejarse de manera polimórfica sin forzar a sus usuarios a asumir que solo hay una instancia.

En el patrón de singleton puede crear el singleton como una instancia de un tipo derivado, no puede hacer eso con una clase estática.

Ejemplo rápido:

if( useD3D ) IRenderer::instance = new D3DRenderer else IRenderer::instance = new OpenGLRenderer

En muchos casos, estos dos no tienen una diferencia práctica, especialmente si la instancia de singleton nunca cambia o cambia muy lentamente, por ejemplo, manteniendo las configuraciones.

Yo diría que la mayor diferencia es que un singleton sigue siendo un Java Bean normal en oposición a una clase Java especializada solo estática. Y debido a esto, un singleton es aceptado en muchas más situaciones; De hecho, es la estrategia de creación de instancias predeterminada de Spring Framework. El consumidor puede o no saber que se está pasando un singleton, simplemente lo trata como un bean Java normal. Si los requisitos cambian y un singleton necesita convertirse en un prototipo en su lugar, como vemos a menudo en Spring, se puede hacer de manera totalmente transparente sin una línea de cambio de código para el consumidor.

Alguien más ha mencionado anteriormente que una clase estática debe ser puramente de procedimiento, por ejemplo, java.lang.Math. En mi opinión, una clase así nunca debería transmitirse y nunca deberían tener otra cosa que no sea la final estática como atributos. Para todo lo demás, use un singleton ya que es mucho más flexible y fácil de mantener.

En un artículo que escribí, describí mi punto de vista sobre por qué el singleton es mucho mejor que una clase estática:

  1. La clase estática no es en realidad una clase canónica, es un espacio de nombres con funciones y variables
  2. Usar una clase estática no es una buena práctica porque rompe los principios de programación orientados a objetos
  3. La clase estática no se puede pasar como un parámetro para otros
  4. La clase estática no es adecuada para la inicialización "perezosa"
  5. La inicialización y uso de la clase estática siempre es difícil
  6. Implementar la gestión de hilos es difícil

Estoy de acuerdo con esta definición:

La palabra " single " significa un solo objeto a lo largo del ciclo de vida de la aplicación, por lo que el alcance es a nivel de la aplicación.

La estática no tiene ningún puntero de objeto, por lo que el alcance está en el nivel de dominio de aplicación.

Además, ambos deben implementarse para ser seguros para subprocesos.

Puedes encontrar otras diferencias interesantes sobre: Singleton Pattern Versus Static Class.

La respuesta verdadera es de Jon Skeet, en otro foro aquí .

Un singleton permite el acceso a una única instancia creada: esa instancia (o, más bien, una referencia a esa instancia) puede pasarse como un parámetro a otros métodos y tratarse como un objeto normal.

Una clase estática permite solo métodos estáticos.

Las principales diferencias son:

  • Singleton tiene una instancia / objeto, mientras que la clase estática es un conjunto de métodos estáticos
  • Singleton puede extenderse, por ejemplo, a través de una interfaz, mientras que la clase estática no puede ser.
  • Singleton se puede heredar, lo que admite los principios de apertura / cierre en los principios de SOLID. Por otra parte, la clase estática no se puede heredar y debemos realizar cambios en sí mismos.
  • El objeto Singleton se puede pasar a los métodos mientras que la clase estática, ya que no tiene instancia, no se puede pasar como parámetros

Leí lo siguiente y creo que también tiene sentido:

Cuidar de los negocios

Recuerde, una de las reglas OO más importantes es que un objeto es responsable de sí mismo. Esto significa que los problemas relacionados con el ciclo de vida de una clase deben manejarse en la clase, no delegarse a construcciones de lenguaje como estática, etc.

del libro Proceso de pensamiento orientado a objetos, 4ª ed.

No soy un gran teórico de OO, pero por lo que sé, creo que la única característica de OO de la que carecen las clases estáticas en comparación con Singletons es el polimorfismo. Pero si no lo necesita, con una clase estática, por supuesto, puede tener herencia (no está seguro de la implementación de la interfaz) y encapsulación de datos y funciones.

El comentario de Morendil, "El estilo de diseño incorporado en una clase estática es puramente procedimental" Puede que esté equivocado, pero no estoy de acuerdo. En los métodos estáticos, puede acceder a miembros estáticos, que serían exactamente los mismos que los métodos singleton que acceden a sus miembros de instancia única.

editar:
De hecho, ahora estoy pensando que otra diferencia es que una clase estática se crea una instancia al inicio del programa * y vive a lo largo de toda la vida útil del programa, mientras que un singleton se crea una instancia explícita en algún momento y también se puede destruir.

* o se puede crear una instancia en el primer uso, según el idioma, creo.

Otra ventaja de un singleton es que se puede serializar fácilmente, lo que puede ser necesario si necesita guardar su estado en un disco o enviarlo a algún lugar de forma remota.

Para ampliar la respuesta de Jon Skeet

La gran diferencia entre un singleton y un montón de métodos estáticos es que singletons puede implementar interfaces (o derivar de clases base útiles, aunque es un IME menos común), por lo que puede pasar el singleton como si fuera "solo otra" implementación.

Es más fácil trabajar con Singletons cuando la unidad prueba una clase. Siempre que pase singletons como parámetro (constructores, configuradores o métodos), puede sustituir una versión simulada o aplastada del singleton.

Para ilustrar el punto de Jon, lo que se muestra a continuación no se puede hacer si Logger era una clase estática. La clase SomeClass espera que una instancia de la implementación de ILogger se pase a su constructor.

La clase Singleton es importante para que la inyección de dependencia sea posible.

using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ConsoleApplication2 { class Program { static void Main(string[] args) { var someClass = new SomeClass(Logger.GetLogger()); } } public class SomeClass { public SomeClass(ILogger MyLogger) { } } public class Logger : ILogger { private static Logger _logger; private Logger() { } public static Logger GetLogger() { if (_logger==null) { _logger = new Logger(); } return _logger; } public void Log() { } } public interface ILogger { void Log(); } }

Singleton es un mejor enfoque desde la perspectiva de la prueba. A diferencia de las clases estáticas, Singleton podría implementar interfaces y usted puede usar una instancia simulada e inyectarlas.

En el siguiente ejemplo ilustraré esto. Supongamos que tiene un método es GoodPrice () que utiliza un método getPrice () e implementa getPrice () como un método en un singleton.

Singleton que proporciona funcionalidad getPrice:

public class SupportedVersionSingelton { private static ICalculator instance = null; private SupportedVersionSingelton(){ } public static ICalculator getInstance(){ if(instance == null){ instance = new SupportedVersionSingelton(); } return instance; } @Override public int getPrice() { // calculate price logic here return 0; } }

Uso de getPrice:

public class Advisor { public boolean isGoodDeal(){ boolean isGoodDeal = false; ICalculator supportedVersion = SupportedVersionSingelton.getInstance(); int price = supportedVersion.getPrice(); // logic to determine if price is a good deal. if(price < 5){ isGoodDeal = true; } return isGoodDeal; } } In case you would like to test the method isGoodPrice , with mocking the getPrice() method you could do it by: Make your singleton implement an interface and inject it. public interface ICalculator { int getPrice(); }

Implementación final de Singleton:

public class SupportedVersionSingelton implements ICalculator { private static ICalculator instance = null; private SupportedVersionSingelton(){ } public static ICalculator getInstance(){ if(instance == null){ instance = new SupportedVersionSingelton(); } return instance; } @Override public int getPrice() { return 0; } // for testing purpose public static void setInstance(ICalculator mockObject){ if(instance != null ){ instance = mockObject; }

clase de prueba:

public class TestCalculation { class SupportedVersionDouble implements ICalculator{ @Override public int getPrice() { return 1; } } @Before public void setUp() throws Exception { ICalculator supportedVersionDouble = new SupportedVersionDouble(); SupportedVersionSingelton.setInstance(supportedVersionDouble); } @Test public void test() { Advisor advidor = new Advisor(); boolean isGoodDeal = advidor.isGoodDeal(); Assert.assertEquals(isGoodDeal, true); } }

En caso de que tomemos la alternativa de usar el método estático para implementar getPrice (), fue difícil obtener el simulado getPrice (). Podría simular la estática con el simulacro de potencia, pero no todos los productos podrían usarlo.

Singleton''s está instanciado, es solo que solo hay una instancia instanciada, de ahí el single en Singleton.

Una clase estática no puede ser instanciada por otra cosa que no sea ella misma.

Tenemos nuestro marco de base de datos que hace conexiones con Back-end. Para evitar lecturas sucias en múltiples usuarios, hemos utilizado el patrón de singleton para asegurarnos de que tenemos una instancia única disponible en cualquier momento.

En c # una clase estática no puede implementar una interfaz. Cuando una única clase de instancia necesita implementar una interfaz para contratos comerciales o IoC, aquí es donde uso el patrón Singleton sin una clase estática.

Singleton proporciona una manera de mantener el estado en escenarios sin estado

Espero que te ayude ..

Una clase estática es aquella que tiene solo métodos estáticos, para lo cual una palabra mejor sería "funciones". El estilo de diseño incorporado en una clase estática es puramente procedimental.

Singleton, por otro lado, es un patrón específico para el diseño OO. Es una instancia de un objeto (con todas las posibilidades inherentes a eso, como el polimorfismo), con un procedimiento de creación que garantiza que solo haya una instancia de ese rol en particular durante toda su vida.

Una diferencia notable es la diferenciación de instancias que viene con Singletons.

Con clases estáticas, el CLR lo crea y no tenemos control sobre él. con singletons, el objeto se crea una instancia en la primera instancia que se intenta acceder.

a. Serialización: los miembros estáticos pertenecen a la clase y, por lo tanto, no pueden ser serializados.

segundo. Aunque hemos hecho que el constructor sea privado, las variables miembro estáticas aún se llevarán a la subclase.

do. No podemos hacer una inicialización lenta, ya que todo se cargará solo al cargar la clase.

static clases static no deberían hacer nada, es útil para unir muchas funciones, es decir, Math (o Utils en proyectos). Entonces el nombre de la clase solo nos da una pista donde podemos encontrar las funciones y no hay nada más.

Singleton es mi patrón favorito y lo usa para administrar algo en un solo punto. Es más flexible que las clases static y puede mantener el estado. Puede implementar interfaces, heredar de otras clases y permitir la herencia.

Mi regla para elegir entre static y singleton :

Si hay un montón de funciones deben mantenerse juntas, entonces static es la elección. Cualquier otra cosa que necesite acceso único a algunos recursos, podría implementarse singleton .

Clase estática: -

  1. No se puede crear la instancia de clase estática.

  2. Cargado automáticamente por el tiempo de ejecución de lenguaje común (CLR) de .NET Framework cuando se carga el programa o espacio de nombres que contiene la clase.

  3. La clase estática no puede tener constructor.

  4. No podemos pasar la clase estática al método.

  5. No podemos heredar la clase estática a otra clase estática en C #.

  6. Una clase que tiene todos los métodos estáticos.

  7. Mejor rendimiento (los métodos estáticos están vinculados en el tiempo de compilación)

Semifallo:-

  1. Puede crear una instancia del objeto y reutilizarlo.

  2. La instancia de Singleton se crea por primera vez cuando el usuario solicita.

  3. Singleton clase puede tener constructor.

  4. Puede crear el objeto de la clase singleton y pasarlo al método.

  5. Singleton clase no dice ninguna restricción de herencia.

  6. Podemos disponer los objetos de una clase singleton pero no de la clase estática.

  7. Los métodos pueden ser anulados.

  8. Puede cargarse de forma lenta cuando sea necesario (las clases estáticas siempre se cargan)

  9. Podemos implementar la interfaz (la clase estática no puede implementar la interfaz).

Como entiendo la diferencia entre una clase estática y una clase Singleton no estática, la estática es simplemente un "tipo" sin instanciación en C #, donde el Singleton es un verdadero "objeto". En otras palabras, todos los miembros estáticos en una clase estática están asignados al tipo pero en Singleton están alojados debajo del objeto. Pero tenga en cuenta que una clase estática todavía se comporta como un tipo de referencia, ya que no es un tipo de valor como un Struct.

Eso significa que cuando crea un Singleton, ya que la clase en sí no es estática, pero su miembro sí, la ventaja es que el miembro estático dentro del Singleton que se refiere a sí mismo está conectado a un "objeto" real en lugar de un "tipo" hueco de sí mismo. Ese tipo de aclara ahora la diferencia entre un Singleton Estático y un No Estático más allá de sus otras características y el uso de la memoria, lo que es confuso para mí.

Ambos utilizan miembros estáticos que son copias individuales de un miembro, pero el Singleton envuelve al miembro al que se hace referencia en torno a un verdadero "objeto" instanciado cuya dirección existe además de su miembro estático. Ese objeto en sí tiene propiedades en las que se puede pasar y referenciar, agregando valor. La clase estática es solo un tipo, por lo que no existe, excepto para señalar a sus miembros estáticos. Ese tipo de concepto cimentó el propósito de Singleton vs Static Class más allá de la herencia y otros problemas.

Hay una gran diferencia entre una única instancia de clase estática (es decir, una única instancia de una clase, que es una variable global o estática) y un único puntero estático para una instancia de la clase en el montón:

Cuando su aplicación salga, se llamará al destructor de la instancia de clase estática. Eso significa que si usaste esa instancia estática como un singleton, tu singleton dejó de funcionar correctamente. Si todavía hay un código en ejecución que usa ese singleton, por ejemplo, en un hilo diferente, es probable que ese código falle.