Qu'est-ce que l'abstraction? [fermé]

Existe-t-il une définition généralement acceptée de ce qu’est une abstraction de programmation , telle qu’elle est utilisée par les programmeurs? [Remarque: la programmation de l'abstraction ne doit pas être confondue avec les définitions du dictionnaire pour le mot "abstraction".] Existe-t-il une définition non ambiguë, voire mathématique? Quels sont quelques exemples clairs d’abstractions?

La réponse à "Pouvez-vous définir ce qu'est une abstraction de programmation est plus ou moins mathématiquement?" est "non" L'abstraction n'est pas un concept mathématique. Ce serait comme demander à quelqu'un d'expliquer mathématiquement la couleur d'un citron.

Si vous voulez une bonne définition, l’abstraction est le processus qui consiste à passer d’une idée spécifique à une idée plus générale. Par exemple, regardez votre souris. Est-ce sans fil? De quel type de capteur s'agit-il? Combien de boutons? Est-ce ergonomique? Quelle est sa taille? Les réponses à toutes ces questions peuvent décrire précisément votre souris, mais quelles que soient leurs réponses, il s’agit toujours d’une souris, car c’est un périphérique de pointage avec des boutons. C'est tout ce qu'il faut pour être une souris. "Silver Logitech MX518" est un élément concret et spécifique, et "souris" en est une abstraction. Une chose importante à laquelle il faut penser, c'est qu'il n'y a pas d'objet concret comme une "souris", c'est juste une idée. La souris sur votre bureau est toujours quelque chose de plus spécifique - c'est

L'abstraction peut être superposée et aussi fine ou grossière que vous le souhaitez (une souris MX518 est une souris, un objet de pointage, un périphérique d'ordinateur, un objet alimenté à l'électricité), peut aller aussi loin que vous le souhaitez et dans pratiquement toutes les directions que vous souhaitez (ma souris a un fil, ce qui signifie que je pourrais le classer comme un objet avec un fil. Il est également plat en bas, de sorte que je pourrais le classer comme une sorte d’objets qui ne roulera pas quand placé verticalement sur un plan incliné).

La programmation orientée objet est construite sur le concept d'abstractions et de familles ou de groupes d'entre eux. Une bonne POO signifie choisir de bonnes abstractions au niveau de détail approprié qui ont un sens dans le domaine de votre programme et ne "fuient" pas. Le premier signifie que classer une souris en tant qu'objet qui ne roulera pas sur un plan incliné n'a pas de sens pour une application inventoriant le matériel informatique, mais peut l'être pour un simulateur physique. Ce dernier signifie que vous devriez essayer d’éviter de vous "boxer" dans une hiérarchie qui n’a aucun sens pour certains objets. Par exemple, dans ma hiérarchie ci-dessus, sommes-nous sûrs que tousles périphériques de l'ordinateur sont alimentés à l'électricité? Qu'en est-il d'un stylet? Si nous souhaitons regrouper un stylet dans la catégorie "périphérique", nous aurions un problème, car il ne consomme pas d'électricité et nous avons défini les périphériques informatiques comme des objets utilisant de l'électricité. Le problème cercle-ellipse est l'exemple le plus connu de cette énigme.

Je suis catégoriquement en désaccord avec la plupart des réponses.

Voici ma réponse:

Étant donné deux ensembles G et H, une connexion de Galois (alpha, bêta) peut être définie entre eux, et l’on peut dire d’une concrétisation de l’autre; inverser la connexion, et l'un est une abstraction de l'autre. Les fonctions sont une fonction de concrétisation et une fonction d'abstraction.

Cela découle de la théorie de l'interprétation abstraite des programmes informatiques, qui est généralement une approche d'analyse statique à ce jour.

L'abstraction est davantage axée sur Whatet moins sur How. Ou vous pouvez dire, ne connaître que ce dont vous avez besoin et faire confiance au fournisseur pour tous les autres services. Parfois, il cache même l'identité du fournisseur de services.

Par exemple, ce site fournit un système pour poser des questions et y répondre. Presque tout le monde ici connaît la procédure à suivre pour demander, répondre, voter et autres choses de ce site. Mais très peu de gens savent quelles sont les technologies sous-jacentes. Par exemple, que le site ait été développé avec ASP.net mvc ou Python, qu'il soit exécuté sur un serveur Windows ou Linux, etc. Parce que cela ne fait pas partie de nos activités. Donc, ce site garde une couche d'abstraction sur son mécanisme sous-jacent pour nous fournir le service.

Quelques autres exemples:

• Une voiture cache tous ses mécanismes, mais fournit un moyen de conduire, de faire le plein et de l'entretenir à son propriétaire.

• Toute API masque tous ses détails d'implémentation fournissant le service aux autres programmeurs.

• Une classe en POO cache ses membres privés et la mise en œuvre de membres publics fournissant le service permettant d'appeler les membres publics.

• Lors de l'utilisation d'un objet de type Interfaceou abstract classen Java ou en C ++, l'implémentation réelle est masquée. Et non seulement cachée, les implémentations des méthodes déclarées dans le Interfacesont également susceptibles d'être différentes dans diverses classes implémentées / héritées. Mais comme vous obtenez le même service, ne vous inquiétez pas, Howil est mis en œuvre et fournit Who/ Whatfournit exactement le service.

• Identity Hiding : Pour la phrase "Je sais que Sam peut écrire des programmes informatiques". L'abstraction peut être- "Sam est un programmeur. Les programmeurs savent écrire des programmes informatiques." Dans la deuxième déclaration, la personne n'est pas importante. Mais sa capacité à faire de la programmation est importante.

Une abstraction de programmation est un modèle simplifié d'un problème.

Par exemple, une connexion TCP / IP est une abstraction sur l'envoi de données. Vous devez simplement inclure une adresse IP et un numéro de port et l'envoyer à l'API. Vous n'êtes pas concerné par tous les détails des fils, des signaux, des formats de message et des échecs.

Une abstraction n'est que la version de programmation d'un théorème.

Vous avez un système formel, vous proposez une réflexion sur ce système. Vous en faites une preuve, et si cela fonctionne, vous avez un théorème. Sachant que votre théorème est valable, vous pouvez ensuite l’utiliser dans d’autres preuves du système. Les primitives fournies par le système (comme les instructions if et les types de valeur int) seraient généralement considérées comme des axiomes, bien que cela ne soit pas strictement vrai, car tout ce qui ne correspond pas aux instructions de la CPU écrites en code machine est une sorte d'abstraction.

En programmation fonctionnelle, l'idée d'un programme en tant qu'énoncé mathématique est très forte et souvent, le système de typage (dans un langage fort et typé de manière statique comme Haskell, F # ou OCAML) peut être utilisé pour tester la théorie par des preuves.

Par exemple: supposons que nous ayons des vérifications d'addition et d'égalité en tant qu'opérations primitives, et des entiers et des booléens en tant que types de données primitifs. Ce sont nos axiomes. Nous pouvons donc dire que 1 + 3 == 2 + 2c'est un théorème, puis utiliser les règles d'addition et les nombres entiers et l'égalité pour voir si c'est une affirmation vraie.

Supposons maintenant que nous souhaitons une multiplication et que nos primitives (par souci de brièveté) incluent une construction en boucle et un moyen d’affecter des références symboliques. Nous pourrions suggérer que

ref x (*) y := loop y times {x +}) 0

Je vais prétendre avoir prouvé cela, en démontrant que la multiplication est valable. Maintenant, je peux utiliser la multiplication pour faire plus de choses avec mon système (le langage de programmation).

Je peux aussi vérifier mon système de types. (*) a un type d'int -> int -> int. Il prend 2 ints et sort un int. L'addition a un type d'int -> int -> int, de sorte que le 0 + (reste) est valide tant que (reste) résulte en un int. Ma boucle peut faire toutes sortes de choses, mais je dis qu'elle génère une chaîne de fonctions curry telle que (x + (x + (x ... + 0))) est le résultat. La forme de cette chaîne d'addition est juste (int -> (int -> (int ... -> int))), donc je sais que mon résultat final sera un int. Donc, mon système de types a retenu les résultats de mon autre preuve!

Compose ce genre d’idée pendant de nombreuses années, de nombreux programmeurs et de nombreuses lignes de code, et vous disposez de langages de programmation modernes: un ensemble copieux de primitives et d’énormes bibliothèques d’abstractions de code «éprouvées».

La réponse de Wikipedia serait-elle suffisante? http://en.wikipedia.org/wiki/Abstraction_%28programming%29

En informatique, le mécanisme et la pratique de l'abstraction se réduisent et suppriment les détails afin que l'on puisse se concentrer sur quelques concepts à la fois.

Eh bien, mathématiquement, "entier" est une abstraction. Et lorsque vous effectuez des preuves formelles telles que x + y = y + x pour tous les entiers, vous utilisez l'abstraction "entier" plutôt que des nombres spécifiques tels que 3 ou 4. La même chose se produit dans le développement logiciel lorsque vous interagissez avec le machine à un niveau supérieur aux registres et aux emplacements de mémoire. Vous pouvez penser à des pensées plus puissantes à un niveau plus abstrait, dans la plupart des cas.

Vous obtenez de bonnes réponses ici. Je ne ferais que mettre en garde - les gens pensent que l’abstraction est en quelque sorte cette chose merveilleuse qui doit être mise sur un piédestal et dont vous ne pouvez pas vous lasser. Ce n'est pas. C'est juste du bon sens. Il s'agit simplement de reconnaître les similitudes entre les choses, de sorte que vous pouvez appliquer une solution à un problème.

Permettez-moi une bête noire ...

En haut de ma liste d'ennuis, c'est quand les gens parlent de "couches d'abstraction" comme si c'était une bonne chose. Ils créent des "wrappers" autour de classes ou de routines qu'ils n'aiment pas et les appellent "plus abstraites", comme si cela les améliorerait. Rappelez-vous la fable de la "princesse au petit pois"? La princesse était si délicate que s'il y avait un pois sous son matelas, elle ne pourrait pas dormir, et ajouter plus de couches de matelas ne serait d'aucune aide. L'idée que l'ajout de plusieurs couches d '"abstraction" aidera, est juste comme ça - habituellement pas. Cela signifie simplement que toute modification de l'entité de base doit être générée par plusieurs couches de code.

Je pense que vous trouverez peut-être utile de publier un article de mon blog sur les abstractions qui fuient. Voici le fond pertinent:

L'abstraction est un mécanisme permettant de prendre ce qui est commun parmi un ensemble de fragments de programme liés, de supprimer leurs différences et de permettre aux programmeurs de travailler directement avec une construction représentant ce concept abstrait. Cette nouvelle construction (pratiquement) a toujours des paramétrisations : un moyen de personnaliser l’utilisation de la construction pour répondre à vos besoins spécifiques.

Par exemple, une Listclasse peut faire abstraction des détails d'une implémentation de liste chaînée - au lieu de penser en termes de manipulation nextet de previouspointeurs, vous pouvez envisager d'ajouter ou de supprimer des valeurs à une séquence. L'abstraction est un outil essentiel pour créer des caractéristiques utiles, riches et parfois complexes à partir d'un ensemble beaucoup plus petit de concepts plus primitifs.

L'abstraction est liée à l'encapsulation et à la modularité, et ces concepts sont souvent mal compris.

Dans l' Listexemple, l' encapsulation peut être utilisée pour masquer les détails d'implémentation d'une liste liée. dans un langage orienté objet, par exemple, vous pouvez rendre les nextet les previouspointeurs privés, seule l'implémentation de la liste étant autorisée à accéder à ces champs.

L'encapsulation n'est pas suffisante pour l'abstraction, car cela n'implique pas nécessairement que vous ayez une conception nouvelle ou différente des constructions. Si toute la Listclasse ne vous donnait que des méthodes d'accès de style ' getNext' setNext', elle encapsulerait à partir des détails de l'implémentation (par exemple, avez-vous nommé le champ' prev'ou' previous'? Quel était son type statique?), Mais aurait un très faible degré d'abstraction.

La modularité concerne la dissimulation d'informations : des propriétés stables sont spécifiées dans une interface, et un module implémente cette interface, en conservant tous les détails de la mise en œuvre dans le module. La modularité aide les programmeurs à faire face aux changements, car les autres modules ne dépendent que de l'interface stable.

L'encapsulation facilite la dissimulation d'informations (de sorte que votre code ne dépend pas de détails d'implémentation instables), mais l'encapsulation n'est pas nécessaire pour la modularité. Par exemple, vous pouvez mettre en œuvre une Liststructure C, ce qui expose les « next» et « prev» pointeurs au monde, mais aussi fournir une interface, contenant initList(),addToList() etremoveFromList()les fonctions. Si les règles de l'interface sont suivies, vous pouvez vous assurer que certaines propriétés seront toujours valables, par exemple en vous assurant que la structure de données est toujours dans un état valide. [Le document classique de Parnas sur la modularité, par exemple, a été écrit avec un exemple en assemblage. L'interface est un contrat et une forme de communication à propos de la conception, elle ne doit pas nécessairement être vérifiée mécaniquement, bien que nous en dépendions aujourd'hui.]

Bien que les termes abstraits, modulaires et encapsulés soient utilisés en tant que descriptions de conception positives, il est important de comprendre que la présence de l'une de ces qualités ne vous donne pas automatiquement une bonne conception:

• Si un algorithme n ^ 3 est "joliment encapsulé", il fonctionnera toujours moins bien qu'un algorithme amélioré de n log n.

• Si une interface est validée par un système d'exploitation spécifique, aucun des avantages d'une conception modulaire ne sera réalisé lorsque, par exemple, un jeu vidéo doit être transféré de Windows vers l'iPad.

• Si l'abstraction créée expose trop de détails non essentiels, elle ne pourra pas créer une nouvelle construction avec ses propres opérations: ce sera simplement un autre nom pour la même chose.

Ok, je pense avoir compris ce que vous demandez: "Qu'est-ce qu'une définition mathématiquement rigoureuse de" Une abstraction "?"

Si tel est le cas, je pense que vous n'avez pas de chance - "l'abstraction" est un terme d'architecture logicielle / design, et n'a aucun fondement mathématique à ma connaissance (peut-être que quelqu'un de plus expérimenté en informatique théorique pourra me corriger ici), pas plus que le "couplage" ou le "masquage d’informations" n’ont des définitions mathématiques.

L'abstraction consiste à ignorer des détails jugés non pertinents au profit de ceux jugés pertinents.

L'abstraction comprend l'encapsulation, la dissimulation d'informations et la généralisation. Il n'englobe pas les analogies, les métaphores ou les heuristiques.

Tout formalisme mathématique pour le concept d'abstraction serait lui - même être une abstraction, car il nécessiterait que la chose sous - jacente à résumer en un ensemble de propriétés mathématiques! La notion de morphisme de la théorie des catégories est probablement la plus proche de ce que vous recherchez.

L'abstraction n'est pas quelque chose que vous déclarez, c'est quelque chose que vous faites .

Pour expliquer cela à une autre personne, j'irais dans le sens inverse, à partir des résultats:

L'abstraction en programmation informatique consiste à généraliser quelque chose au point que plus d'une chose semblable peut généralement être traitée comme telle et traitée de la même manière.

Si vous souhaitez développer cela, vous pouvez ajouter:

Parfois, ceci est fait pour obtenir un comportement polymorphe (interfaces et héritage) afin de réduire le code répétitif au début, d'autres fois, cela est fait pour que le fonctionnement interne de quelque chose puisse être remplacé à une date ultérieure par une solution similaire sans avoir à modifier le code. code de l’autre côté du conteneur ou de l’emballage extrait, ce qui, espérons-le, réduira les retouches dans le futur.

Au-delà, je pense qu'il faut commencer par des exemples ...

Vous voudrez peut-être consulter certaines statistiques de Bob Martin

http://en.wikipedia.org/wiki/Software_package_metrics

Cela dit, je ne pense pas que son "Abstraction" soit la même que la vôtre. Son plus est une mesure de "manque d'implémentation sur une classe" qui signifie l'utilisation d'interfaces / classes abstraites. L'instabilité et la distance de la séquence principale jouent probablement davantage dans ce que vous recherchez.

Merriam-webster définit abstrait comme un être adjectif: dissocié de toute instance spécifique.

Une abstraction est un modèle de système. Ils énumèrent souvent un groupe d’hypothèses à respecter pour qu’un système réel puisse être modélisé par l’abstraction, et elles sont souvent utilisées pour permettre de conceptualiser des systèmes de plus en plus complexes. Passer d’un système réel à une abstraction n’a aucune méthode mathématique formelle pour le faire. C’est à la discrétion de quiconque définit l’abstraction et quel est le but de l’abstraction.

Souvent cependant, les abstractions sont définies en termes de constructions mathématiques. C'est probablement parce qu'ils sont si souvent utilisés en sciences et en génie.

Un exemple est la mécanique newtonienne. Cela suppose que tout est infiniment petit et que toute l'énergie est conservée. Les interactions entre les objets sont clairement définies par des formules mathématiques. Comme nous le savons, l’univers ne fonctionne pas vraiment de cette façon et, dans de nombreuses situations, l’abstraction s’échappe. Mais dans beaucoup de situations, cela fonctionne très bien.

Un autre modèle abstrait est constitué d'éléments de circuits linéaires, de résistances, de condensateurs et d'inductances typiques. Là encore, les interactions sont clairement définies par des formules mathématiques. Pour les circuits basse fréquence, les pilotes de relais simples, etc., l'analyse RLC fonctionne bien et donne de très bons résultats. Mais dans d’autres situations, telles que les circuits radio à micro-ondes, les éléments sont trop volumineux et les interactions plus fines, et les simples abstractions RLC ne tiennent pas. Ce qu’il faut faire à ce moment-là relève du jugement de l’ingénieur. Certains ingénieurs ont créé une autre abstraction parmi d’autres, certains remplaçant les amplis op idéaux par de nouvelles formules mathématiques pour leur fonctionnement, d’autres remplaçant les amplis op idéaux par des amplis op réels simulés, qui sont simulés à leur tour avec un réseau complexe de plus petits. éléments idéaux.

Comme d'autres l'ont dit, c'est un modèle simplifié. C'est un outil utilisé pour mieux comprendre les systèmes complexes.

Une abstraction représente quelque chose (par exemple un concept, une structure de données, une fonction) en termes d’autre chose. Par exemple, nous utilisons des mots pour communiquer. Un mot est une entité abstraite qui peut être représentée en termes de sons (parole) ou en termes de symboles graphiques (écriture). L'idée principale d'une abstraction est que l'entité en question est distincte de la représentation sous-jacente, tout comme un mot n'est pas le son utilisé pour la prononcer ni les lettres utilisées pour l'écrire.

Ainsi, au moins en théorie, la représentation sous-jacente d'une abstraction peut être remplacée par une représentation différente. En pratique, cependant, l'abstraction est rarement entièrement distincte de la représentation sous-jacente, et parfois, la représentation « fuit ». Par exemple, la parole comporte des nuances émotionnelles très difficiles à transmettre par écrit. De ce fait, un enregistrement audio et une transcription des mêmes mots peuvent avoir des effets très différents sur le public. En d'autres termes, l'abstraction des mots fuit souvent.

Les abstractions viennent généralement en couches. Les mots sont des abstractions qui peuvent être représentées par des lettres, qui sont à leur tour des abstractions de sons, qui sont à leur tour des abstractions du modèle de mouvement des particules d'air créées par les cordes vocales et détectées par les tympans. .

En informatique, les bits sont généralement le niveau de représentation le plus bas. Les octets, les emplacements de mémoire, les instructions d'assemblage et les registres de la CPU constituent le prochain niveau d'abstraction. Nous avons ensuite des types de données primitives et des instructions d'un langage de niveau supérieur, implémentées en termes d'octets, d'emplacements de mémoire et d'instructions d'assemblage. Puis les fonctions et les classes (en supposant un langage OO) qui sont implémentées en termes de types de données primitifs et d’instructions de langage intégrées. Ensuite, des fonctions et des classes plus complexes sont implémentées en termes de plus simples. Certaines de ces fonctions et classes implémentent des structures de données, telles que des listes, des piles, des files d'attente, etc. .

Une façon que j'essaie de décrire aux gens, peut-être pas la meilleure façon

Considérons un programme qui ajoute 2 + 2 et génère 4

Considérons un programme qui ajoute deux nombres saisis par un utilisateur, x + y = z

Lequel est le plus utile et le plus général?

Je dirais qu'une abstraction est quelque chose qui cache des détails inutiles. La procédure est l’une des unités les plus élémentaires de l’abstraction. Par exemple, je ne veux pas m'inquiéter de la façon dont je sauvegarde les données dans la base de données lorsque je lis ces données à partir d'un fichier. Je crée donc une fonction save_to_database.

Les abstractions peuvent également être jointes pour former de plus grandes abstractions. Par exemple, les fonctions peuvent être regroupées dans une classe, les classes peuvent être regroupées pour former un programme, les programmes peuvent être regroupés pour former un système distribué, etc.

Je pense toujours que l’abstraction dans la programmation cache des détails et offre une interface simplifiée. C'est la raison principale pour laquelle les programmeurs peuvent décomposer des tâches monumentales en éléments gérables. Avec l'abstraction, vous pouvez créer la solution à une partie du problème, y compris tous les détails importants, puis fournir une interface simple pour utiliser la solution. Vous pouvez alors "oublier" les détails. Ceci est important car il est impossible pour une personne de garder tous les détails d'un système super complexe à la fois. Cela ne veut pas dire que les détails sous l'abstraction ne devront jamais être revisités, mais pour le moment, seule l'interface doit être gardée en mémoire.

En programmation, cette interface simplifiée peut être une variable (extraire un groupe de bits et fournir une interface mathématique plus simple) à une fonction (extraire toute quantité de traitement en un seul appel de ligne) à une classe et au-delà.

En fin de compte, la tâche principale des programmeurs consiste à extraire généralement tous les détails du calcul et à fournir une interface simple, telle qu'une interface utilisateur graphique, à laquelle peut accéder une personne ignorant le fonctionnement de l'ordinateur.

Certains des avantages de l'abstraction sont:

• Permet à un gros problème d'être divisé en morceaux gérables. Lors de l'ajout d'enregistrements d'une personne à une base de données, vous ne voulez pas vous soucier d'insérer et d'équilibrer des arborescences d'index sur la base de données. Ce travail a peut-être été fait à un moment donné, mais a maintenant été résumé et vous n'avez plus à vous en soucier.

• Permet à plusieurs personnes de bien travailler ensemble sur un projet. Je ne veux pas avoir à connaître tous les tenants et les aboutissants du code de mon collègue. Je veux juste savoir comment l'utiliser, ce qu'il fait et comment l'adapter à mon travail (l'interface).

• Permet aux personnes ne disposant pas des connaissances requises d'effectuer une tâche complexe. Ma mère peut mettre à jour son facebook et les gens qu'elle connaît dans tout le pays peuvent le voir. Sans l'abstraction d'un système incroyablement complexe pour une simple interface Web, elle ne pourrait pas commencer à faire quelque chose de similaire (et je ne le ferais pas d'ailleurs).

L'abstraction peut toutefois avoir l'effet inverse de rendre les choses moins faciles à gérer si on en abuse. En divisant un problème en trop petits éléments, le nombre d'interfaces à mémoriser augmente et il est de plus en plus difficile de comprendre ce qui se passe réellement. Comme la plupart des choses, un équilibre doit être trouvé.

Un niveau supplémentaire d'indirection.

Vous ne voulez pas vous soucier de savoir si l'objet que vous utilisez est un Catou une Dogcible, vous devez donc parcourir une table de fonctions virtuelle pour trouver la bonne makeNoise()fonction.

Je suis sûr que cela pourrait également s’appliquer aux niveaux 'inférieur' et 'supérieur' - imaginez un compilateur recherchant la bonne instruction à utiliser pour un processeur donné ou le Monadrésumé de Haskell sur les effets de calcul en appelant tout returnet >>=.

C'est un sujet sur lequel je voulais en fait bloguer plus longtemps, mais je n'y suis jamais arrivé. Heureusement, je suis un représentant zombie et il y a même une prime. Mon post s'est avéré plutôt long , mais voici l'essentiel:

L'abstraction en programmation consiste à comprendre l'essence d'un objet dans un contexte donné.

[...]

L'abstraction est non seulement confondue avec la généralisation, mais également avec l'encapsulation, mais ce sont les deux parties orthogonales de la dissimulation d'informations: le module de service décide ce qu'il est disposé à montrer et le module client décide de ce qu'il est disposé à voir. L'encapsulation est la première partie et l'abstraction la dernière. Seuls les deux ensemble constituent une dissimulation complète d'informations.

J'espère que ça t'as aidé.

Ici, une réponse non mathématique:

Abandonner dans la programmation, c'est prétendre que vous ne vous souciez pas des détails maintenant, alors qu'en fait, vous devriez vous en soucier tout le temps. C'est fondamentalement faire semblant.

Pour moi, l'abstraction est quelque chose qui n'existe pas "littéralement", c'est plutôt une idée. Si vous l'exprimez mathématiquement, ce n'est plus abstrait car les mathématiques sont un langage qui permet d'exprimer ce qui se passe dans votre cerveau afin que le cerveau de quelqu'un puisse le comprendre. Vous ne pouvez donc pas structurer vos idées, car si vous le faites, ce n'est pas une idée plus: vous devez comprendre comment fonctionne un cerveau pour exprimer un modèle d’idée.

L'abstraction est quelque chose qui vous permet d'interpréter la réalité en quelque chose qui peut en être indépendant. Vous pouvez faire abstraction d’une plage et d’un rêve, mais la plage existe mais le rêve n’existe pas. Mais vous pouvez dire que les deux existent, mais ce n'est pas vrai.

Le plus difficile dans l’abstraction est de trouver un moyen de l’exprimer de manière à ce que d’autres personnes puissent le comprendre afin qu’il devienne réalité. C'est le travail le plus difficile, et cela ne peut pas vraiment être fait seul: vous devez inventer un modèle relatif qui fonctionne sur vos idées et qui peut être compris par quelqu'un d'autre.

Pour moi, l’abstraction en langage informatique doit être nommée "mathématiser" le modèle, il s’agit de réutiliser des idées pouvant être communiquées, et c’est une contrainte énorme par rapport à ce qui peut être réalisé de manière abstraite.

Pour le dire simplement, les atomes sont côte à côte, mais ils s'en moquent. Un grand ensemble de molécules organisées en un être humain peut comprendre qu'il est à côté de quelqu'un, mais il ne peut pas comprendre comment, c'est simplement comment les atomes se sont positionnés dans un motif.

Un objet qui est régi par un concept, en général, ne peut pas "comprendre" lui-même. C'est pourquoi nous essayons de croire en dieu et pourquoi nous avons du mal à comprendre notre cerveau.

Puis-je avoir ma médaille maintenant?

Question interessante. Je ne connais pas de définition unique de l'abstraction qui fasse autorité en matière de programmation. Bien que d’autres personnes aient fourni des liens vers des définitions issues de diverses branches de la théorie ou des mathématiques CS; J'aime y penser de la même manière que "superviser" voir http://en.wikipedia.org/wiki/Supervenience

Lorsque nous parlons d'abstraction en programmation, nous comparons essentiellement deux descriptions d'un système. Votre code est une description d'un programme. Une abstraction de votre code serait également une description de ce programme, mais à un niveau "supérieur". Bien entendu, votre abstraction d'origine peut être encore plus abstraite (par exemple, une description du programme dans une architecture système de haut niveau par rapport à la description du programme dans sa conception détaillée).

Maintenant, qu'est-ce qui rend une description "de niveau supérieur" à l'autre? La clé est la "réalisabilité multiple" - votre abstraction du programme pourrait être réalisée de nombreuses manières dans de nombreuses langues. Maintenant, vous pourriez dire qu’on pourrait aussi produire plusieurs conceptions pour un même programme - deux personnes pourraient produire deux conceptions de haut niveau différentes qui décrivent toutes les deux avec précision le programme. L'équivalence des réalisations fait la différence.

Lorsque vous comparez des programmes ou des conceptions, vous devez le faire de manière à pouvoir identifier les propriétés clés de la description à ce niveau. Vous pouvez entrer dans des manières compliquées de dire qu'une conception est équivalente à une autre, mais la façon la plus simple d'y penser est la suivante: un seul programme binaire peut-il satisfaire les contraintes des deux descriptions?

Alors, qu'est-ce qui fait qu'un niveau de description est supérieur à l'autre? Disons que nous avons un niveau de description A (par exemple, les documents de conception) et un autre niveau de description B (par exemple, le code source). A est de niveau supérieur à B car si A1 et A2 sont deux descriptions non équivalentes au niveau A, les réalisations de ces descriptions, B1 et B2, doivent également être non équivalentes au niveau B. Toutefois, l'inverse n'est pas nécessairement vrai. .

Donc, si je ne peux pas produire un seul programme binaire qui réponde à deux documents de conception distincts (les contraintes de ces conceptions se contrediraient), le code source qui implémente ces conceptions doit être différent. Par contre, si je prends deux ensembles de code source qui ne pourraient éventuellement pas être compilés dans le même programme binaire, il se pourrait que les fichiers binaires résultant de la compilation de ces deux ensembles de code source satisfassent tous deux la même conception. document. Ainsi, le document de conception est une "abstraction" du code source.

Les abstractions de programmation sont des abstractions faites par quelqu'un sur un élément de programmation. Disons que vous savez comment créer un menu avec ses éléments et autres choses. Ensuite, quelqu'un a vu cette partie de code et a pensé, hé, que cela pourrait être utile dans d'autres types de structures semblables à celle-ci, et a défini le modèle de conception de composant avec une abstraction de la première partie de code.

Les modèles de conception orientés objet sont un assez bon exemple de ce qu'est l'abstraction, et je ne parle pas de la mise en œuvre réelle, mais de la façon dont nous devrions aborder une solution.

Donc, pour résumer, programmer l’abstraction est une approche qui nous permet de comprendre un problème, c’est le moyen d’obtenir quelque chose, mais ce n’est pas la réalité.