... y es probablemente uno de esos artículos en los que se basó OOP.
En realidad no, pero se agregó a la discusión, especialmente a los profesionales que, en ese momento, fueron entrenados para descomponer sistemas utilizando los primeros criterios que describe en el documento.
Primero quiero saber si mi evaluación es correcta. ¿El paradigma FP y este artículo no están filosóficamente en desacuerdo?
No. Además, a mis ojos, su descripción de cómo se ve un programa de FP no es diferente de cualquier otro que use procedimientos o funciones:
Los datos se pasan de una función a otra, cada función es íntimamente consciente de los datos y "los cambia" en el camino.
... excepto la parte de "intimidad", ya que puede (y a menudo lo hace) tener funciones que operan en datos abstractos, precisamente para evitar la intimidad. Por lo tanto, tiene cierto control sobre esa "intimidad" y puede regularla como quiera, configurando interfaces (es decir, funciones) para lo que desea ocultar.
Por lo tanto, no veo ninguna razón por la cual no podríamos seguir los criterios de ocultación de información de Parnas utilizando la programación funcional y terminar con una implementación de un índice KWIC con beneficios puntuales similares a su segunda implementación.
Suponiendo que estén de acuerdo, me gustaría saber qué es la implementación de FP de la ocultación de datos. Es obvio ver esto en OOP. Puede tener un campo privado al que nadie fuera de la clase puede acceder. No hay una analogía obvia de esto para mí en FP.
En lo que respecta a los datos, puede elaborar abstracciones de datos y abstracciones de tipo de datos utilizando FP. Cualquiera de estas estructuras de hormigón ocultas y manipulaciones de estas estructuras de hormigón utilizando funciones como abstracciones.
EDITAR
Aquí hay un número creciente de afirmaciones que afirman que "ocultar datos" en el contexto de FP no es tan útil (o OOP-ish (?)). Entonces, permítanme estampar aquí un ejemplo muy simple y claro de SICP:
Suponga que su sistema necesita trabajar con números racionales. Una forma de representarlos es como un par o una lista de dos enteros: el numerador y el denominador. Así:
(define my-rat (cons 1 2)) ; here is my 1/2
Si ignora la abstracción de datos, lo más probable es que obtenga el numerador y el denominador usando car
y cdr
:
(... (car my-rat)) ; do something with the numerator
Siguiendo este enfoque, todas las partes del sistema que manipulan números racionales sabrán que un número racional es a cons
: crearán cons
números para crear racionales y extraerlos utilizando operadores de lista.
Un problema que puede enfrentar es cuando necesita tener una forma reducida de los números racionales: se requerirán cambios en todo el sistema. Además, si decide reducir en el momento de la creación, es posible que más tarde reduzca cuando acceder a uno de los términos racionales es mejor, produciendo otro cambio a escala completa.
Otro problema es si, hipotéticamente, se prefiere una representación alternativa para ellos y usted decide abandonar la cons
representación - cambio de escala total nuevamente.
Cualquier esfuerzo sensato al tratar estas situaciones probablemente comenzará a ocultar la representación de los racionales detrás de las interfaces. Al final, podrías terminar con algo como esto:
(make-rat <n> <d>)
devuelve el número racional cuyo numerador es el entero <n>
y cuyo denominador es el entero <d>
.
(numer <x>)
devuelve el numerador del número racional <x>
.
(denom <x>)
devuelve el denominador del número racional <x>
.
y el sistema ya no sabrá (y ya no debería) saber de qué están hechos los racionales. Esto es porque cons
, car
y cdr
no son intrínsecos a los racionales, pero make-rat
, numer
y lo denom
son . Por supuesto, esto podría ser fácilmente un sistema FP. Entonces, la "ocultación de datos" (en este caso, mejor conocida como abstracción de datos, o el esfuerzo de encapsular representaciones y estructuras concretas) se presenta como un concepto relevante y una técnica ampliamente utilizada y explorada, ya sea en el contexto de OO, programación funcional o lo que sea.
Y el punto es ... aunque uno puede tratar de hacer distinciones entre qué "tipo de ocultamiento" o encapsulación están haciendo (ya sea que estén ocultando una decisión de diseño, o estructuras de datos o algoritmos, en el caso de abstracciones de procedimiento), Todos tienen el mismo tema: están motivados por uno o más puntos que Parnas hizo explícitos. Es decir:
- Capacidad de cambio: si los cambios requeridos se pueden hacer localmente o se extienden a través del sistema.
- Desarrollo independiente: hasta qué punto dos partes del sistema pueden desarrollarse en paralelo.
- Comprensibilidad: qué cantidad del sistema se necesita para conocer una de sus partes.
El ejemplo anterior se tomó del libro SICP, por lo que, para la discusión y presentación completa de estos conceptos en el libro, recomiendo consultar el capítulo 2 . También recomiendo familiarizarse con los tipos de datos abstractos en el contexto de FP, que trae otros problemas a la mesa.