Comments on: Coding: Reduce fields, delay calculations

By: Scala: val, lazy val and def at Mark Needham

Scala: val, lazy val and def at Mark Needham — Wed, 22 Jun 2011 23:08:09 +0000

[...] In Java, C# or Ruby I would definitely favour the 3rd option because it reduces the amount of state that an object has to hold. [...]

By: Testability: How much logic belongs in the constructor? « Alexandre Gazola

Testability: How much logic belongs in the constructor? « Alexandre Gazola — Wed, 23 Sep 2009 22:35:55 +0000

[...] should do no real work. Mark Needham, in turn, advocates the simplification of constructors by delaying calculations. He points out the idea of reducing field calculation in the constructor, only calculating those [...]

By: Coding: Watch out for mutable code at Mark Needham

Coding: Watch out for mutable code at Mark Needham — Wed, 16 Sep 2009 13:44:43 +0000

[...] been doing some more work recently on trying to reduce the number of fields in some of our classes and moving any logic related to calculations into… but managed to break part of our application recently by doing that a bit too casually and not [...]

By: Coding: An abstract class/ASP.NET MVC dilemma at Mark Needham

Coding: An abstract class/ASP.NET MVC dilemma at Mark Needham — Sat, 12 Sep 2009 14:20:47 +0000

[...] previously described a refactoring that we have been working on to reduce the number of fields and delay calculations and the actual goal behind this refactoring was to get the code into shape so that we could add in [...]

By: Mark Needham

Mark Needham — Sat, 12 Sep 2009 11:58:06 +0000

@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.

By: Dave Cameron

Dave Cameron — Sun, 06 Sep 2009 19:15:49 +0000

Very much agree on the Law of Demeter violation. From the example, CalculateValueFrom() really looks like it wants to live on dependency1.

By: Dave Cameron

Dave Cameron — Sun, 06 Sep 2009 19:14:48 +0000

@Mark

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.

By: Dave Cameron

Dave Cameron — Sun, 06 Sep 2009 19:08:04 +0000

@bogdan, @mark, @mike

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.

By: Mike King

Mike King — Fri, 04 Sep 2009 12:55:25 +0000

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.

By: Reflective Perspective - Chris Alcock » The Morning Brew #426

Reflective Perspective - Chris Alcock » The Morning Brew #426 — Fri, 04 Sep 2009 07:38:24 +0000

[...] Coding: Reduce fields, delay calculations – Mark Needham talks about avoiding doing calculations in constructors and storing the values in fields, instead opting for a more lazy loaded approach [...]