What to call OOP's equivalent of "referential transparency"?

Question

My understanding is that the term "referential transparency" can really only be applied to functional code. However, a method call on an object in object-oriented code can have a similar property, which is that the return value of the method, and the state of the object after a method call depends only on the state of the object before the call, and the method's arguments.

i.e. functional referential transparency:

i = foo(n, m);
// return value depends only on n, m

OO "referential transparency":

i = obj.foo(n, m);
// return value, and subsequent state of obj, depends 
// only on initial state of obj, n, m

Is there a name for this property?

If the state of obj does not change during the call to foo(), then the "object oriented" style is equivalent to the functional form if function overloading is supported since it could be rewritten as:

i = foo(obj, n, m);
// return value depends only on obj, n, m

However, is pretty common for the state of obj to change in a method call, so I'm not sure if this helps the analysis...

Answer 1

the state of the object after a method call depends only on the state of the object before the call, and the method's arguments.

I suppose you could say that the method has no external dependencies.

Unlike referential transparency however, I'm not sure what this gains you. I suppose it means the method is easily testable.

Answer 2

The functional term would be referential transparency as you say. I would humbly propose that the form you've described here with the results depending on the method's arguments plus the object's state be termed referential opacity.

Answer 3

I don't think that the property you described in the OO scenario gives you anything similar to what referential transparency does in functional programming. You described a property where the foo method modifies only the state of the obj object in the following call:

i = obj.foo(n, m); 

However, if you have another object that references obj then the call to foo also modifies the behavior of the other object. Since references between objects are essential in OO (meaning that this is a problem you cannot easily avoid), this means that the property you described doesn't tell you much about code. For example:

a = new Other(obj);
i = obj.foo(n, m);  // changes state of 'obj' and 'a'

If the foo method was referentially transparent (didn't modify any state - just returned some results), then that would be an interesting property - because it wouldn't modify the state of a.

Answer 4

Your mistake is thinking that FP and OO are somehow fundamentally orthogonal. The "OO version" of referential transparency is just referential transparency.

An expression e is referentially transparent if and only if e can be replaced with its evaluated result without affecting the behavior of the program.

So if you have an expression o.foo(a), then it is referentially transparent if you could modify your code to replace it with the result of the call, without changing how your program behaves. Obviously, if o.foo is void, you can't do that. Ditto if it modifies the internal state of o. So the only way for o.foo(a) to be referentially transparent is if its result is a function of o and a.

In my mind, "functional code", is synonymous with "referentially transparent code".