Encapsulation d'un objet mutable dans un objet en lecture seule

Question

Je suis actuellement en train de mettre en œuvre des solveurs itératifs, qui fonctionnent en améliorant successivement l'estimation de la solution à un problème spécifique. Comme la solution est un ensemble de données plutôt important, le raffinement est effectué en place.

J'ai implémenté un simple pattern Observer/Observable afin de pouvoir observer l'algorithme pendant les itérations. En particulier, le solveur fournit une méthode

Foo getCurrentSolution() 

qui renvoie l'estimation actuelle de la solution. L'observateur est alors libre de faire quelques calculs, basés sur l'estimation actuelle (par exemple: décider si la solution est assez bonne et si les itérations peuvent être arrêtées). Foo est mutable, mais bien sûr, si l'observateur modifie l'estimation actuelle de la solution, cela peut ruiner les itérations du solveur.

Par conséquent, getCurrentSolution() devrait vraiment retourner une copie défensive. Mais cela nécessite du temps et de la mémoire sur les gros problèmes, donc je suis venu avec une autre idée, qui est getCurrentSolution() retourner un nouveau ReadOnlyFoo(bar), où foo est l'estimation actuelle (mutable) de la solution, privée au solveur. L'idée est que ReadOnlyFoo a presque la même interface que Foo, seules les méthodes qui pourraient modifier les données sont "désactivées" (elles lèvent une exception). Tous les détails de certaines classes factices sont donnés ci-dessous.

Ma question est la suivante: cette approche est-elle une bonne pratique? Y a-t-il un meilleur modèle?

Merci! Sébastien

public abstract class AbstractFoo{ 
    public abstract double getValue(); 

    public abstract void setValue(final double x); 

    public abstract AbstractFoo add(AbstractFoo bar); 

    public void addToSelf(AbstractFoo bar){ 
     setValue(getValue + bar.getValue()); 
    } 
} 

public class Foo extends AbstractFoo{ 
    private double value; 

    public Foo(final double x){ 
     value = x; 
    } 

    public double getValue(){ 
     return value; 
    } 

    public void setValue(final double x){ 
     value = x; 
    } 

    public AbstractFoo add(AbstractFoo bar){ 
     return new Foo(value + bar.getValue()); 
    } 
} 

public final class FooReadOnly extends AbstractFoo{ 
    private final Foo foo; 

    public FooReadOnly(AbstractFoo foo){ 
     this.foo = foo; 
    } 

    public double getValue(){ 
     return foo.getValue(); 
    } 

    public void setValue(final double x){ 
     throw new NotImplementedException("read only object"); 
    } 

    public AbstractFoo add(AbstractFoo bar){ 
     return foo.add(bar); 
    } 

    public void addToSelf(AbstractFoo bar){ 
     throw new NotImplementedException("read only object"); 
    } 
} 

Answer 1

Je définirais une interface Solution ne contenant que les méthodes de lecture seule, et une classe mutable MutableSolution contenant toutes les méthodes, et rendre la méthode getCurrentSolution() retourner une instance Solution. De cette façon, vous n'avez pas besoin de créer une copie défensive ou d'envelopper votre solution dans un wrapper en lecture seule.

Bien sûr, l'observateur pourrait encore lancer la solution à MutableSolution, mais ce ne serait pas un accident. Si vous souhaitez vous protéger contre les conversions, alors écrivez une classe wrapper ReadOnlySolution implémentant Solution et déléguant au MutableSolution enveloppé. Ceci est similaire à votre proposition, sauf que la signature de la méthode indique clairement que l'objet n'est pas modifiable.

Answer 2

C'est en fait l'approche que la classe Collections fait avec unmodifiableList(...) etc. Il retourne un emballage qui contient la liste originale mais jette des exceptions dans les méthodes qui modifient la collection.

Answer 3

Je ne ferais pas ça. Si on utilise AbstractFoo même d'une interface commune (qui pourrait exister dans votre implémentation réelle), alors il ne sait pas à l'avance si l'instance courante est mutable ou non. Ainsi, l'utilisateur risque de perdre des exceptions non vérifiées.

Et, pour un objet immuable, étant non modifiable, ce n'est pas exceptionnel du tout. En d'autres termes: je ne voudrais pas utiliser execption pour signaler, que l'on a tenté de modifier une instance de FooReadOnly.

Au moins j'ajouter une méthode abstraite boolean isModifiable() à la classe abstraite AbstractFoo afin que nous puissions tester, si nous pouvons modifier l'objet.Et dans ce cas, nous n'aurions pas besoin de lancer des exceptions - l'implémentation des méthodes de modification pourrait simplement ne rien faire.

Answer 4

Pourquoi une telle solution surdimensionnée? Pourquoi ne pas avoir un attribut de classe et readOnly booléen? Ensuite, vérifiez checkWriteable() pour chaque setter.