Quiero reemplazar la clase (mutable)
class OldValue { private int value; public OldValue(int value) { this.value = value; } public int getValue() { return value; } public void setValue(int value) { this.value = value; } }con la clase inmutable
class NewValue { private final int value; public NewValue(int value) { this.value = value; } public int getValue() { return value; } /* no setter, obviously */ } En la mayoría de las partes del código, algo como newValue.set(777) puede ser reemplazado por newValue = new NewValue(777) . Sin embargo, hay algunas partes heredadas del código con algo como
class ManagementServiceProviderFacadeSingletonAbstractFactoryObserver { public void setTheValue(OldValue oldValue) { oldValue.setValue(555); } } class Data { private OldValue oldValue; public OldValue get() { return oldValue; } } class SomewhereElse { public void frobnicate(Data data, ManagementServiceProviderFacadeSingletonAbstractFactoryObserver x) { x.setTheValue(data.get()); } }Estas partes heredadas son muy difíciles de cambiar y nos gustaría adaptarlas lo menos posible. ¿Hay alguna manera de escribir algún tipo de método de establecimiento "malvado" que pueda usarse en el código heredado? Algo como
class EvilSetter { public static void evilSet(NewValue newValue, int x) { // temporarily make newValue.value both public and non-final, set it to x } }¿Hay alguna otra manera sin perder la inmutabilidad y elegancia del nuevo diseño?
Probablemente mantendría ambos tipos, dejaría el código heredado usando solo el tipo anterior y proporcionaría métodos de adaptador para convertir entre los dos.
public class LegacyValueAdapter { public static OldValue toOldValue(NewValue newValue) { return new OldValue(newValue.getValue); } public static NewValue toNewValue (OldValue oldValue) { return new NewValue(oldValue.getValue); } }Documente claramente que estos solo deben usarse para interactuar con el código heredado, márquelos como obsoletos según sea necesario. Esto claramente no es lo ideal, pero eso se aplica a toda la situación.
Si la clase es más complicada (por ejemplo, también tiene métodos con algún comportamiento no trivial), podría valer la pena implementar OldValue envolviendo una instancia de NewValue , pero en este caso simple, eso no proporcionará muchos beneficios.
Recomiendo enfáticamente contra cualquier reflejo-hacks, ya que invalidarían la mayoría de los beneficios de usar los tipos inmutables en primer lugar. No me dé un tipo que parezca inmutable, pero luego cambie el valor de alguna manera a escondidas, eso rompe las expectativas de los usuarios y oculta los riesgos para las condiciones de carrera.