... et est probablement l'un de ces articles sur lesquels la POO était basée.
Pas vraiment, mais cela a ajouté à la discussion, spécialement aux praticiens qui, à l'époque, étaient formés pour décomposer les systèmes en utilisant les premiers critères qu'il décrit dans l'article.
Je veux d'abord savoir si mon évaluation est correcte. Le paradigme de la PF et cet article sont-ils philosophiquement en désaccord?
De plus, à mes yeux, votre description de ce à quoi ressemble un programme de PF n'est pas différente de toute autre qui utilise des procédures ou des fonctions:
Les données sont transmises de fonction en fonction, chaque fonction étant intimement consciente des données et les "modifiant" en cours de route.
... sauf pour la partie "intimité", puisque vous pouvez (et avez souvent) des fonctions fonctionnant sur des données abstraites, précisément pour éviter l'intimité. Ainsi, vous avez un certain contrôle sur cette «intimité» et vous pouvez la réguler comme bon vous semble, en configurant des interfaces (c'est-à-dire des fonctions) pour ce que vous voulez cacher.
Donc, je ne vois aucune raison pour laquelle nous ne serions pas en mesure de suivre les critères Parnas de dissimulation d'informations à l'aide de la programmation fonctionnelle et de nous retrouver avec une implémentation d'un index KWIC avec des avantages pointus similaires à sa deuxième implémentation.
En supposant qu'ils soient d'accord, j'aimerais savoir ce qu'est la mise en œuvre par les FP de la dissimulation des données. Il est évident de voir cela dans OOP. Vous pouvez avoir un champ privé auquel personne en dehors de la classe ne peut accéder. Il n'y a pas d'analogie évidente avec cela dans FP.
En ce qui concerne les données, vous pouvez élaborer des abstractions de données et des abstractions de types de données à l'aide de FP. N'importe laquelle de ces structures cache des structures en béton et des manipulations de ces structures en béton en utilisant des fonctions comme abstractions.
MODIFIER
Il y a un nombre croissant d'affirmations ici affirmant que «cacher des données» dans le contexte de la PF n'est pas si utile (ou OOP-ish (?)). Alors, laissez-moi tamponner ici un exemple très simple et clair du SICP:
Supposons que votre système doive fonctionner avec des nombres rationnels. Vous pouvez éventuellement les représenter sous la forme d'une paire ou d'une liste de deux nombres entiers: le numérateur et le dénominateur. Ainsi:
(define my-rat (cons 1 2)) ; here is my 1/2
Si vous ignorez l'abstraction des données, vous obtiendrez très probablement le numérateur et le dénominateur en utilisant car
et cdr
:
(... (car my-rat)) ; do something with the numerator
En suivant cette approche, toutes les parties du système qui manipulent des nombres rationnels sauront qu'un nombre rationnel est un cons
- ils cons
numéroteront pour créer des rationnels et les extraire en utilisant des opérateurs de liste.
Un problème auquel vous pouvez être confronté est lorsque vous devez avoir une forme réduite de nombres rationnels - des changements seront nécessaires dans l'ensemble du système. De plus, si vous décidez de réduire au moment de la création, vous constaterez peut-être plus tard que la réduction lors de l'accès à l'un des termes rationnels est meilleure, ce qui entraînera un autre changement à grande échelle.
Un autre problème est si, hypothétiquement, une représentation alternative pour eux est préférée et que vous décidez d'abandonner la cons
représentation - changement à grande échelle à nouveau.
Tout effort raisonnable pour faire face à ces situations commencera probablement à cacher la représentation des logiques derrière les interfaces. À la fin, vous pourriez vous retrouver avec quelque chose comme ceci:
(make-rat <n> <d>)
renvoie le nombre rationnel dont le numérateur est l'entier <n>
et dont le dénominateur est l'entier <d>
.
(numer <x>)
renvoie le numérateur du nombre rationnel <x>
.
(denom <x>)
renvoie le dénominateur du nombre rationnel <x>
.
et le système ne saura plus (et ne devrait plus) savoir de quoi sont faites les justifications. C'est parce que cons
, car
et cdr
ne sont pas intrinsèques aux rationnels, mais make-rat
, numer
et le denom
sont . Bien sûr, cela pourrait facilement être un système de PF. Ainsi, la "dissimulation de données" (dans ce cas, mieux connue sous le nom d'abstraction de données, ou l'effort d'encapsuler des représentations et des structures concrètes) se présente comme un concept pertinent et une technique largement utilisée et explorée, que ce soit dans le contexte de l'OO, de la programmation fonctionnelle ou peu importe.
Et le fait est ... bien que l'on puisse essayer de faire des distinctions entre le "type de dissimulation" ou l'encapsulation qu'ils font (qu'ils cachent une décision de conception, ou des structures de données ou des algorithmes - dans le cas d'abstractions procédurales), tous ont le même thème: ils sont motivés par un ou plusieurs points explicités par Parnas. C'est:
- Changeabilité: si les modifications requises peuvent être apportées localement ou réparties dans le système.
- Développement indépendant: dans quelle mesure deux parties du système peuvent être développées en parallèle.
- Compréhension: quelle partie du système doit être connue pour comprendre l'une de ses parties.
L'exemple ci-dessus a été tiré du livre SICP donc, pour la discussion complète et la présentation de ces concepts dans le livre, je recommande fortement de consulter le chapitre 2 . Je recommande également de se familiariser avec les types de données abstraits dans le contexte de la FP, ce qui apporte d'autres problèmes à la table.