usar patron metodos metodo estaticos cuando conexion java design-patterns singleton

metodos - patron singleton java conexion



¿Por qué utilizar un singleton en lugar de métodos estáticos? (7)

Nunca he encontrado buenas respuestas a estas simples preguntas sobre las clases de ayuda / utilidad:

¿Por qué debería crear un singleton (sin estado) en lugar de usar métodos estáticos?

¿Por qué se necesitaría una instancia de objeto si un objeto no tiene estado?


En la mayoría de los lenguajes de programación, las clases eluden mucho al tipo de sistema. Mientras que una clase, con sus métodos y variables estáticos es un objeto, muy a menudo no puede implementar una interfaz o extender otras clases. Por esa razón, no se puede usar de forma polimórfica, ya que no puede ser el subtipo de otro tipo. Por ejemplo, si tiene una interfaz IFooable , que es requerida por varias firmas de métodos de otras clases, el objeto de clase StaticFoo no se puede usar en lugar de IFooable , mientras que FooSingleton.getInstance() puede (suponiendo que FooSingleton implemente IFooable ).

Tenga en cuenta que, como comenté la respuesta de Heinzi, un singleton es un patrón para controlar la creación de instancias. Reemplaza la new Class() con Class.getInstance() , lo que le da al autor de la Class más control sobre las instancias, que puede usar para evitar la creación de instancias innecesarias. El singleton es solo un caso muy especial del patrón de fábrica y debe tratarse como tal. El uso común hace que sea más bien el caso especial de los registros globales, que a menudo termina mal, porque los registros globales no se deben usar simplemente quiera o no.

Si planea proporcionar funciones de ayuda global, entonces los métodos estáticos funcionarán bien. La clase no actuará como clase, sino solo como un espacio de nombres. Sugiero que mantenga una alta cohesión o que termine con los problemas de acoplamiento más extraños.

greetz
back2dos


En realidad, he encontrado otra respuesta no mencionada aquí: los métodos estáticos son más difíciles de probar.

Parece que la mayoría de los frameworks de prueba funcionan bien para burlarse de los métodos de instancia, pero muchos de ellos no manejan de una manera decente la simulación de métodos estáticos.


Hay una disyuntiva entre usar cuál. Los singletons pueden o no tener estado y se refieren a objetos. Si no mantienen el estado y solo se utilizan para el acceso global, entonces la estática es mejor ya que estos métodos serán más rápidos. Pero si desea utilizar objetos y conceptos de OOP (polimorfismo de herencia), entonces singleton es mejor.

Considere un ejemplo: java.lang.Runtime es una clase singleton en java. Esta clase permite diferentes implementaciones para cada JVM. La implementación es única por JVM. Si esta clase hubiera sido estática, no podemos aprobar implementaciones diferentes basadas en JVM.

Encontré este enlace realmente útil: http://javarevisited.blogspot.com/2013/03/difference-between-singleton-pattern-vs-static-class-java.html ?

¡¡Espero eso ayude!!


Para mí "Want Object State use Singleton, Want Function use static method"

Depende de lo que quieras. Siempre que desee el estado del objeto (por ejemplo, polimorfismo como estado nulo en lugar de null o estado predeterminado), singleton es la elección adecuada para usted, mientras que el método estático se usa cuando necesita la función (recibir entradas y luego devolver una salida).

Recomiendo para el caso singleton, siempre debe ser el mismo estado después de que se crea una instancia. No debe ser clonable, ni recibir ningún valor para establecer en (excepto la configuración estática del archivo, por ejemplo , archivo de propiedades en java).

PD El rendimiento entre estos 2 es diferente en milisegundos, por lo que primero debe centrarse en Arquitectura .


Podría ver un caso para el uso de un singleton sin estado en lugar de una clase de métodos estáticos, a saber, para Dependency Injection .

Si tiene una clase auxiliar de funciones de utilidad que está utilizando directamente, crea una dependencia oculta; no tienes control sobre quién puede usarlo o dónde. Inyectar esa misma clase de ayuda a través de una instancia de singleton sin estado le permite controlar dónde y cómo se usa, y reemplazarlo / simularlo / etc. cuando lo necesite.

Al convertirlo en una instancia única, simplemente se asegura de que no está asignando más objetos del tipo que el necesario (ya que solo necesita uno).


Singleton no es apátrida, tiene el estado global.

Algunas de las razones por las que puedo pensar en usar Singleton son:

  • Para evitar fugas de memoria
  • Proporcionar el mismo estado para todos los módulos en una aplicación, p. Ej. Conexión de base de datos

Un singleton se usa para introducir algún tipo de estado global a una aplicación. Si no tiene estado, tampoco veo el sentido de usar un singleton, a menos que

  • esperas extenderlo con estado en el futuro previsible o
  • necesita una instancia de objeto por algún motivo técnico particular (por ejemplo, para la instrucción de lock C #, aunque esto ya es bastante descabellado) o
  • necesita herencia, es decir, desea poder reemplazar fácilmente su singleton con otra utilizando la misma interfaz pero con una implementación diferente. Por ejemplo, el método Toolkit.getDefaultToolkit() en Java devolverá un singleton cuyo tipo exacto depende del sistema.