Функциональное программирование и макет объектов

Недавно я смотрел трансляцию на Clojure. В нем ведущий сделал комментарий в контексте обсуждения FP-характера Clojure, который походил на что-то вроде (надеюсь, что я не искажаю его) "Макет предметов насмехается над вами".

Я также слышал подобный комментарий некоторое время назад, когда я смотрел веб-трансляцию, когда Microsoft Reactive Framework начала появляться. Это что-то вроде "Макет объектов для тех, кто не знает математику" )

Теперь я знаю, что оба комментария - это шутки/язык в щеке и т.д. и т.д. (и, вероятно, плохо перефразированный), но лежащие в их основе, очевидно, что-то концептуальное, что я не понимаю, поскольку я действительно не сделал переход к Парадигма FP.

Итак, я был бы признателен, если бы кто-нибудь мог объяснить, действительно ли FP делает насмешливым избыточным, и если да, то каким образом.

Ответ 1

В чистом FP у вас есть ссылочные прозрачные функции, которые вычисляют один и тот же вывод каждый раз, когда вы вызываете их с одним и тем же входом. Таким образом, все необходимое вам состояние должно быть явно передано в качестве параметров и как результаты функции, нет объектов с сохранением состояния, которые каким-то образом "скрыты" за вызываемой вами функцией. Это, однако, то, что обычно делают ваши макетные объекты: имитировать какое-то внешнее, скрытое состояние или поведение, на которое полагается ваш испытуемый.

Другими словами: OO: Ваши объекты сочетают родственное состояние и поведение. Pure FP: State - это то, что вы передаете между функциями, которые сами по себе являются апатридами и опираются только на другие функции без гражданства.

Ответ 2

Я думаю, что важно подумать о том, как идея использования тестов помогает структурировать ваш код. На самом деле, Mocks действительно откладывает решения, которые вы не хотите принимать сейчас (и широко непонятная техника). Вместо состояния объекта рассмотрим частичные функции. Вы можете написать функцию, которая отвлекает часть своего поведения до частичной функции, которая прошла. В unit test это может быть поддельная реализация, которая позволяет вам просто сосредоточиться на коде в руке. Позже вы создаете свой новый код с реальной реализацией для создания системы.

На самом деле, когда мы разрабатывали идею Mocks, я всегда думал о Mocks таким образом. Часть объекта была случайной.