Что назвать эквивалентом ООП "ссылочной прозрачности"?

Я понимаю, что термин " ссылочная прозрачность" действительно может быть применен только к функциональному коду. Однако вызов метода объекту в объектно-ориентированном коде может иметь аналогичное свойство, то есть возвращаемое значение метода и состояние объекта после вызова метода зависит только от состояния объекта перед вызовом, и аргументы метода.

то есть. функциональная ссылочная прозрачность:

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

OO "ссылочная прозрачность":

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

Есть ли имя для этого свойства?

Если состояние obj не изменяется во время вызова foo(), тогда стиль "ориентированный объект" эквивалентен функциональной форме, если перегрузка функций поддерживается, поскольку она может быть переписана как:

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

Однако довольно часто для состояния obj можно изменить вызов метода, поэтому я не уверен, помогает ли это анализу...

Ответ 1

Ваша ошибка заключается в том, что FP и OO каким-то образом принципиально отличаются друг от друга. "Версия OO" ссылочной прозрачности - это просто ссылочная прозрачность.

Выражение e является ссылочно прозрачным тогда и только тогда, когда e может быть заменено его оцененным результатом, не влияя на поведение программы.

Итак, если у вас есть выражение o.foo(a), то оно ссылочно прозрачно, если вы можете изменить свой код, чтобы заменить его результатом вызова, не изменяя, как работает ваша программа. Очевидно, что если o.foo недействителен, вы не можете этого сделать. То же самое, если он изменяет внутреннее состояние o. Таким образом, единственным способом для o.foo(a) быть ссылочно прозрачным является то, что его результат является функцией от o и a.

На мой взгляд, "функциональный код" является синонимом "ссылочно прозрачного кода".

Ответ 2

Функциональный термин будет, как вы говорите, прозрачным. Я бы смиренно предложил, чтобы форма, которую вы описали здесь с результатами в зависимости от аргументов метода плюс состояние объекта, называлась ссылочной непрозрачностью.

Ответ 3

Я не думаю, что свойство, описанное вами в сценарии OO, дает вам что-то похожее на то, что ссылочная прозрачность делает в функциональном программировании. Вы описали свойство, в котором метод foo изменяет только состояние объекта obj в следующем вызове:

i = obj.foo(n, m);

Однако, если у вас есть другой объект, который ссылается на obj, тогда вызов foo также изменяет поведение другого объекта. Поскольку ссылки между объектами имеют важное значение в OO (это означает, что это проблема, которую вы не можете легко избежать), это означает, что описанное вами свойство мало говорит о коде. Например:

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

Если метод foo был ссылочно прозрачным (не изменял какое-либо состояние - просто вернул некоторые результаты), то это было бы интересным свойством - потому что оно не изменило бы состояние a.

Ответ 4

состояние объекта после вызова метода зависит только от состояния объекта перед вызовом и аргументов метода.

Я полагаю, вы могли бы сказать, что метод не имеет внешних зависимостей.

В отличие от ссылочной прозрачности, я не уверен, что это набирает вас. Я полагаю, это означает, что метод легко тестируется.