将可变对象封装为只读对象

Question

我目前正在实现迭代求解器，它通过连续改进对特定问题的解决方案的估计来工作。由于解决方案是一个相当大的数据集，因此进行了适当的细化。

我实现了一个简单的观察者/可观察模式，以便能够在迭代发生时观察算法。特别是，求解器提供了一种

Foo getCurrentSolution()

返回解的当前估计值的方法。然后观察者可以根据当前的估计自由地进行一些计算（例如：决定解决方案是否足够好并且可以停止迭代）。 Foo 是可变的，但是当然，如​​果观察者修改了解的当前估计，这可能会破坏求解器的迭代。

因此，getCurrentSolution() 确实应该返回一个防御性副本。但这需要时间和内存来解决大问题，所以我想出了另一个想法，那就是让 getCurrentSolution() 返回一个新的 ReadOnlyFoo(bar)，其中 >foo 是解的（可变的）当前估计，对求解器来说是私有的。这个想法是 ReadOnlyFoo 与 Foo 具有几乎相同的接口，只有可能修改数据的方法被“停用”（它们抛出异常）。下面给出了一些虚拟类的所有详细信息。

我的问题是：这种方法是好的做法吗？有更好的模式吗？

谢谢！ 塞巴斯蒂安

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

我将定义一个仅包含只读方法的接口 Solution 和一个包含所有方法的可变类 MutableSolution，并创建 getCurrentSolution() > 方法返回一个 Solution 实例。这样，您不需要创建防御性副本或将解决方案包装到只读包装器中。

当然，观察者仍然可以将解决方案转换为 MutableSolution，但这并非偶然。如果您想保护自己免受强制转换，请编写一个实现 Solution 的 ReadOnlySolution 包装类，并将其委托给包装的 MutableSolution。这与您的命题类似，只是方法的签名清楚地表明该对象是不可变的。

Answer 2

这实际上是 Collections 类使用 unmodifyingList(...) 等的方法。它返回一个包含原始列表的包装器，但在修改列表的方法中抛出异常。收藏。

Answer 3

我不会那样做。如果一个人甚至使用一个通用接口（可能存在于您的实际实现中）的 AbstractFoo ，那么他事先并不知道当前实例是否可变。因此，用户将面临抛出一些未经检查的异常的风险。

而且，对于一个不可变的对象来说，不可修改它一点也不例外。换句话说：我不会使用 execption 来表示试图修改 FooReadOnly 的实例。

至少我会向抽象类AbstractFoo添加一个抽象方法boolean isModabilible()，以便我们可以测试是否可以修改目的。在这种情况下，我们不需要抛出异常 - 修改方法的实现可以简单地什么都不做。

Answer 4

为什么要采用这种过度设计的解决方案？为什么不拥有一个类和 readOnly 布尔属性？然后为每个 setter 执行 checkWriteable() 。