clase mutable como hijo de una clase inmutable

Question

Quiero tener objetos inmutables de Java como esto (muy simplificada):

class Immutable { 

    protected String name; 

    public Immutable(String name) { 
     this.name = name; 
    } 

    public String getName() { 
     return name; 
    } 

} 

En algunos casos, el objeto no sólo debe ser legible, pero mutable, por lo que podría añadir mutabilidad través de la herencia:

public class Mutable extends Immutable { 

    public Mutable(String name) { 
     super(name); 
    } 

    public void setName(String name) { 
     super.name = name; 
    } 

} 

Si bien esto es técnicamente muy bien, me pregunto si se conforma con programación orientada a objetos y la herencia que mutable es también de tipo inmutable. Quiero evitar que el crimen de OOP arroje UnsupportedOperationException por objeto inmutable, como hace la API de colecciones de Java.

¿Qué opinas? ¿Alguna otra idea?

Answer 1

Evite llamar al padre "Inmutable" porque se convierte en una mentira en la clase secundaria - si do desea hacer que una clase sea inmutable, también debe ser definitiva para evitar exactamente este problema.

Joda Time usa "ReadableXXX" para dar la idea de que "esta clase solo proporciona acceso de lectura, otras subclases pueden ser mutables". No estoy seguro si me gusta esa idea, pero no puedo decir que haya visto muchas alternativas.

Básicamente el problema es con la expresión de un negativo - Immutable describe lo que puede no do (mutar ella) y que no se pueden aplicar con sensatez en las subclases. (Incluso si los campos dentro de Immutable fueran finales, no detendría a una subclase que tenga sus propios campos mutables.)

Answer 2

Las clases inmutables deben ser final precisamente para evitar subtipos mutables.

Permitir que un subtipo de una clase inmutable rompa el contrato inmutable hace que sea inútil que la clase sea inmutable en primer lugar. Puede ser legal en el sentido de que Java le permite hacerlo (la inmutabilidad no se aplica en el idioma) pero dicha clase no es verdaderamente inmutable, siempre que pueda ser subclasificado.

Esta es la razón por la cual String es final.

Answer 3

Me parece curioso su código.

Para implementar un comportamiento tan inmutable, preferiría haber confiado en una interfaz Immutable, proporcionando solo el método getter, mientras el objeto contenga ambos. De esta manera, las operaciones que dependen de los objetos inmutables habrían llamado a la interfaz, mientras que otras habrían llamado al objeto.

Y, si realmente no desea que sus objetos inmutables se conviertan en elementos mutables, puede usar proxies y todas las herramientas empresariales (aspectos, etc.). Pero generalmente, depender de la buena voluntad de otros desarrolladores es una manera dulce de hacerlos responsables de sus errores (como lanzar lo inmutable en mutable).

Answer 4

Su subclase es mala porque infringe el Liskov substitution principle. No lo hagas

Answer 5

Sugiero que debe tener una clase base heredable "ReadableFoo", una clase ImmutableFoo sellada derivada y otras clases MutableFoo derivadas. El código que no se preocupa si un Foo es mutable o no puede aceptar un ReadableFoo. El código que quiere un Foo que está garantizado que no cambia puede aceptar un ImmutableFoo. El código que puede necesitar cambiar un Foo puede aceptar un MutableFoo.

Tenga en cuenta que los constructores de ImmutableFoo y MutableFoo normalmente deberían aceptar un ReadableFoo. De esta forma, cualquier Foo será convertible a una versión mutable o inmutable.