Immutable vs Mutable objects - Design

Question

I have a class that models LogicalExpressions. The leaves are classes that implement an interface IEvaluable, that has a method called Evaluate which returns a boolean as the result.

public class MyEvaluable : IEvaluable
{
    public bool Evaluate(Environment env)
    {

    }
}

Some of these evaluable objects need to do some heavy stuff to produce the result, like calling a web service for instance. And since a logical expression may have multiple such objects that are related, I would like to evaluate them all at once, doing one web service call for all of them instead of separate calls for each parameter.

So I've been thinking about a good way to design such a system and came up with 2 solutions:

1) Make my evaluable objects mutable.

public interface IBatchEvaluable
{
    void BatchEvaluate(object[] siblings, Common.Environment env);
    bool IsEvaluated { get; }
    bool EvaluationResult { get; }
}
public interface IBatchEvaluable<T> : IBatchEvaluable
{
    void BatchEvaluate<T>(T[] siblings, Common.Environment env);
}

So every object that is IBatchEvaluable will have a state. When I need to evaluate it I check if it's already been evaluated and do the batch evaluation if it's needed. The only con is that my objects will be mutable, and that's not really desirable.

2) Store evaluation data in the environment

I could keep the objects immutable, and move the IsEvaluated and EvaluationResult data in the environment. So each object would look in the environment first to see if it has already been evaluated and if so get the result from the environment, otherwise evaluate all the siblings in one go and put the data in the Environment.

This is also not very attractive, since the implementation of my objects will depend on outside data, doesn't seem to abide by OOP principles.

How should I go about this from an OOP perspective ? I am open to hearing other potential solutions to this.

Answer 1

And since a logical expression may have multiple such objects that are related, I would like to evaluate them all at once, doing one web service call for all of them instead of separate calls for each parameter.

So why don't you do that?

Going through and memoizing the results of the expressions isn't going to be ideal when you're making calls to web services and the such since they're invariably going to be non-pure calls. If you ask for the temperature now, the web service is going to give you a different result than it would an hour from now. By moving to this batching approach under the covers, you're changing the result of your computation invisibly from your user.

If your goal is to get all of the data and then operate on it, then do that. What you describe is MapReduce in a nutshell. Instead of having logical expressions on individual items, you would shift the design to having operations that work on sets. Then it becomes more natural to get the data as a batch and perform operations on that batch. You don't need to worry so much about if parts of the data have been loaded since it becomes clearer in the set operation world. And with a bunch of existing implementations, you can find resources to help, or perhaps find that you don't need to write the code at all because it already exists.

Answer 2

One approach you could go with is to use composition and the strategy pattern. This will not eliminate mutability it will address the concern about encapsulation that you point to at the end of your question. Basically add one more layer over your Evaluable. It will have a reference to another Evaluable which is either one that can be resolved, or a result. When your composite Evaulable is called, you get the result from the resolvable Evaluable and put it in a result object.

If you want to be completely agnostic, you can simply do this with every Evaluable regardless of whether it's already resolved. This will create a churn of new objects but that may not be an issue. If it is, you can add a method to the Evaluable to return the result as a Evaluable and the resolved result simply returns this