A pattern in code which I’ve noticed quite frequently lately is that of executing calculations in the constructor of an object and then storing the result in a field on the object.

From the small amount of experience I have playing around with functional languages I have come across the idea of lazy evaluation of functions quite frequently and I think it’s something that we can apply in object oriented languages as well.

When we store a value of a calculation in a field we are opening up the ability for that value to be changed before we use it.

We can certainly reduce/remove the chance of that happening by making fields read only or final but as Dhanji points out in his InfoQ article, if we are storing reference objects there is still a chance they could be mutated before we use them.

Even if we can manage to work our way around that problem I still feel that we increase the complexity of classes by having more fields as well as decreasing the readability of the code in the constructor since we now have all this extra information standing in our way when perhaps we don’t even care about it at all since it won’t be used until later on anyway.

I’m not sure if it’s a given but I never expect calculations to be done in the constructors of objects when I create them – at most I would expect the fields I pass in to be stored but any more than that is surprising and I think it’s good to avoid surprises if we can!

I don’t think the automated properties in C# 3.0 have really helped much and code like this is quite common:

Now when we look at the constructor we can see that ‘SomeObject’ depends on those 2 classes and when we want to see what a call to ‘Field1’ does we can see straight away instead of having to scroll back up to the constructor to check.

In this case I would still favour storing ‘Dependency1’ and then executing that calculation later although a law of demeter violation is more often than not staring us in the face and perhaps this isn’t the right class to be performing this calculation.

It definitely depends on what “Calculation1” actually does. If it always returns the same result it makes sense to save it in a field instead of doing the calculation thousands of times during the life of the app.

One point – if there is a calculation involved on a dependency object, fields are probably not the right vehicle anyway. Fields are perceived as “data buckets”, not “workhorses” and therefore programmers frequently use fields as loop invariants (e.g. list.Count) or tokens. Invoking a calculation (that, mind you, may potentially call into a remote service, since it all depends on the dependency object’s implementation) would become a major performance bottleneck.
A method would be a better alternative in this case.

There’s a nice combination of the two as well. Avoid the up front work of the constructor oriented approach, especially since it’s possible those values will never be needed, and the performance impact of repeating the same calculations over and over if that Property is used a lot and the value doesn’t change. Calculate it on demand but cache the value in a field, use a WeakReference if memory is a concern.

I have been misled by assuming a repeated calculation will take more time than storing a calculated value in a field. Memory is not uniformly speedy. Even if a calculation always returns the same value, it can be faster to repeat a calculation thousands of times rather than fetching it from memory. It depends on caching, CLR behaviour, memory layout and so many other factors that predicting it ahead of time is quite difficult.

At the same time, predictions of some accuracy can be made by looking at the amount of code involved. If a calculation is a whole class on its own with hundreds of lines, that could make sense to save in a field. If the calculation is only a handful of operations, like adding and multiplying two numbers, it may not make sense.

I try to strive for code that only expresses the functional goal. Afterwards, if necessary, optimizations like caching calculations in fields can be made.

In the specific example Mark is discussing, SomeObject is intended to be an adapter or aggregate that exposes several information sources to a consumer. It’s not intended to be an information holder for the information. And, there is already caching underneath the Dependency1 and Dependency2 classes, as they do abstract away some network calls.

In what way does storing the object increase the coupling? In both cases, SomeObject knows about Dependency1 and calls one of its methods. The difference is in when it is called, but not what is called.

There is some run-time relationship difference, since the reference to Dependency1 means it will be garbage collected sometime after SomeObject is collected. Before, it may have been collected after SomeObject’s constructor ran. This isn’t what I normally think of as coupling though.

@bogdan

Thinking about it a bit more, your comment shows a type of coupling between the objects none of us have called out yet. By requiring SomeObject to know that Dependency1.Calculation1() always returns the same value, the version which stores the value in a field creates an implicit coupling between SomeObject and Dependency1. SomeObject needs to know that Calculation1() is implemented in such a way that the value does not change on repeated calls.

@Dave Didn’t see your second reply until today! Coupling wise I was thinking that if you stored it that meant a greater coupling but I think you’re right it knows about the Dependency so there’s no difference.