Est-ce que la force de la conception OO dans la sémantique ou l'encapsulation?

StackOverflow https://stackoverflow.com/questions/669042

Question

conception orientée objet (OOD) combine les données et ses méthodes. Ce, pour autant que je peux voir, réalise deux grandes choses: il fournit l'encapsulation (donc je ne me soucie pas les données il y a, que la façon dont je reçois des valeurs que je veux) et sémantique (ce qui a trait les données ainsi que les noms, et son méthodes utilisent systématiquement les données comme prévu initialement).

D'où vient donc le mensonge de la force de OOD? En contraste, la programmation fonctionnelle attribue la richesse des verbes plutôt que les noms, et ainsi à la fois l'encapsulation et la sémantique sont fournies par les procédés plutôt que les structures de données.

Je travaille avec un système qui est à l'extrémité fonctionnelle du spectre, et continuellement longtemps pour que la sémantique et l'encapsulation de OO. Mais je vois que l'encapsulation de OO peut être un obstacle à l'extension flexible d'un objet. Donc, pour le moment, je peux voir la sémantique comme une plus grande force.

Ou est-encapsulation la clé de tout le code utile?

Edit: Je veux dire spécifiquement le type de OO d'encapsulation fournit ici. Devient changeColor(door,blue) door.changeColor(blue).

Était-ce utile?

La solution

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 cet article.

Encapsulation est pas un terme lâche; 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: Un modèle d'une entité. Un objet est caractérisé par son comportement et, doublement, par son état.

Comportement (d'un objet). Une collection d'actions avec un ensemble de contraintes quand ils peuvent se produire

Interface:. Une abstraction du comportement d'un objet qui se compose d'un sous-ensemble des interactions de cet objet ainsi que d'un ensemble de contraintes sur le moment où ils peuvent se produire

Encapsulation:. La propriété que les informations contenues dans un objet est accessible uniquement par des interactions aux interfaces supportées par l'objet

Nous pouvons encore faire une proposition de soi: que certaines informations sont accessibles via ces interfaces, certaines informations doivent être caché et inaccessible dans l'objet. La propriété de ces informations présente 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 documents informatiques:

http://www.cs.umd.edu/ classe / spring2003 / cmsc838p / design / criteria.pdf

Il est important de noter qu'il est non seulement les données sont des informations cachées:. Il est un sous-ensemble du 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 la norme ISO et Parnas, la gestion des données ne sont pas la clé d'encapsulation. Je ne vois donc pas pourquoi l'encapsulation dans la programmation fonctionnelle doit être différente de celle OO.

Vous mentionnez, par ailleurs, dans votre post que la programmation fonctionnelle fournit l'encapsulation, « ... par les méthodes plutôt que les structures de données. », Je pense, est une différence d'échelle plutôt que d'absolu. Si j'utilise le mot « objet » plutôt que « la structure des données » (encore une fois, s'il vous plaît laissez-moi savoir si je suis mal interprété), vous semblez trouver une signification dans l'encapsulation de OO par objet et l'encapsulation de programmation fonctionnelle par la méthode.

Cependant, la définition ISO ci-dessus, un objet est tout ce que je souhaite modéliser. Ainsi, les classes peuvent être encapsulées dans un paquet, tant que certains de ces cours contribuent à l'interface de l'ensemble (à savoir, les classes publiques du paquet) et certains sont cachés des informations (des 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 aller un cran plus bas et dire que les séquences successives McCabian de code sont encapsulées dans les méthodes. Chaque forme un graphe de noeuds encapsulés au sein des régions encapsulées; et tous ces graphiques forment une pile graphique. Ainsi, la programmation fonctionnelle peut bien encapsulé au niveau fonction / fichier, mais cela ne diffère pas de la méthode / graphique de classe OO, et pratiquement pas de différence par rapport à la classe graphique / paquet de OO soit.

En outre, notez ce mot Parnas ci-dessus utilise: le changement. Le masquage d'information concerne des événements potentiels, comme le changement des décisions de conception difficiles à l'avenir. Vous demandez où le mensonge de la force OO; bien, l'encapsulation est certainement une force de OO, mais la question devient alors: « D'où vient le mensonge de la force de l'encapsulation? » et la réponse est une de clarté retentissante: chala gestion de NGE. En particulier, l'encapsulation réduit la charge potentielle maximale du changement.

Le concept de « couplage potentiel » est utile ici.

« Coupling », elle-même est définie comme « une mesure de la force de l'association établie par une connexion d'un module à l'autre, » dans une autre des grands papiers de calcul:

http://www.research.ibm.com/journal/ sj / 382 / stevens.pdf

Et comme le journal, des mots jamais depuis amélioré, « Minimisation des connexions entre les modules permet également de minimiser les chemins le long desquels les changements et les erreurs se propagent dans d'autres parties du système, éliminant ainsi désastreux, « effets Ripple », où les changements de une partie des erreurs de cause dans un autre, ce qui nécessite des modifications supplémentaires ailleurs, donnant lieu à de nouvelles erreurs, etc. »

Comme défini ici, cependant, il y a deux limitations qui peuvent facilement être levées. Tout d'abord, le couplage ne mesure pas les connexions intra-module et ces connexions intra-module peut donner lieu à tout autant, « Ripple » effets que les connexions inter-modules (le document ne définit, « cohésion » de relier intra-module éléments, mais ce ne sont pas définis en termes de connexions entre les éléments (par exemple, les références à des étiquettes ou des adresses) avec lequel le couplage a été défini). D'autre part, le couplage d'un programme d'ordinateur est une donnée, en ce que les modules sont connectés ou; il y a peu de place dans la définition du couplage pour gérer les changements potentiels dont Parnas parle.

Ces deux problèmes sont résolus, dans une certaine mesure, avec le concept de couplage potentiel: le nombre maximum de connexions façonnables entre tous les éléments d'un programme. En Java, par exemple, une classe qui est paquet-privé (l'accesseur par défaut) dans un emballage ne peuvent pas avoir des connexions formées sur (ie, pas de cours à l'extérieur peuvent dépendre, de réflexion en dépit), mais une classe publique dans un emballage peut ont des dépendances sur elle. Cette classe publique contribuerait au couplage potentiel même si aucune autre classe dépendent au moment -. Des cours pourraient dépendre à l'avenir, lorsque les changements de conception

Pour voir la force d'encapsulation, considérons le principe de la charge. Le principe de la charge prend deux formes.

La forme forte indique que la charge de la transformation d'un ensemble 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'un ensemble d'entités est une fonction du nombre potentiel maximum des entités transformées.

La charge de créer ou de modifier tout système de logiciel est une fonction du nombre de classes créées ou modifiées (nous utilisons ici, « Classes », présumant un système OO, et sont concernés par encapsulation au niveau classe / package, nous pourraient également nous ont concerné le niveau fonction / fichier de programmation fonctionnelle). (Notez que le « fardeau » est le développement de logiciels modernes est généralement le coût, ou le temps, ou les deux.) Les classes qui dépendent d'un particulier, la classe modifiée ont une plus grande probabilité d'être touchés que les classes qui ne dépendent pas de la classe modifiée.

La charge potentielle maximale d'une classe modifiée peut imposer est l'impactant de toutes les classes qui en dépendent.

Réduire les dépendances sur une classe modifiée réduit donc la probabilité que sa mise à jour aura un impact sur d'autres classes et réduit ainsi la charge potentielle maximale que cette classe peut imposer. (Ceci est un peu plus d'une nouvelle déclaration de la « conception structurée, » papier.)

Réduire le nombre maximal de dépendances entre toutes les classes dans un système réduit donc la probabilité qu'un impact à une classe particulière entraînera des mises à jour à d'autres classes, et réduit ainsi la charge potentielle maximale de toutes les mises à jour.

Encapsulation, en réduisant le nombre maximal de Dependencies entre toutes les classes, donc la forme atténue la faiblesse du principe de la charge. Tout cela est couvert par « théorie Encapsulation », qui tente de prouver mathématiquement ces assertions, en utilisant le couplage potentiel comme moyen logique de structuration d'un programme.

Notez, cependant, que lorsque vous demandez, « ? Est-encapsulation la clé de tout le code vaut la peine », la réponse doit sûrement: non. Il n'y a pas de clé unique à tout le code utile. Encapsulation est, dans certaines circonstances, mais simplement un outil pour aider à améliorer la qualité du code afin qu'il devienne « Worthwhile ».

Vous écrivez aussi que, « ... l'encapsulation peut être une barrière à l'extension flexible d'un objet. » Oui, il peut très certainement: 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 changer. Ceci est toutefois pas considéré comme une mauvaise chose. Une autre approche serait d'avoir toutes les classes publiques et un programme exprimer son couplage potentiel maximum; mais la forme faible du principe de la charge indique que les mises à jour deviendront de plus en plus coûteux; ce sont les coûts contre lesquels les obstacles à l'extension sont à mesurer.

Enfin, vous faites la comparaison intéressante entre l'encapsulation et la sémantique, et que, à votre avis, la sémantique OO sont sa plus grande force. Je ne suis pas non plus sémanticien (je ne savais même pas un tel mot existait avant que le bon Monsieur Ramsey fait allusion dans son commentaire), mais je présume que vous voulez dire, « Sémantique » au sens de « la signification ou un interprétation du sens, d'un mot, » et très fondamentalement qu'une classe avec une méthode Woof () doit être appelé un chien.

Il y a une grande force dans cette sémantique en effet.

Ce qui est curieux pour moi est que vous opposez sémantique contre l'encapsulation et chercher un gagnant; Je doute que vous trouverez un.

À mon avis, il y a deux forces qui motivent l'encapsulation:. La sémantique et logique

encapsulation sémantique signifie simplement l'encapsulation basée sur la signification des nœuds (à utiliser le terme général) encapsulées. Donc, si je vous dis que j'ai deux paquets, l'un dit, « l'animal », et on a appelé « minéral », et puis vous donner trois classes de chien, de chat et de chèvre et demande dans laquelle des paquets ces classes doivent être encapsulées, puis, étant donné aucune autre information, vous serait tout à fait raison de prétendre que la sémantique du système suggère que les trois classes sont encapsulées dans le « animal » paquet, plutôt que le « minéral ».

L'autre motivation pour l'encapsulation, cependant, est logique, et en particulier l'étude du couplage potentiel, mentionné ci-dessus. la théorie Encapsulation fournit en fait des équations pour le nombre de colis qui doit être utilisé 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 le couplage potentiel de mes programmes à élever au-dessus du minimum si cela rend le programme sémantiquement plus facile à comprendre; mais les niveaux énormes et un gaspillage de couplage potentiel sera un avertissement que mon programme doit être restructurés, peu importe la façon dont il est sémantiquement évident.

(Et si le bon Monsieur Ramsey est en train de lire encore, pourriez-vous ou vos amis sémanticien me donner un meilleur mot pour les phases, « Sémantique, » Je me sers ici? Il serait bon d'utiliser un terme plus approprié. )

Cordialement, Ed.

Autres conseils

Encapsulation et l'abstraction qui en résulte sont clairement les principaux points forts de OO. Le prédicat « choses » que « actions » peut être invoqué sur eux, si les noms prennent une importance sémantique plus que des verbes.

En fin de compte, il est difficile d'envisager la conception d'un système complexe sous une forme cohérente et échangeables sans un certain niveau d'encapsulation.

En tant que programmeur Lisp, dont le système objet sans doute fournit aucune de ces, je dis:. Aucune de ces

jwz:. "Le modèle d'objet pseudo-Smalltalk perd et que les fonctions génériques (convenablement contraint par la règle de non-externe-overrides) gagnant"

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 Java style OO, mais pas uniquement la conséquence.

Isoler complexité est OMI l'objectif principal de toute conception:. Encapsulation fonctionnalité 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, « plus simple des moyens différents »).

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

Tout projet d'atteindre une certaine taille devient un exercice de gestion de la complexité. Je parie une réclamation au cours des années, la programmation a écrémé le long des limites de la complexité que nous avons appris # à gérer.

Je ne l'ai pas touché à la programmation fonctionnelle pendant des années, mais je crois comprendre qu'il peut être décrit par un sens de la mathématique des mots puissants, chics, beaux amd. « Beautiful » et « élégant », dans ce contexte, essayer de décrire une idée brillante dans le vrai ou la structure pertinente d'un système complexe, regardant d'un point de vue où il est étonnamment simple. il accepte la complexité comme donnée, et tente d'y naviguer.

La flexibilité que vous mentionnez est dans ma compréhension la capacité de changer le POV en fonction de vos besoins - mais qui est contraire à l'encapsulation: ce qui est un détail inutile d'une position peut être la seule pertinente dans un autre

.

OO, OTOH, est l'approche réductionniste: nous changeons POV en allant à un niveau supérieur. Dans « vieux OO », il y a une une seule hiérarchie de POVs, les interfaces sont - dans ce modèle - une façon de modéliser différents POVs.

Si je puis dire, la force de OO est d'être mieux adapté à « gens normaux ».

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 compréhension un grand projet, ainsi que un moyen de lotir les affectations de travail d'un grand projet parmi beaucoup de gens.

Comment choisir la 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 les deux principales caractéristiques de OO qui en font bon à ce sont:

  • encapsulées : chaque classe encapsule un « secret » - un ensemble de spécifique à la mise en œuvre des hypothèses qui-sont-susceptibles à avoir à changement de temps au sujet de sa mise en œuvre - et expose une interface qui est agnostique à ces hypothèses; superposant ces abstractions encapsulées permet à l'architecte une conception robuste où les composants / mises en œuvre peuvent facilement être permutés face à des changements prévus.
  • Nom-centrique : dans la plupart des domaines, les humains semblent mieux abord décomposer un modèle de domaine en pensant les noms / données d'un domaine, puis en identifiant les verbes de soutien qui sont associés à chaque nom .

En ce qui concerne la programmation fonctionnelle (FP) par rapport à OO, je blogué à 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, avec OO étant plus dominante sur la fin « grand » de l'échelle et FP étant plus dominant sur l'extrémité « petit ». Cela est, sur un grand projet, la structure de haut niveau est le mieux décrit par la conception de classe OO, mais beaucoup des détails au niveau du module (mises en œuvre, et les détails des formes des interfaces des modules) sont les mieux en forme par FP influences.

La force de la conception orientée objet-est proportionnel à la quantité de liaison tardive se produit dans la conception. Ceci est la notion Kay de OO, pas la notion Nygaard. Alan Kay a écrit :

  

POO me signifie que la messagerie, locale   la conservation et la protection et la dissimulation   de processus d'état, et de l'extrême   liaison tardive de toutes choses. Ça peut être   fait en Smalltalk et Lisp. Là   sont peut-être d'autres systèmes dans lesquels   cela est possible, mais je ne suis pas au courant   les.

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

Prenons un peu de recul et de regarder cela d'un niveau supérieur. Les avantages de tout mensonge caractéristique de la langue dans la capacité d'exprimer succinctement le problème / solution d'une manière plus naturelle par rapport au domaine du problème.

La mécanique de la POO sont facilement mises en œuvre en C à struct et des pointeurs de fonction. Vous pouvez même obtenir un peu de POO sentir le faire de cette façon. Cependant, les idiomes POO ne sont pas presque aussi venir dans un tel environnement. Quand il y a prise en charge linguistique réelle pour POO alors l'expressivité du paradigme sort, et la façon dont une langue 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 ce n'est pas sur les composants et les concepts sous-jacents, mais plutôt la façon dont ils sont mis en place et utilisés qui font OO en C ++ ce qu'il est.

Encapsulation conjointement avec Polymorphisme. La capacité des classes dans la plupart des langages de POO pour mettre en œuvre une ou plusieurs interfaces a eu le plus grand impact sur le développement de mon logiciel. Cette fonction me permet de définir précisément l'interaction entre les deux objets.

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

Cette fonction est la principale raison pour laquelle je préfère utiliser des langues POO sur les langages fonctionnels. Bien que très puissant, j'ai trouvé des logiciels écrits en langages fonctionnels pour être une douleur à maintenir lorsque le cycle de maintenance est mesuré depuis des décennies. (Logiciel AutoLisp trouvé dans AutoCAD)

IMHO, OO signifie simplement des objets qui interagissent avec d'autres objets. Encapsulation signifie simplement abstraire un concept. Ainsi, vous créez un socket et .Connect () à quelque chose. Comment il se connecte, vous ne vous souciez pas vraiment (ce qui est fondamentalement ma définition d'encapsulation).

Et, pur la programmation fonctionnelle peut utiliser l'objet pour communiquer .. mais ces objets doivent être immuable. Donc, encore une fois à mon humble avis, FP peut facilement utiliser OO notion; langue Impératif tel que C peut encore utiliser le concept de OO .. par exemple, un fichier pour chaque « classe » avec une partie privée qui ne devrait pas être utilisé.

Votre question se lit comme vous voulez tirer tous les avantages d'un Maison en analysant une brique.

Avoir la capacité de fournir un contexte sémantique et l'encapsulation ne sont que les capacités de base d'une classe OO. (Comme une brique peut résister à une certaine force et une certaine revendication espace.)

Pour continuer l'analogie: Pour obtenir le maximum de briques, il suffit de les mettre ensemble. le très même pour les classes et les objets.

ya beaucoup de modèles de conception qui peuvent être utilisés pour OO programmation. La plupart d'entre eux comptent 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 alinéa de votre question:

Non affilié à StackOverflow
scroll top