¿Monótate es el buen primo del malvado Singleton?

Question

Singleton es definitivamente uno de los patrones más mal utilizados y abusados ​​que hay. Muchos de nosotros hemos sido infectados con Singletonitis en un momento u otro. Curiosamente, su primo cercano Monostate es menos famoso y menos utilizado. ¿Cuál es su opinión sobre Monostate? Bueno o simplemente como el mal? ¿Es una mejor alternativa al uso de Singleton? ¿Desanimarías también tu uso como lo harías con Singleton?

Answer 1

¿qué tal no usar patrones simplemente porque?

actualización: el abuso de singleton se produce porque las personas agregan el patrón sin justificación. A menudo agrega restricción arbitraria a ningún beneficio. usar monostate sin justificación es tal vez menos dañino, pero no más justificado. si el universo no colapsará si hay más de una instancia, entonces no lo aplique con un patrón, solo cree una sola instancia.

Answer 2

¿Por qué supones que la gente desalentaría el uso de Singletons? Hacer amplias generalizaciones sobre Singletons es como hacer generalizaciones generales sobre gotos, variables globales, etc. Hay un lugar para todos ellos. Ninguna de estas cosas es "mala", y su mal uso no las hace malas para usar, solo significa que deben usarse correctamente.

Answer 3

El acuerdo con Monostate es que necesita saber menos acerca de la implementación del objeto para poder usarlo. En otras palabras, guarda unas pocas teclas porque no tiene que llamar al método getInstance de los objetos (Singleton s = Singleton :: getInstance; s.Method();) para obtener una referencia al objeto, simplemente usa construcciones de lenguaje normal (Monostate ms; ms.Method();). Una fina línea de hecho.

Cada construcción de lenguaje de programación se puede etiquetar como mal porque se puede abusar de cada contrato de lenguaje de programación.

Cuando se usa razonablemente, no veo que ninguno sea "malo" o "bueno".

Answer 4

El mayor problema que tengo con Monostate es que puede causar confusión entre quienes lo usan. En términos generales, si crea una nueva instancia de un objeto, espera que sea solo eso, una nueva instancia, con su propio estado y ciclo de vida. Generalmente considero que los comportamientos inesperados son algo malo, por lo que prefiero el singleton, solo porque sabes lo que obtienes cuando lo usas.

En cuanto a si cualquiera de los patrones es malo o no, los singleton tienden a ser mal utilizados, pero también lo hacen todos los otros patrones, declaraciones de cambio, para bucles, o cualquier otra cosa que quieras mencionar.

Answer 5

Aquí hay un extracto de la página 127 de Patrones de diseño: Elementos del software reutilizable orientado a objetos por Gamma, Helm, Johnson y Vlissides.

Uso del patrón Singleton cuando

• debe haber exactamente una instancia de una clase, y debe ser accesible a los clientes de un conocido punto de
• acceso cuando la única instancia debe ser extensible subclases, y los clientes deben ser capaces de utilizar una instancia prolongado sin modificar su código

¿realmente hace únicos malos sólo porque se usan mal y mal entendido?

Answer 6

De acuerdo con esta definición de Monostates, es esta nota:

"Monostates son malos de la misma manera que SingletonsAreEvil."

No estoy necesariamente de acuerdo. La premisa básica es que Singletons y Monostates son variables globales, y dado que los Globals son malvados, también deben ser Singletons y Monostates.

El problema con esta línea de razonamiento es que no tiene en cuenta POR QUÉ los globales son malvados. Los globales son malvados principalmente porque son variables a las que se puede acceder fuera del alcance local accidentalmente, de forma similar a cómo los lenguajes no tipados a menudo permiten que las variables se creen simplemente haciendo referencia a ellas.

Singletons y Monostates no pueden causar los mismos tipos de problemas, porque es prácticamente imposible hacer referencia "accidentalmente" a un método estático global, llamar a su método de instancia y luego utilizar la instancia.

En otras palabras, los globales son malvados porque causan problemas sutiles y difíciles de ver. Singletons y Monostates no causan los mismos tipos de problemas, así que no los veo como malvados por las mismas razones, que es donde la mayoría de las personas parecen equivocarse en este argumento.

Ahora, ¿pueden los singletons y los monostatos causar otros tipos de problemas? Por supuesto. Aparentemente, la gente de TDD los odia porque son difíciles de probar correctamente con las pruebas automatizadas. Ok, está bien, pero para aquellas personas que no usan TDD, esos problemas no existen.

Por supuesto, los singletons pueden ser mal utilizados. Las personas que los usan simplemente para evitar pasar una instancia están abusando de ellos. Creo que Monostates es mejor para eso que un singleton.

Muchas personas proponen patrones de fábrica en lugar de singletons, pero creo que las fábricas son solo generadores de singleton de lujo. No, no hay un método estático de "instancia", pero básicamente hace lo mismo (cuando una fábrica crea un único objeto de instancia). Factory.Create no es diferente de Singleton.Instance.

EDIT:

Un aspecto de Singleton y Monostates que es comparable a Globals es que son compartidos, y por tanto no seguro para subprocesos. Si bien esto es una preocupación si planea hacer aplicaciones de subprocesos múltiples, si lo sabe puede tomar medidas para serializar el acceso a los objetos compartidos. Así que esta es probablemente la única área donde, generalmente, se puede pensar que los tres tipos causan problemas.

Answer 7

Um, monostate es Singleton ... por lo que tiene exactamente los mismos problemas.

• pruebas
• dependencias de ocultación
• inflexibles
• hilo de seguridad
• estado global hace que sea difícil garantizar la corrección

Answer 8

¿Qué hay de una clase con un solo ejemplo, pero sin mundial acceso:

public class SingleInstance 
{ 
    private static boolean exhausted = false; 

    public SingleInstance() 
    { 
     if (exhausted) 
     { 
      throw new IllegalStateException("only one instance allowed"); 
     } 
     exhausted = true; 

     [...] 
    } 

    [...] 
} 

Esto evita los problemas de Singleton y MonoState, mientras que impone y comunica claramente que solo hay una instancia.