Каковы преимущества ссылочной прозрачности для программиста?

Каковы преимущества ссылочной прозрачности в программировании ?

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

Конечно, у них будут свои академические объяснения того, насколько это «чисто» и «элегантно», но как это делает его лучше, чем менее «чистый» код? Как это помогает мне в моем повседневном программировании?

Примечание: это не дубликат Что такое ссылочная прозрачность? Последний затрагивает тему того, что такое RT, в то время как этот вопрос посвящен его преимуществам (которые могут быть не такими интуитивными).

Преимущество состоит в том, что чистые функции облегчают анализ вашего кода. Или, другими словами, побочные эффекты увеличивают сложность вашего кода.

Возьмите пример computeProductPriceметода.

Чистый метод будет запрашивать количество продукта, валюту и т. Д. Вы знаете, что всякий раз, когда метод вызывается с одинаковыми аргументами, он всегда будет давать один и тот же результат.

• Вы даже можете кэшировать его и использовать кешированную версию.
• Вы можете сделать его ленивым и отложить его вызов, когда он вам действительно понадобится, зная, что значение тем временем не изменится.
• Вы можете вызывать метод несколько раз, зная, что у него не будет побочных эффектов.
• Вы можете рассуждать о самом методе в отрыве от мира, зная, что все, что ему нужно, это аргументы.

Не чистый метод будет более сложным в использовании и отладке. Поскольку это зависит от состояния переменных, отличных от аргументов и, возможно, их изменения, это означает, что он может давать разные результаты при многократном вызове или не иметь одинакового поведения, когда не вызывается вообще или вызывается слишком рано или слишком поздно.

пример

Представьте, что в структуре есть метод, который анализирует число:

decimal math.parse(string t)

У него нет ссылочной прозрачности, потому что это зависит от:

• Переменная окружения, которая определяет систему нумерации, то есть Base 10 или что-то еще.

• Переменная в mathбиблиотеке, которая определяет точность чисел для анализа. Таким образом, при значении 1, синтаксический анализ строки "12.3456"даст 12.3.

• Культура, которая определяет ожидаемое форматирование. Например, с fr-FR, разбор "12.345"даст 12345, потому что символ разделения должен быть ,, а не.

Представьте, как легко или сложно было бы работать с таким методом. С одним и тем же вводом вы можете получить радикально разные результаты в зависимости от момента, когда вы вызываете метод, потому что что-то где-то изменило переменную среды или переключило культуру или установило другую точность. Недетерминированный характер метода приведет к большему количеству ошибок и большему количеству отладочного кошмара. Вызов math.parse("12345")и получение 5349в качестве ответа, так как какой-то параллельный код анализировал восьмеричные числа, нехорошо.

Как исправить этот явно неработающий метод? Путем введения ссылочной прозрачности. Другими словами, избавившись от глобального состояния и переместив все на параметры метода:

decimal math.parse(string t, base=10, precision=20, culture=cultures.en_us)

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

Вы часто добавляете точку останова к точке в своем коде и запускаете приложение в отладчике, чтобы выяснить, что происходит? Если вы это сделаете, это в значительной степени потому, что вы не используете ссылочную прозрачность (RT) в своих проектах. И поэтому нужно запустить код, чтобы понять, что он делает.

Весь смысл RT в том, что код очень детерминирован, то есть вы можете прочитать код и определить, что он делает, каждый раз для одного и того же набора входных данных. Как только вы начинаете добавлять переменные переменные, некоторые из которых выходят за рамки одной функции, вы не можете просто читать код. Такой код должен выполняться либо в вашей голове, либо в отладчике, чтобы понять, как он действительно работает.

Чем проще код для чтения и рассуждения, тем проще обслуживать и обнаруживать ошибки, что экономит время и деньги для вас и вашего работодателя.

Люди используют термин «легче рассуждать», но никогда не объясняют, что это значит. Рассмотрим следующий пример:

result1 = foo("bar", 12)
// 100 lines of code
result2 = foo("bar", 12)

Есть result1и result2одинаковые или разные? Без ссылочной прозрачности вы понятия не имеете. Вы должны на самом деле прочитать тело, fooчтобы убедиться, и, возможно, тело любых fooвызовов функций , и так далее.

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

Есть так много защитных механизмов, которые люди используют, чтобы обойти отсутствие ссылочной прозрачности. Для моего маленького примера я мог бы захотеть сохранить result1в памяти, потому что я не знаю, изменится ли он. Тогда у меня есть код с двумя состояниями: до того, как result1был сохранен и после. С помощью ссылочной прозрачности я могу легко пересчитать ее, если пересчет не занимает много времени.

Я бы сказал: ссылочная прозрачность хороша не только для функционального программирования, но и для всех, кто работает с функциями, потому что она следует принципу наименьшего удивления.

У вас есть функция, и вы можете лучше рассуждать о том, что она делает, потому что нет никаких внешних факторов, которые вы должны принимать во внимание, для данного входа результат всегда будет одинаковым. Даже на своем императивном языке я стараюсь максимально следовать этой парадигме, из чего автоматически вытекает следующее: маленькие простые для понимания функции вместо ужасных 1000+ строковых функций, в которых я иногда работаю.

Эти большие функции делают магию, и я боюсь прикасаться к ним, потому что они могут сломаться захватывающими способами.

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