Programación de funciones y simulacros de objetos

Question

Hace poco vi una transmisión por Internet en Clojure. En él, el presentador hizo un comentario en el contexto de discutir la naturaleza de FP de Clojure, que fue algo así como (espero no tergiversarlo) "Los objetos simulados se burlan de ti".

También escuché un comentario similar hace un tiempo cuando vi un webcast cuando el Marco Reactivo de Microsoft comenzaba a aparecer. Fue algo así como "Los objetos simulados son para aquellos que no saben matemáticas")

Ahora sé que ambos comentarios son bromas/irónicos, etc., etc. (y probablemente parafraseados), pero subyacentes a ellos obviamente algo conceptual que no entiendo ya que no he hecho el cambio al paradigma de FP.

Por lo tanto, estaría agradecido si alguien pudiera explicar si FP de hecho hace que la burla sea redundante y, de ser así, cómo.

Answer 1

En FP puro tiene funciones referencialmente transparentes que calculan la misma salida cada vez que las llama con la misma entrada. Por lo tanto, todo el estado que necesita debe pasarse explícitamente como parámetros y salir como resultados de función, no hay objetos con estado que estén de alguna manera "ocultos detrás" de la función que llama. Sin embargo, esto es lo que suelen hacer los objetos falsos: simular algún estado externo o oculto o comportamiento del que se basa el sujeto bajo prueba.

En otras palabras: OO: Sus objetos combinan estado y comportamiento relacionados. FP puro: el estado es algo que se pasa entre funciones que por sí mismas son sin estado y solo se basan en otras funciones sin estado.

Answer 2

Creo que lo importante es pensar en la idea de utilizar pruebas para estructurar su código. Los simulacros se tratan realmente de diferir las decisiones que no quieres tomar ahora (y una técnica ampliamente incomprendida). En lugar de estado del objeto, considere funciones parciales. Puede escribir una función que transfiere parte de su comportamiento a una función parcial que se transfiere. En una prueba unitaria, esa podría ser una implementación falsa que le permite concentrarse en el código que tiene entre manos. Más tarde, compones tu nuevo código con una implementación real para construir el sistema.

En realidad, cuando estábamos desarrollando la idea de Mocks, siempre pensé en Mocks de esta manera. La parte del objeto era incidental.