There’s a lovely idea out there that states that code shouldn’t make it obvious whether a value is data or computed. Martin Fowler recently added a bliki article on the subject. He also observed that the custom is more honoured in the breach than the observance. But, to be honest, I’m really not that convinced it’s a good idea anyway. Let’s restate this a different way: a field access should be indistinguishable from a synchronous method call. Now, this is fine for computations of the form “price * volume”, but if you get a computation that takes appreciable time, this starts to look like a bad idea.
It gets to be an insane idea when you extend the idea to anything that involves I/O. The first idea that you develop is the idea of the Remote Procedure Call, a brilliant, beautiful, wrong-headed idea. If network access was cheap, as people seemed to believe it would be in the early 90s, this might be a goer. As it is, the performance difference between accessing a byte of memory and a byte of memory on a remote machine is so large as to render almost all other concerns, including algorithmic complexity, irrelevant. You try to write a front end using the Uniform Access Principle and you will have a inconsistently performing UI.
There is a way, of course, to satisfy the uniform access principle and still cope with network access and long computation, and that’s to make absolutely everything asynchronous. Not even node does that. In practice, your code is always going to reflect the performance architecture and especially the network architecture of the solution. If it doesn’t, frankly, your code is wrong.
Colour Coding 