Vous semblez utiliser une définition assez étroite de « Encapsulation ». Est-ce que je raison en présumant que vous définissez l'encapsulation être, « La combinaison des données avec des méthodes? »
Si je me trompe alors s'il vous plaît ignorer le reste de ce post.
L'encapsulation n'est pas un terme vague; en fait, il est défini par l'Organisation internationale de normalisation. La référence de l'ISO modèle de traitement réparti ouvert - définit les cinq concepts suivants:
Entité: Toute chose concrète ou abstraite d'intérêt.
Objet: Modèle d'entité. Un objet est caractérisé par son comportement et, dualement, par son état.
Comportement (d'un objet): Une collection d'actions avec un ensemble de contraintes sur quand elles peuvent se produire.
Interface: Une abstraction du comportement d'un objet qui consiste en un sous-ensemble des interactions de cet objet avec un ensemble de contraintes sur le moment où elles peuvent se produire.
Encapsulation: la propriété selon laquelle les informations contenues dans un objet sont accessibles uniquement via des interactions au niveau des interfaces prises en charge par l'objet.
Nous pouvons en outre faire une proposition évidente: certaines informations étant accessibles via ces interfaces, certaines informations doivent être cachées et inaccessibles dans l'objet. La propriété de ces expositions d'information est appelée dissimulation de l'information, qui Parnas défini en faisant valoir que les modules doivent être conçus pour cacher les décisions difficiles et les décisions qui sont susceptibles de changer, voir l'un des grands journaux informatiques:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
Il est important de noter que ce ne sont pas seulement les données qui sont cachées par l'information: c'est un sous-ensemble de comportement associé à l'objet qui est difficile ou susceptible de changer. Dans votre message, vous semblez dire que la différence entre l'encapsulation dans OO et dans la programmation fonctionnelle découle de la gestion des données, mais au moins selon ISO et Parnas, la gestion des données n'est pas la clé de l'encapsulation. Donc, je ne vois pas pourquoi l'encapsulation dans la programmation fonctionnelle doit être différente de celle de OO. Vous mentionnez, en outre, dans votre message que la programmation fonctionnelle fournit l'encapsulation, "... par les méthodes plutôt que par les structures de données." Ceci, je pense, est une différence d'échelle plutôt que d'absolu. Si j'utilise le mot "Object" plutôt que "Structure de données" (encore une fois s'il vous plaît faites-moi savoir si j'interprète mal), alors vous semblez trouver une signification dans l'encapsulation d'OO par l'encapsulation par méthode d'objet et de programmation fonctionnelle.
Pourtant, selon la définition ISO ci-dessus, un objet est tout ce que je souhaite modéliser. Ainsi, des classes peuvent être encapsulées dans un paquet, tant que certaines de ces classes contribuent à l'interface du paquet (c'est-à-dire, les classes publiques du paquet) et certaines sont cachées par l'information (les classes privées dans le paquet). De même, les méthodes sont encapsulées dans une classe - certaines méthodes étant publiques et d'autres privées. Vous pouvez même prendre un cran plus bas et dire que les séquences de code séquentielles de McCabian sont encapsulées dans des méthodes. Chacun forme un graphe de noeuds encapsulés dans des régions encapsulées; et tous ces graphes forment une pile de graphes. Ainsi, la programmation fonctionnelle peut très bien être encapsulée au niveau de la fonction/du fichier, mais ce n'est pas différent du graphe méthode/classe de OO, et essentiellement pas de différence avec le graphe classe/paquet de OO non plus.
Notez également que le mot Parnas utilise ci-dessus: changer. La dissimulation d'informations concerne des événements potentiels, tels que le changement de décisions de conception difficiles dans le futur. Vous demandez où réside la force d'OO; Bien, l'encapsulation est certainement une force de OO, mais la question devient alors, "Où réside la force de l'encapsulation?" et la réponse est celle d'une clarté retentissante: la gestion du changement. En particulier, l'encapsulation réduit la charge potentielle maximale de changement.
Le concept de «couplage potentiel» est utile ici.
« couplage » est lui-même défini comme « une mesure de la force de l'association établie par une connexion d'un module à l'autre, » dans un autre des grands journaux de l'informatique:
http://www.research.ibm.com/journal/sj/382/stevens.pdf
Et comme Réduire les connexions entre les modules minimise également les chemins le long desquels les changements et les erreurs se propagent dans d'autres parties du système, éliminant ainsi les effets désastreux, "Ripple", où les changements dans une partie causent des erreurs dans les autres parties du système. un autre, nécessitant des modifications supplémentaires ailleurs, donnant lieu à de nouvelles erreurs, etc. "
Comme défini ici, cependant, il existe deux limitations qui peuvent être facilement levées. Premièrement, le couplage ne mesure pas les connexions intra-module, et ces connexions intra-module peuvent donner lieu à autant d'effets "Ripple" que de connexions inter-modules (le papier définit, "Cohesion", à relier intra-module éléments, mais ceci n'est pas défini en termes de connexions entre les éléments (c.-à-d. les références aux étiquettes ou aux adresses) avec lesquels le couplage a été défini). Deuxièmement, le couplage de n'importe quel programme informatique est donné, en ce que les modules sont connectés ou; la définition du couplage a peu de portée pour gérer les changements potentiels dont parle Parnas.
Ces deux problèmes sont résolus, dans une certaine mesure, avec le concept de couplage potentiel: le nombre maximum possible de connexions pouvant être formées entre tous les éléments d'un programme. En Java, par exemple, une classe qui est package-private (l'accesseur par défaut) dans un package ne peut pas avoir de connexions (c'est-à-dire, aucune classe externe ne peut en dépendre), mais une classe publique dans un package peut avoir des dépendances à ce sujet. Cette classe publique contribuerait au couplage potentiel même si aucune autre classe n'en dépend pour l'instant - les classes pourraient en dépendre à l'avenir, lorsque le design change.
Pour voir la force de l'encapsulation, considérons le principe de la charge. Le principe de Burden prend deux formes.
La forme forte indique que la charge de la transformation d'une collection d'entités est fonction du nombre d'entités transformées. La forme faible indique que la charge potentielle maximale de la transformation d'une collection d'entités est fonction du nombre potentiel maximal d'entités transformées. Le fardeau de la création ou de la modification d'un système logiciel dépend du nombre de classes créées ou modifiées (ici, nous utilisons "Classes", supposant un système OO, et concernent l'encapsulation au niveau classe/paquet; nous pourrions également nous intéresser au niveau fonction/fichier de la programmation fonctionnelle). (Notez que le "Burden" est un développement de logiciel moderne qui coûte habituellement, ou l'heure, ou les deux.) Les classes qui dépendent d'une classe modifiée particulière ont une plus grande probabilité d'être impactées que les classes qui ne dépendent pas de la modification. classe.
La charge potentielle maximale qu'une classe modifiée peut imposer est l'impact de toutes les classes qui en dépendent. La réduction des dépendances sur une classe modifiée réduit donc la probabilité que sa mise à jour ait un impact sur les autres classes et réduit ainsi la charge potentielle maximale que cette classe peut imposer. Réduire le nombre potentiel maximum de dépendances entre toutes les classes d'un système réduit donc la probabilité qu'un impact sur une classe particulière soit réduit. provoquer des mises à jour à d'autres classes et réduit ainsi le fardeau potentiel maximal de toutes les mises à jour.L'encapsulation, en réduisant le nombre potentiel maximal de dépendances entre toutes les classes, atténue donc la forme faible du principe de charge. Tout cela est couvert par la «théorie de l'encapsulation», qui tente de prouver mathématiquement de telles assertions, en utilisant le couplage potentiel comme moyen logique de structurer un programme.
Notez, cependant, que lorsque vous demandez, "L'encapsulation est-elle la clé de tout code valable?", La réponse doit sûrement être: non. Il n'y a pas de clé unique pour tout le code valable. L'encapsulation est, dans certaines circonstances, simplement un outil pour améliorer la qualité du code afin qu'il devienne «utile».
Vous écrivez aussi que «... l'encapsulation peut être une barrière à l'extension flexible d'un objet. "Oui, c'est très certainement le cas: il est en effet conçu pour être une barrière contre l'extension des décisions de conception d'un objet qui sont difficiles ou susceptibles de changer. Ce n'est pas, cependant, pensé pour être une mauvaise chose. Une approche alternative serait de rendre toutes les classes publiques et d'avoir un programme exprimant son couplage potentiel maximal; mais alors la forme faible du principe de Burden stipule que les mises à jour deviendront de plus en plus coûteuses; ce sont les coûts par rapport auxquels les obstacles à la vulgarisation doivent être mesurés. Finalement, vous faites la comparaison intéressante entre l'encapsulation et la sémantique, et que, selon vous, la sémantique d'OO est sa plus grande force. Je ne suis pas sémantique non plus (je ne savais même pas qu'un tel mot existait avant que le bon Monsieur Ramsey y fasse allusion dans son commentaire) mais je présume que vous voulez dire, "Sémantique", au sens de "le sens, ou un interprétation de la signification, d'un mot, "et très fondamentalement qu'une classe avec une méthode, woof() devrait s'appeler un chien.
Il y a une grande force dans cette sémantique. Ce qui est curieux pour moi, c'est que vous faites une sémantique contre l'encapsulation et que vous cherchez un gagnant; Je doute que vous en trouviez un. À mon avis, il y a deux forces qui motivent l'encapsulation: la sémantique et la logique.
L'encapsulation sémantique signifie simplement l'encapsulation basée sur la signification des nœuds (pour utiliser le terme général) encapsulée. Donc, si je vous dis que j'ai deux paquets, un appelé, «animal», et un appelé «minéral», puis vous donner trois classes Dog, Cat et Goat et demander dans quels paquets ces classes doivent être encapsulées, puis, donné aucune autre information, vous auriez parfaitement raison de prétendre que la sémantique du système suggérerait que les trois classes soient encapsulées dans le paquet «animal» plutôt que dans le «minéral». L'autre motivation pour l'encapsulation, cependant, est la logique, et en particulier l'étude du couplage potentiel, mentionnée ci-dessus. La théorie de l'encapsulation fournit en fait des équations pour le nombre de paquets qui devraient être utilisés pour encapsuler un certain nombre de classes afin de minimiser le couplage potentiel. Pour moi, l'encapsulation dans son ensemble est le compromis entre cette approche sémantique et logique: je vais permettre au couplage potentiel de mes programmes de dépasser le minimum si cela facilite la compréhension sémantique du programme; mais des niveaux énormes et gaspilleurs de couplage potentiel seront un avertissement que mon programme doit être restructuré, peu importe à quel point il est sémantiquement évident.
(Et si le bon Monsieur Ramsey est toujours en train de lire, est-ce que vous ou vos amis sémanticiens pourriez me donner un meilleur mot pour la phase sémantique que j'utilise ici? Il serait bon d'utiliser un terme plus approprié .)
Cordialement, Ed.
Vous utilisez abusivement le terme technique «sémantique». (Je ne suis pas un sémanticien, mais beaucoup de mes amis le sont.) Parlez-vous de raisonnement basé sur la confiance/repos sur les corps de méthodes? Si c'est le cas, c'est une conséquence de l'encapsulation (dissimulation d'informations) et il n'y a pas de concurrence. –
Peut-être que l'abstraction est un meilleur mot? Et voulez-vous parler de programmation procédurale plutôt que de programmation fonctionnelle? – MarkJ