La force de OO design en termes de sémantique ou d'encapsulation?

Question

La conception orientée objet (OOD) combine les données et leurs méthodes. Ceci, pour autant que je puisse le voir, réalise deux grandes choses: il fournit l'encapsulation (donc je me fiche des données, seulement comment je reçois les valeurs que je veux) et de la sémantique (il relie les données avec les noms et leurs les méthodes utilisent systématiquement les données comme prévu à l'origine).

Alors, où se situe la force OOD? En revanche, la programmation fonctionnelle attribue la richesse aux verbes plutôt qu'aux noms, de sorte que l'encapsulation et la sémantique sont fournies par les méthodes plutôt que par les structures de données.

Je travaille avec un système qui est sur la fin fonctionnelle du spectre, et qui est continuellement long pour la sémantique et l'encapsulation de OO. Mais je peux voir que l'encapsulation de OO peut être une barrière à l'extension flexible d'un objet. Donc, en ce moment, je peux voir la sémantique comme une plus grande force.

Ou l'encapsulation est-elle la clé de tout code valable?

Éditer: Je veux dire spécifiquement le type d'encapsulation OO fournit ici. changeColor(door,blue) devient door.changeColor(blue).

Answer 1

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.

Answer 2

L'encapsulation et l'abstraction qui en résulte sont clairement les principaux atouts de OO. Les «choses» prédisent quelles «actions» peuvent être invoquées sur elles, de sorte que les noms prennent une importance sémantique plus élevée que les verbes. En fin de compte, il est difficile d'envisager la conception d'un système complexe dans une forme cohérente et maintenable sans un certain niveau d'encapsulation.

Answer 3

complexité Isoler OMI est l'objectif principal de toute conception: l'encapsulation des fonctionnalités derrière une interface qui est plus simple à utiliser que la fonctionnalité elle-même.

OO fournit divers mécanismes pour que - les deux mention Oyu:

Encapsulation permet de concevoir une surface personnalisée qui est indépendante de la mise en œuvre effective. (Pour paraphraser, "Simpler signifie différent").

La sémantique permet de modéliser des entités qui représentent des éléments du domaine de problème, de sorte qu'elles sont plus faciles à comprendre.

---

Tout projet atteignant une certaine taille devient un exercice de gestion de la complexité. Je parierais que, au fil des ans, la programmation a effleuré les limites de la complexité que nous avons appris à gérer.

Je n'ai pas trempé dans la programmation fonctionnelle depuis des années, mais dans ma compréhension, il peut être mieux décrit par la signification d'un mathématicien des mots puissant, elgant, amd beautiful. "Beau" et "élégant", dans ce contexte, essaient de décrire un aperçu brillant de la structure vraie ou pertinente d'un système complexe, en le regardant d'un point de vue où il est étonnamment simple. il accepte la complexité comme donnée, et essaie de la naviguer. La flexibilité que vous mentionnez est selon moi la capacité de changer le POV en fonction de vos besoins - mais cela va à l'encontre de l'encapsulation: ce qui est un détail inutile d'une position peut être le seul pertinent dans un autre.

OO, OTOH, est l'approche réductionniste: nous changeons le POV en passant à un niveau supérieur.Dans "old OO", il existe une seule hiérarchie de POV, les interfaces sont - dans ce modèle - un moyen de modéliser différents POV.

Si je peux dire, la force de OO est mieux adaptée aux "personnes normales".

Answer 4

Une certaine forme de modularité est la clé de toute conception évolutive. Les limites des êtres humains empêche les gens de « grokking » trop d'informations à la fois, donc nous devons diviser les problèmes en morceaux maniables, de cohésion, à la fois de fournir une base pour comprendre un grand projet, ainsi qu'un moyen de subdivisent les tâches de travail d'un grand projet parmi beaucoup de gens.

Comment choisir le plus efficace « division »/« cloisonnement » d'un grand projet pour atteindre les objectifs ci-dessus? L'expérience a montré que OO est le grand gagnant ici, et je pense que beaucoup de gens seraient d'accord que deux attributs clés de OO qui en font bon à ce sont:

• Encapsulated: chaque classe encapsule un « secret » - un ensemble d'hypothèses spécifiques à la mise en œuvre - qui sont susceptibles d'avoir à changer au fil du temps au sujet de sa mise en œuvre - et qui expose une interface qui est indépendante de ces hypothèses; la superposition de telles abstractions encapsulées permet d'architecturer une conception robuste où les composants/implémentations peuvent facilement être échangés face aux changements anticipés. Dans la plupart des domaines, les humains semblent mieux décomposer d'abord un modèle de domaine en pensant aux noms/données d'un domaine, puis en identifiant les verbes de support associés à chaque nom.

En ce qui concerne la programmation fonctionnelle (FP) par rapport à OO, je blogged à ce sujet, mais brièvement, je pense que FP est plus sur les techniques de mise en œuvre alors OO est plus sur la structure du programme et la conception, et donc les deux sont complémentaires, OO étant plus dominant sur la «grande» extrémité de l'échelle et FP étant plus dominant sur la «petite» extrémité. C'est-à-dire, sur un grand projet, la structure de haut niveau est mieux décrite par la classe OO, mais de nombreux détails au niveau du module (implémentations et détails des formes des interfaces des modules) sont mieux définis par FP. influences.

Answer 5

En tant que programmeur Lisp, dont le système objet sans doute fournit aucune de ces, je dis: aucun de ces éléments. : "Le modèle d'objet pseudo-Smalltalk perd et que les fonctions génériques (convenablement contraintes par la règle no-external-overrides) gagnent".

Je pense que les caractéristiques souhaitables que vous et d'autres ici énumérez (encapsulation, modularité, etc.) ne sont pas aussi inhérente à OO que vous pensez. Ils sont souvent fournis aux côtés de OO de style Java, mais pas seulement la conséquence de celui-ci.

Answer 6

La force de la conception orientée objet est proportionnelle à la quantité liaison tardive se produit dans la conception. C'est la notion de Kay de OO, pas la notion de Nygaard. Alan Kay wrote:

POO me signifie que la messagerie, la rétention locale et à la protection et en se cachant de processus de l'État, et de l'extrême liaison tardive de toutes choses. Il peut être fait dans Smalltalk et dans LISP. Il sont éventuellement d'autres systèmes dans lesquels c'est possible, mais je ne suis pas au courant de eux.

Une grande partie de la littérature ignore la liaison tardive en faveur de l'idée C++ de l'orientation de l'objet.

Answer 7

Prenons un peu de recul et regardons ceci à partir d'un niveau supérieur. Les avantages de toute caractéristique linguistique résident dans la capacité à exprimer succinctement le problème/la solution d'une manière plus naturelle par rapport au domaine du problème.

Les mécanismes de la POO sont facilement implémentés en langage C simple avec des structures et des pointeurs de fonction. Vous pouvez même ressentir un peu de POO de cette façon. Cependant, les idiomes de la POO ne sont pas aussi proches dans un tel environnement. Quand il y a un support linguistique réel pour la POO, alors l'expressivité du paradigme apparaît, et la façon dont un langage met en œuvre une idée a un impact très réel sur ce qui est dit et comment. Par exemple, voir les différences de code en utilisant des fermetures/lambdas en lisp, python, ruby, etc.

Donc, à la fin, il ne s'agit pas des composants et des concepts sous-jacents, mais plutôt comment ils sont mis ensemble et utilisés qui font OO en C++ ce que c'est.

Answer 8

Encapsulation en conjonction avec polymorphisme. La capacité des classes dans la plupart des langages POO à implémenter une ou plusieurs interfaces a eu le plus grand impact sur le développement de mon logiciel. Cette fonctionnalité me permet de définir précisément l'interaction entre deux objets.

Non seulement définir les interactions, mais documentez-le pour que des années plus tard, je peux revenir à cette section du code et voir ce qui se passe clairement.

Cette caractéristique est la principale raison pour laquelle je préfère utiliser les langages POO sur les langages fonctionnels. Bien que très puissant, j'ai trouvé que les logiciels écrits dans des langages fonctionnels étaient difficiles à maintenir lorsque le cycle de maintenance est mesuré en plusieurs décennies. (AutoLisp logiciel trouvé dans AutoCAD)

Answer 9

Votre question se lit comme Vous voulez tirer les avantages d'une maison en analysant une brique. La capacité à fournir un contexte sémantique et une encapsulation ne sont que les capacités de base d'une classe dans OO. (Comme une boîte de briques résister à une certaine force et réclamer un certain espace.)

Pour continuer l'analogie: Pour obtenir le maximum de briques, il suffit de les assembler. Le même s'applique aux classes et aux objets.

Il y a are a lot of design patterns qui peut être utilisé pour la programmation OO . La plupart d'entre eux s'appuient sur les capacités "encapsulation" et "sémantique", que vous avez mentionné.

Certains de ces modèles sont même une réponse au troisième paragraphe de votre question:

• Si vous souhaitez étendre le comportement d'une classe existante, vous pouvez créer une classe dérivée. Si vous souhaitez étendre ou modifier le comportement d'un objet existant, vous pouvez envisager le decorator pattern.

Answer 10

IMHO, OO signifie simplement des objets interagissant avec d'autres objets. L'encapsulation signifie simplement l'abstraction d'un concept. Donc, vous créez un Socket et .Connect() à quelque chose. Comment ça se connecte, vous ne vous en souciez pas vraiment (ce qui est essentiellement ma définition de l'encapsulation). Et, pure programmation fonctionnelle peut utiliser objet pour communiquer .. mais ces objets doivent être immuables. Donc, à mon humble avis, FP peut facilement utiliser le concept OO; Un langage impératif tel que C peut toujours utiliser le concept de OO .. par exemple, un fichier pour chaque "Classe" avec une section privée qui ne devrait pas être utilisée.

Answer 11

La puissance réelle de OO réside dans le polymorphisme plutôt que dans l'encapsulation. L'encapsulation, dans une certaine mesure, est réalisable et est utilisée dans les langages fonctionnels, mais le polymorphisme serait très gênant s'il était implémenté dans un langage fonctionnel.

(lire « design pattern » par gang de quatre pour comprendre la puissance de OO.)

@Phil, la différence que vous avez mentionné, si je vous comprends bien, est entre la façon dont le programme invoque des données/method: dans oo, il y a d'abord un objet/instance, puis la donnée/méthode de l'objet est invoquée à travers l'objet; en fonctionnelle, la méthode est invoquée directement. Cependant, en regardant l'implémentation d'un programme fonctionnel, nous voyons que les données et la méthode sont enveloppées (dans un fichier mais pas dans une classe). Par exemple, un programme C a le fichier d'en-tête qui déclare les fonctions accessibles par un autre fichier, et les données sont des données privées si elles sont uniquement accessibles via ces fonctions déclarées. Tant qu'un programmeur est assez prudent, la majeure partie de l'encapsulation dans OO peut être implémentée dans des programmes fonctionnels. (Même l'héritage est disponible en utilisant certaines astuces de pointeur.)