¿Es apropiada una clase estática cuando el estado es inmutable?

Question

Digamos que tengo una clase simple llamada WebsterDictionary que tiene una función que puede tomar una palabra y devolver su definición. Quizás haya otra función que pueda tomar una definición y devolver una palabra. La clase es utilizada todo el tiempo por muchos clientes.

Para facilitar las búsquedas, la clase contiene una variable miembro que es un Diccionario en memoria que almacena las palabras y sus definiciones asociadas. Suponga que el Diccionario nunca puede cambiar una vez que se inicializa : es constante y no varía según las instancias.

¿Es este un buen candidato para la clase estática? He estado leyendo que las clases estáticas no deberían tener estado ... pero esta clase tiene estado (el diccionario en memoria) ¿verdad?

EDITAR: Además, si esto se convierte en una clase estática, ¿cuándo inicializo el Diccionario ya que ya no habría un constructor? ¿Verifico si la referencia al Diccionario es nula cada vez que se llama a uno de los métodos estáticos?

Gracias.

Answer 1

Una clase estática es adecuada cuando la funcionalidad no necesita ser reemplazable (por ejemplo, para pruebas). Si desea utilizar un código auxiliar o un simulacro, debe crear una interfaz adecuada y luego implementarla con un singleton.

Answer 2

Para ampliar las respuestas de otros, una clase estática o singleton es útil cuando necesita tener solo una instancia de una clase. Esto es mucho más fácil de lograr cuando los datos son inmutables. Por lo tanto, existe la posibilidad de que una clase estática sea lo que desea usar para esto. Pero no es necesariamente el caso de que sea automáticamente lo que desea usar.

Mi consejo es que te hagas una pregunta: ¿se derrumbará el mundo si creo más de uno de estos objetos? Si es así, use una clase singleton o estática. De lo contrario, use una clase regular.

Answer 3

Una clase estática puede ser lo que quieres aquí (ver otras respuestas). Pero no cometa el error de llamar a su diccionario "inmutable".

Inmutable no significa "nunca puede cambiar en tiempo de ejecución" en el sentido de que usaste la frase , porque tu Diccionario realmente cambia en tiempo de ejecución; después de crearlo, también debe agregar los elementos. Incluso en este punto, puede intentar que nunca vuelva a cambiar, pero es posible cambiarlo. Su intención no se aplica en ninguna parte.

Un verdadero objeto inmutable no puede cambiar después de la creación, sin importar cuánto lo intente. En cambio, cuando necesita una variación del objeto, debe crear una nueva instancia con los atributos deseados.

Puede pensar que una clase estática en un sentido tiene exactamente una instancia. Probablemente esa no sea la mejor opción para un patrón en el que dependas de crear nuevas instancias para cada cambio de estado.

Answer 4

Puedes ir a Singleton o a una clase estática. Probablemente iría con un Singleton, pero creo que es principalmente un problema de preferencia en esta situación particular.

Answer 5

Una clase estática es apropiada cuando solo una '' instancia '' debería existir alguna vez, en cuyo caso el patrón Singleton puede o no ser más apropiado (dependiendo de los detalles). Para un objeto inmutable del que necesitará múltiples instancias, por supuesto, una clase estática es inapropiada.

Answer 6

¿Lo que estás buscando podría ser Singleton?

No es necesario que la clase estática no necesite tener estado (puede tener miembros estáticos como parte de ella, que pueden ser parte de su estado).

Answer 7

Suena como si estuvieras describiendo el Patrón de monoestado : desea que todos compartan el mismo WebsterDictionary . Sucede que el WebsterDictionary también es inmutable, pero eso es una preocupación ortogonal: simplemente imposibilite la actualización (por ejemplo, utilizando un contenedor de solo lectura).

Answer 8

Como dijiste, la clase tiene alguna forma de estado global, incluso si es de solo lectura. Seguir el enfoque Singleton deja muy claro que contiene datos.

Si usa la inyección de dependencia, puede hacer que inyecte instancias singleton, en lugar de hacer que todas las clases tengan un código que le proporcione la instancia. Esto significa que las otras clases no estarán vinculadas al enfoque Singleton, y si puede reemplazarlo más fácilmente durante la prueba (combinado con una interfaz para habilitar el reemplazo con simulacros de prueba).