Qu'est-ce que l'abstraction?
Existe-t-il une définition généralement acceptée de ce qu'est une abstraction de programmation, telle qu'utilisée par les programmeurs? [Remarque, la programmation de l'abstraction ne doit pas être confondue avec les définitions de dictionnaire du mot "abstraction".] Existe-t-il une définition univoque, voire mathématique? Quels sont des exemples clairs d'abstractions?
La réponse à "Pouvez-vous définir ce qu'est une abstraction de programmation 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 cependant: l'abstraction est le processus de passage d'une idée spécifique à une idée plus générale. Par exemple, jetez un œil à votre souris. Est-ce sans fil? De quel type de capteur dispose-t-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 les réponses, il s'agit toujours d'une souris, car il s'agit d'un dispositif 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 à penser 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 une Apple Magic Mouse ou une souris optique Dell ou une souris Microsoft IntelliMouse - "souris" est juste un concept abstrait.
L'abstraction peut être en couches et aussi fine ou grossière que vous le souhaitez (une MX518 est une souris, qui est un objet pointant, qui est un périphérique d'ordinateur, qui est un objet alimenté par l'électricité), peut aller aussi loin que vous le souhaitez , et dans pratiquement toutes les directions que vous voulez (ma souris a un fil, ce qui signifie que je pourrais le catégoriser comme un objet avec un fil. Il est également plat en bas, donc je pourrais le classer comme une sorte d'objets qui ne rouleront pas 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 elles. Bon OOP signifie choisir de bonnes abstractions au niveau de détail approprié qui ont du sens dans le domaine de votre programme et ne "fuient" pas. Le premier signifie que classer une souris comme un objet qui a gagné "Ne pas rouler sur un plan incliné n'a pas de sens pour une application qui inventorie du matériel informatique, mais cela peut avoir du sens pour un simulateur de physique. Ce dernier signifie que vous devriez essayer d'éviter de vous" enfermer "dans une hiérarchie qui ne fonctionne pas" t faire sens pour une sorte d'objets. Par exemple, dans ma hiérarchie ci-dessus, sommes-nous sûrs que tous les périphériques informatiques sont alimentés par l'électricité? Si nous voulons regrouper un stylet dans la catégorie "périphérique", nous aurions un problème, car il n'utilise pas d'électricité, et nous avons défini les périphériques d'ordinateur comme des objets qui utilisent l'électricité. Le cercle-ellipse problem 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 Galois (alpha, beta) peut être définie entre eux, et l'un peut être considéré comme 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 provient 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 met davantage l'accent sur What et moins sur How. Ou vous pouvez dire, ne connaître que les choses dont vous avez besoin et simplement faire confiance au fournisseur pour tous les autres services. Il cache même parfois 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 sait quelles sont les procédures pour demander, répondre, voter et autres choses sur ce site. Mais très peu savent quelles sont les technologies sous-jacentes. Comme si le site a été développé avec ASP.net mvc ou Python, que cela fonctionne sur un serveur Windows ou Linux, etc. Parce que cela ne nous regarde pas. Donc, ce site conserve 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 cache tous ses détails d'implémentation en fournissant le service à d'autres programmeurs.
Une classe dans OOP cache ses membres privés et l'implémentation des membres publics fournissant le service pour appeler les membres publics.
Lors de l'utilisation d'un objet de type d'un
Interfaceou d'unabstract classin Java ou C++, l'implémentation réelle est cachée. Et pas seulement cachée, les implémentations des méthodes déclarées dansInterfacesont également susceptibles d'être différentes dans les différentes implémentations/classes héritées. Mais comme vous obtenez le même service, ne dérangez pasHow, il est implémenté et exactementWho/Whatfournit le service.Masquage d'identité: 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 incluez simplement une adresse IP et un numéro de port et l'envoyez à 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 la preuve, et si ça marche, alors vous avez un théorème. Sachant que votre théorème est valable, vous pouvez ensuite l'utiliser dans d'autres preuves sur le système. Les primitives fournies par le système (comme les instructions if et les types de valeurs int) seraient généralement considérées comme des axiomes, bien que ce ne soit pas strictement vrai car tout ce qui n'est pas des instructions CPU écrites dans le 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 type (dans un langage fort typé statiquement comme Haskell, F # ou OCAML) peut être utilisé pour tester la théorème à travers des preuves.
Par exemple: disons que nous avons la vérification d'addition et d'égalité comme opérations primitives, et les entiers et booléens comme types de données primitifs. Ce sont nos axiomes. On peut donc dire que 1 + 3 == 2 + 2 est un théorème, puis utilisez les règles d'addition et d'entiers et d'égalité pour voir si c'est une vraie déclaration.
Supposons maintenant que nous voulons la multiplication, et nos primitives (par souci de concision) 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, démontrant que la multiplication tient. Maintenant, je peux utiliser la multiplication pour faire plus de choses avec mon système (le langage de programmation).
Je peux également vérifier mon système de saisie. (*) a un type d'int -> int -> int. Il prend 2 ints et sort un int. L'addition a un type d'int -> int -> int donc le 0 + (reste) tient aussi longtemps que (reste) donne un entier. Ma boucle pourrait faire toutes sortes de choses, mais je dis qu'elle génère une chaîne de fonctions curry telles 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 ma sortie finale sera un int. Donc, mon système de type a retardé les résultats de mon autre preuve!
Composez ce genre d'idée sur 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".
Vous obtenez de bonnes réponses ici. Je voudrais seulement mettre en garde - les gens pensent que l'abstraction est en quelque sorte cette chose merveilleuse qui doit être placée sur un piédestal, et dont vous ne pouvez pas vous en passer. 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 éventail de problèmes.
Permettez-moi une bête ...
En haut de ma liste de désagréments, c'est quand les gens parlent de "couches d'abstraction" comme si c'était une bonne chose. Ils font des "wrappers" autour de classes ou de routines qu'ils n'aiment pas, et les appellent "plus abstraits", comme si cela les rendrait meilleurs. Rappelez-vous la fable de la "Princesse et le pois"? La princesse était si délicate que s'il y avait un pois sous son matelas, elle ne pourrait pas dormir, et l'ajout de plusieurs couches de matelas n'aiderait pas. L'idée que l'ajout de couches supplémentaires d '"abstraction" vous aidera est exactement comme ça - ce n'est généralement pas le cas. Cela signifie simplement que toute modification apportée à l'entité de base doit être répercutée sur plusieurs couches de code.
Je pense que vous pourriez trouver un article de blog à moi sur les abstractions qui fuient utile. Voici le contexte pertinent:
L'abstraction est un mécanisme qui permet de prendre ce qui est commun à un ensemble de fragments de programme associé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 a (virtuellement) toujours paramétrisations : un moyen de personnaliser l'utilisation de la construction en fonction de vos besoins spécifiques.
Par exemple, une classe List peut résumer les détails d'une implémentation de liste chaînée - où au lieu de penser en termes de manipulation des pointeurs next et previous, vous pouvez penser au niveau de l'ajout ou de la suppression de valeurs à une séquence. L'abstraction est un outil essentiel pour créer des fonctionnalités 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'exemple List, l'encapsulation peut être utilisée pour masquer les détails d'implémentation d'une liste chaînée; dans un langage orienté objet, par exemple, vous pouvez rendre les pointeurs next et previous privés, où seule l'implémentation List est autorisée à accéder à ces champs.
L'encapsulation n'est pas suffisante pour l'abstraction, car elle n'implique pas nécessairement que vous ayez une conception nouvelle ou différente des constructions. Si tout ce qu'une classe List faisait était de vous donner des méthodes d'accesseur de style 'getNext'/'setNext', elle s'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 il aurait un très faible degré d'abstraction.
La modularité concerne le masquage des informations : les propriétés stables sont spécifiées dans une interface et un module implémente cette interface, en conservant tous les détails d'implémentation dans le module. La modularité aide les programmeurs à faire face au changement, car les autres modules ne dépendent que de l'interface stable.
Le masquage des informations est facilité par l'encapsulation (de sorte que votre code ne dépend pas des détails d'implémentation instables), mais l'encapsulation n'est pas nécessaire pour la modularité. Par exemple, vous pouvez implémenter une structure List en C, exposant les pointeurs 'next' et 'prev' au monde, mais également fournir une interface contenant initList(), addToList() et removeFromList(). À condition que les règles de l'interface soient respectées, vous pouvez garantir que certaines propriétés seront toujours valides, par exemple en vous assurant que la structure de données est toujours dans un état valide. [Le papier classique de Parnas sur la modularité, par exemple, a été écrit avec un exemple dans Assembly. L'interface est un contrat et une forme de communication sur la conception, elle ne doit pas nécessairement être vérifiée mécaniquement, bien que ce soit ce sur quoi nous comptons aujourd'hui.]
Bien que des termes comme abstrait, modulaire et encapsulé soient utilisés comme descriptions de conception positives, il est important de réaliser 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 "bien encapsulé", il fonctionnera toujours moins bien qu'un algorithme n log n amélioré.
Si une interface s'engage sur 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 porté de Windows vers l'iPad.
Si l'abstraction créée expose trop de détails inutiles, elle ne parviendra pas à créer une nouvelle construction avec ses propres opérations: ce sera simplement un autre nom pour la même chose.
La réponse de Wikipédia serait-elle assez bonne? http://en.wikipedia.org/wiki/Abstraction_%28programming%29
En informatique, le mécanisme et la pratique de l'abstraction réduisent et factorisent les détails pour que l'on puisse se concentrer sur quelques concepts à la fois.
Eh bien, mathématiquement, "entier" est une abstraction. Et quand vous faites des preuves formelles comme ça x + y = y + x pour tous les entiers, vous travaillez avec l'abstraction "entier" plutôt qu'avec des nombres spécifiques comme 3 ou 4. Cette même chose se produit dans le développement de logiciels 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.
Pour l'expliquer à une autre personne, je ferais l'inverse, à partir des résultats:
L'abstraction dans la programmation informatique est l'acte de généraliser quelque chose au point que plus d'une chose similaire peut généralement être traitée comme la même et traitée de la même manière.
Si vous souhaitez développer cela, vous pouvez ajouter:
Parfois, cela est fait pour obtenir un comportement polymorphe (interfaces et héritage) afin de réduire le code répétitif à l'avance, d'autres fois, il 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 de l'autre côté du conteneur ou de l'emballage abstrait, en espérant réduire les retouches à l'avenir.
Au-delà de cela, je pense que vous devez commencer par des exemples ...
L'abstraction consiste à ignorer les détails jugés non pertinents au profit de ceux jugés pertinents.
L'abstraction englobe l'encapsulation, la dissimulation d'informations et la généralisation. Il ne comprend pas les analogies, les métaphores ou les heuristiques.
Tout formalisme mathématique pour le concept d'abstraction serait lui-même soit une abstraction, car il faudrait nécessairement que la chose sous-jacente soit abstraite dans un ensemble de propriétés mathématiques! La notion de catégorie-théorie d'un morphisme 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 .
Ok, je pense que j'ai 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 - 'abstraction' est un terme d'architecture/conception logicielle, et n'a aucun support mathématique à ma connaissance (peut-être que quelqu'un de mieux versé en CS théorique me corrigera ici), pas plus que le "couplage" ou la "dissimulation d'informations" n'ont de définitions mathématiques.
Je pense toujours à l'abstraction dans la programmation comme cachant des détails et fournissant une interface simplifiée. C'est la principale raison pour laquelle les programmeurs peuvent décomposer des tâches monumentales en morceaux gérables. Avec l'abstraction, vous pouvez créer la solution à une partie du problème, y compris tous les détails précis, puis fournir une interface simple pour utiliser la solution. Ensuite, vous pouvez en effet "oublier" les détails. C'est important car il n'y a aucun moyen qu'une personne puisse garder tous les détails d'un système super complexe dans son esprit à 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 mémorisée.
En programmation, cette interface simplifiée peut être n'importe quoi d'une variable (résume un groupe de bits et fournit une interface mathématique plus simple) à une fonction (résume toute quantité de traitement en un seul appel de ligne) à une classe et au-delà.
En fin de compte, le travail principal des programmeurs est généralement d'abstraire tous les détails de calcul et de fournir une interface simple comme une interface graphique que quelqu'un qui ne sait pas une chose sur le fonctionnement des ordinateurs peut utiliser.
Certains des avantages de l'abstraction sont:
Permet de décomposer un gros problème en morceaux gérables. Lorsque vous ajoutez des enregistrements d'une personne à une base de données, vous ne voulez pas avoir à vous soucier de l'insertion et de l'équilibrage des arborescences d'index sur la base de données. Ce travail a peut-être été fait à un moment donné, mais maintenant il a é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 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 qui n'ont pas les connaissances requises d'effectuer une tâche complexe pour le faire. Ma maman peut mettre à jour son facebook et les gens qu'elle connaît partout au pays peuvent le voir. Sans l'abstraction d'un système incroyablement complexe à une simple interface Web, il n'y a aucun moyen qu'elle puisse commencer à faire quelque chose de similaire (ni d'ailleurs d'ailleurs).
L'abstraction peut cependant avoir l'effet inverse de rendre les choses moins gérables si elle est surutilisée. En décomposant un problème en trop de petits morceaux, le nombre d'interfaces dont vous vous souvenez augmente et il devient plus difficile de comprendre ce qui se passe réellement. Comme la plupart des choses, un équilibre doit être trouvé.
Une façon dont j'essaie de le décrire aux gens, n'est peut-être pas la meilleure façon
Considérons un programme qui ajoute 2 + 2 et produit 4
Considérons un programme qui ajoute deux nombres saisis par un utilisateur, x + y = z
Qu'est-ce qui est le plus utile et le plus général?
Je dirais qu'une abstraction est quelque chose qui cache des détails inutiles. L'une des unités d'abstraction les plus élémentaires est la procédure. Par exemple, je ne veux pas m'inquiéter de la façon dont j'enregistre les données dans la base de données lorsque je lis ces données dans un fichier. Je crée donc une fonction save_to_database.
Les abstractions peuvent également être réunies 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.
C'est quelque chose que je voulais en fait bloguer depuis plus longtemps, mais je n'y suis jamais arrivé. Heureusement, je suis un zombie représentant et il y a même une prime. Mon message s'est avéré assez long , mais voici l'essentiel:
L'abstraction en programmation consiste à comprendre l'essence d'un objet dans un contexte donné.
[...]
L'abstraction n'est pas seulement confondue avec la généralisation, mais aussi 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 ce qu'il est disposé à voir. L'encapsulation est la première partie et l'abstraction la seconde. Seuls les deux ensemble constituent une dissimulation complète des informations.
J'espère que cela pourra aider.
Un niveau d'indirection supplémentaire.
Vous ne voulez pas vous soucier de savoir si l'objet que vous utilisez est un Cat ou un Dog, vous parcourez donc une table de fonction virtuelle pour trouver la bonne makeNoise() une fonction.
Je suis sûr que cela pourrait également être appliqué à des niveaux "inférieurs" et "supérieurs" - pensez à un compilateur recherchant la bonne instruction à utiliser pour un processeur donné ou aux Monads de Haskell abstrait sur les effets de calcul en appelant tout return et >>=.
Vous voudrez peut-être vérifier certaines des mesures de Bob Martin
http://en.wikipedia.org/wiki/Software_package_metrics
Cela dit, je ne pense pas que son "abstrait" soit le même que le vôtre. Il s'agit davantage d'une mesure du "manque d'implémentation sur une classe", c'est-à-dire de l'utilisation d'interfaces/classes abstraites. L'instabilité et la distance de la séquence principale jouent probablement plus dans ce que vous recherchez.
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 clé d'une abstraction est que l'entité en question est distincte de la représentation sous-jacente, tout comme un mot n'est pas les sons qui sont utilisés pour le prononcer ou les lettres qui sont 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 " fuites " à travers. Par exemple, la parole comporte des nuances émotionnelles qui sont 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 se présentent généralement en couches. Les mots sont des abstractions qui peuvent être représentées par des lettres, qui à leur tour sont elles-mêmes des abstractions de sons, qui sont à leur tour des abstractions du schéma 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 CPU sont le prochain niveau d'abstraction. Ensuite, nous avons des types de données primitifs et des instructions d'un langage de niveau supérieur, qui sont implémentés en termes d'octets, d'emplacements de mémoire et d'instructions d'assemblage. Ensuite, les fonctions et classes (en supposant un OO langage) qui sont implémentées en termes de types de données primitifs et d'instructions de langage intégrées. Ensuite, les fonctions et classes plus complexes sont implémentées en termes de plus simples. Certains de ces fonctions et classes implémentent des structures de données, telles que des listes, des piles, des files d'attente, etc. Celles-ci sont à leur tour utilisées pour représenter des entités plus spécifiques telles qu'une file d'attente de processus, ou une liste d'employés, ou une table de hachage des titres de livres. Dans ce schéma, chaque niveau est une abstraction par rapport à son prédécesseur.
Merriam-webster définit l'abstrait comme un être adjectif: dissocié de toute instance spécifique.
Une abstraction est un modèle d'un système. Ils énumèrent souvent un groupe d'hypothèses qui doivent être satisfaites pour qu'un système réel puisse être modélisé par l'abstraction, et ils sont souvent utilisés pour nous permettre de conceptualiser des systèmes de plus en plus compliqués. Passer d'un système réel à une abstraction n'a pas de méthode mathématique formelle pour le faire. Cela dépend du jugement de celui qui 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 science et en génie.
Un exemple est la mécanique newtonienne. Il 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. Maintenant, comme nous le savons, l'univers ne fonctionne pas tout à fait de cette façon, et dans de nombreuses situations, l'abstraction s'infiltre. 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. Encore une fois, les interactions sont clairement définies par des formules mathématiques. Pour les circuits basse fréquence ou les pilotes de relais simples et autres, l'analyse RLC fonctionne bien et fournit de très bons résultats. Mais d'autres situations, comme les circuits radioélectriques hyperfréquences, les éléments sont trop gros, les interactions sont plus fines et les abstractions RLC simples ne tiennent pas. Ce qu'il faut faire à ce stade dépend du jugement de l'ingénieur. Certains ingénieurs ont créé une autre abstraction au-dessus des autres, certains remplaçant les amplificateurs opérationnels idéaux par de nouvelles formules mathématiques pour leur fonctionnement, d'autres remplacent les amplificateurs opérationnels idéaux par des amplificateurs opérationnels réels simulés, qui à leur tour sont simulés avec un réseau complexe de plus petits éléments idéaux.
Comme d'autres l'ont dit, il s'agit d'un modèle simplifié. C'est un outil utilisé pour mieux comprendre les systèmes complexes.
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 ses trucs. Ensuite, quelqu'un a vu ce morceau de code et a pensé, hé qui pourrait être utile dans d'autres types de structures de type hireachy, et a défini le modèle de conception de composant avec une abstraction du premier morceau 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, la programmation de 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 vraie chose
Pour moi, l'abstraction est quelque chose qui n'existe pas "littéralement", c'est quelque chose comme une idée. Si vous l'exprimez mathématiquement, ce n'est plus abstrait parce que les mathématiques sont un langage pour exprimer ce qui se passe dans votre cerveau afin qu'il puisse être compris par le cerveau de quelqu'un d'autre, donc vous ne pouvez pas structurer vos idées, car si vous le faites, ce n'est pas une idée plus: vous auriez besoin de 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 on pourrait dire que les deux existent, mais ce n'est pas vrai.
La chose la plus difficile dans l'abstraction est de trouver un moyen de l'exprimer pour que les autres puissent le comprendre afin qu'il puisse devenir réalité. C'est le travail le plus difficile, et cela ne peut pas vraiment se faire 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 devrait s'appeler "mathématiser" le modèle, il s'agit de réutiliser des idées qui peuvent être communiquées, et c'est une énorme contrainte 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 juste la façon dont les atomes se sont positionnés selon un modèle.
Un objet qui est régi par un concept, en général, ne peut pas "se 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?
Ici, une réponse non mathématique:
Abtracting away dans la programmation, c'est prétendre que vous ne vous souciez plus des détails maintenant, alors qu'en fait vous le faites et vous devriez vous en soucier tout le temps. C'est essentiellement faire semblant.
Question interessante. Je ne connais pas de définition unique de l'abstraction considérée comme faisant autorité en matière de programmation. Bien que d'autres personnes aient fourni des liens vers certaines définitions de diverses branches de la théorie CS ou des mathématiques; J'aime y penser d'une manière similaire à "supervenience" voir http://en.wikipedia.org/wiki/Supervenience
Lorsque nous parlons d'abstraction dans la 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 sûr, vous pouvez avoir une abstraction de niveau encore plus élevé de votre abstraction d'origine (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 fait qu'une description est "de niveau supérieur" qu'une autre. La clé est la "réalisabilité multiple" - votre abstraction du programme pourrait être réalisée de plusieurs manières dans de nombreuses langues. Maintenant, vous pourriez dire que l'on pourrait également produire plusieurs conceptions pour un seul programme - deux personnes pourraient produire deux conceptions de haut niveau différentes qui décrivent toutes 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 d'une manière qui vous permette d'identifier les propriétés clés de la description à ce niveau. Vous pouvez entrer dans des façons 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 programme binaire unique peut-il satisfaire les contraintes des deux descriptions?
Alors, qu'est-ce qui rend un niveau de description plus élevé que 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 un niveau supérieur à B car si A1 et A2 sont deux descriptions non équivalentes au niveau A, alors les réalisations de ces descriptions, B1 et B2 doivent également être non équivalent au niveau B. Cependant, l'inverse n'est pas nécessairement vrai.
Donc, si je ne peux pas produire un seul programme binaire qui satisfasse deux documents de conception distincts (c'est-à-dire que les contraintes de ces conceptions se contrediraient), alors le code source qui implémente ces conceptions doit être différent. Mais d'un autre côté, si je prends deux ensembles de code source qui ne pourraient pas être compilés dans le même programme binaire, il se pourrait tout de même que les 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.