Esiste una definizione generalmente condivisa su cosa sia una astrazione di programmazione , come viene usata dai programmatori? [Nota, l'astrazione di programmazione non deve essere confusa con le definizioni del dizionario per la parola "astrazione".] Esiste una definizione non ambigua o addirittura matematica? Quali sono alcuni esempi chiari di astrazioni?
La risposta a "Puoi definire cosa un'astrazione di programmazione è più o meno matematicamente?" è no." L'astrazione non è un concetto matematico. Sarebbe come chiedere a qualcuno di spiegare matematicamente il colore di un limone.
Se vuoi una buona definizione: l'astrazione è il processo di passaggio da un'idea specifica a una più generale. Ad esempio, dai un'occhiata al tuo mouse. È wireless? Che tipo di sensore ha? Quanti pulsanti? È ergonomico? Quanto è grande? Le risposte a tutte queste domande possono descrivere con precisione il mouse, ma indipendentemente da quali siano le risposte, è pur sempre un mouse, perché è un dispositivo di puntamento con pulsanti. È tutto ciò che serve per essere un topo. "Silver Logitech MX518" è un oggetto concreto e specifico e il "mouse" ne è un'astrazione. Una cosa importante da considerare è che non esiste un tale oggetto concreto come un "mouse", è solo un'idea. Il mouse sulla tua scrivania è sempre qualcosa di più specifico: è un mouse Apple Magic Mouse o un mouse ottico Dell o un Microsoft IntelliMouse - il "mouse" è solo un concetto astratto.
L'astrazione può essere stratificata e a grana fine o grossa come vuoi (un MX518 è un mouse, che è un oggetto di puntamento, che è una periferica del computer, che è un oggetto alimentato da elettricità), può andare lontano come vuoi, e praticamente in qualsiasi direzione tu voglia (il mio mouse ha un filo, il che significa che posso categorizzarlo come un oggetto con un filo. È anche piatto sul fondo, quindi posso categorizzarlo come una specie di oggetto che ha vinto " t roll se posizionato verticalmente su un piano inclinato).
La programmazione orientata agli oggetti è costruita sul concetto di astrazioni e famiglie o gruppi di essi. Un buon OOP significa scegliere buone astrazioni al livello appropriato di dettaglio che ha senso nel dominio del tuo programma e non "perdita". Il primo vuol dire che classificare un mouse come un oggetto che non rotolerà su un piano inclinato non ha senso per un'applicazione che inventaria le apparecchiature informatiche, ma potrebbe avere senso per un simulatore di fisica. Quest'ultimo significa che dovresti cercare di evitare di "inscatolare te stesso" in una gerarchia che non ha senso per alcuni tipi di oggetti. Ad esempio, nella mia gerarchia di cui sopra, siamo sicuri che le tutte periferiche per computer sono alimentate dall'elettricità? Che mi dici di uno stilo? Se vogliamo raggruppare uno stilo nella categoria "periferica", avremmo un problema, perché non utilizza l'elettricità, e abbiamo definito le periferiche del computer come oggetti che usano l'elettricità. Il problema dell'ellisse circolare è l'esempio più noto di questo enigma.
Sono categoricamente in disaccordo con la maggior parte delle risposte.
Questa è la mia risposta:
Given two sets G and H, a Galois connection (alpha, beta) can be defined between them, and one can be said to be a concretization of the other; reverse the connection, and one is an abstraction of the other. The functions are a concretization function and an abstraction function.
Questo deriva dalla teoria dell'interpretazione astratta dei programmi per computer, che in genere è un approccio di analisi statica fino ad oggi.
L'astrazione è più focalizzata su What e meno su How . Oppure puoi dire, conoscere solo le cose che ti servono e fidarti solo del provider per tutti gli altri servizi. A volte nasconde persino l'identità del fornitore di servizi.
Ad esempio, questo sito fornisce un sistema per porre domande e rispondervi. Quasi tutti qui sanno quali sono le procedure per chiedere, rispondere, votare e altre cose di questo sito. Ma pochissimi sanno quali sono le tecnologie di base. Ad esempio se il sito è stato sviluppato con ASP.net mvc o Python, indipendentemente dal fatto che sia eseguito su un server Windows o Linux ecc. Perché non è affar nostro. Quindi, questo sito sta mantenendo un livello di astrazione sul meccanismo sottostante per fornire il servizio.
Alcuni altri esempi:
Un'auto nasconde tutti i suoi meccanismi ma fornisce un modo per guidare, rifornire di carburante e mantenerla al suo proprietario.
Qualsiasi API nasconde tutti i dettagli di implementazione che forniscono il servizio ad altri programmatori.
Una classe in OOP nasconde i suoi membri privati e l'implementazione di membri pubblici che forniscono il servizio per chiamare i membri pubblici.
Mentre si utilizza un oggetto di tipo Interface o abstract class in Java o C ++, l'implementazione reale è nascosta. E non solo nascosto, anche le implementazioni dei metodi dichiarati in Interface sono probabilmente diverse in varie classi implementate / ereditate. Ma poiché stai ricevendo lo stesso servizio, non ti preoccupare del fatto che How è implementato e esattamente Who / What sta fornendo il servizio.
Nascondere identità : per la frase "So che Sam può scrivere programmi per computer". l'astrazione può essere ... "Sam è un programmatore, i programmatori sanno come scrivere programmi per computer". Nella seconda affermazione, la persona non è importante. Ma la sua capacità di fare programmazione è importante.
Un'astrazione di programmazione è un modello semplificato di un problema.
Ad esempio, una connessione TCP / IP è un'astrazione sull'invio di dati. Basta includere un indirizzo IP e un numero di porta e inviarlo all'API. Non sei interessato a tutti i dettagli di fili, segnali, formati dei messaggi e guasti.
Un'astrazione è solo la versione di programmazione di un teorema.
Hai un sistema formale, proponi un pensiero su quel sistema. Ne fai una dimostrazione e, se funziona, hai un teorema. Sapendo che il tuo teorema è valido, puoi usarlo in ulteriori prove sul sistema. I primitivi forniti dal sistema (come se le istruzioni e i tipi di valore int) sarebbero tipicamente visti come assiomi, sebbene ciò non sia strettamente vero poiché qualsiasi cosa che non sia istruzioni della CPU scritte in codice macchina è una sorta di astrazione.
Nella programmazione funzionale, l'idea di un programma come affermazione matematica è molto strong e spesso il sistema di tipi (in un linguaggio strong, tipizzato staticamente come Haskell, F # o OCAML) può essere usato per testare la teorema attraverso le prove.
Ad esempio: diciamo che abbiamo l'addizione e il controllo di uguaglianza come operazioni primitive, e interi e booleani come tipi di dati primitivi. Questi sono i nostri assiomi. Quindi possiamo dire che 1 + 3 == 2 + 2 è un teorema, quindi utilizzare le regole di addizione, interi e uguaglianza per vedere se questa è una vera affermazione.
Ora supponiamo di volere la moltiplicazione, ei nostri primitivi (per brevità) includono un costrutto ciclico e un mezzo per assegnare riferimenti simbolici. Potremmo suggerire che
ref x (*) y := loop y times {x +}) 0
Farò finta di averlo dimostrato, dimostrando che la moltiplicazione è valida. Ora posso usare la moltiplicazione per fare più cose con il mio sistema (il linguaggio di programmazione).
Posso anche controllare il mio sistema di tipi. (*) ha un tipo di int - > int - > Int. Prende 2 int e genera un int. L'aggiunta ha un tipo di int - > int - > int così lo 0 + (resto) tiene fino a quando (resto) risulta in un int. Il mio ciclo potrebbe fare ogni genere di cose, ma sto dicendo che emette una catena di funzioni elaborate tale che (x + (x + (x ... + 0))) è il risultato. La forma di quella catena di addizione è solo (int - > (int - > (int ... - > int))) quindi so che il mio output finale sarà un int. Quindi il mio sistema di tipi ha tenuto sotto controllo i risultati della mia altra prova!
Componi questo tipo di idea per molti anni, molti programmatori e molte linee di codice, e hai i moderni linguaggi di programmazione: un ricco insieme di primitive e enormi librerie di astrazioni di codice "provate".
Beh, matematicamente, "intero" è un'astrazione. E quando fai prove formali come quella x + y = y + x per tutti gli interi, stai lavorando con l'astrazione "intero" piuttosto che con numeri specifici come 3 o 4. La stessa cosa accade nello sviluppo del software quando interagisci con il macchina a un livello sopra registri e posizioni di memoria. Puoi pensare pensieri più potenti a un livello più astratto, nella maggior parte dei casi.
Qui trovi buone risposte. Vorrei solo fare attenzione - la gente pensa che l'astrazione sia in qualche modo questa cosa meravigliosa che deve essere messa su un piedistallo, e che non ne puoi mai abbastanza. Non è. È solo buon senso. Sta solo riconoscendo le somiglianze tra le cose, quindi puoi applicare una soluzione problema a una serie di problemi.
Permettimi un pensiero ...
In cima alla mia lista di fastidi è quando le persone parlano di "strati di astrazione" come se fosse una buona cosa. Fanno "wrapper" attorno a classi o routine che non gli piacciono, e li chiamano "più astratti", come se ciò li renderebbe migliori. Ricorda la favola della "Principessa e il Pisello"? La principessa era così delicata che se c'era un pisello sotto il materasso non sarebbe stata in grado di dormire, e aggiungere altri strati di materassi non sarebbe stato d'aiuto. L'idea che aggiungere ulteriori livelli di "astrazione" aiuterà è proprio così, di solito non è così. Significa semplicemente che qualsiasi modifica all'entità di base deve essere rippled attraverso più livelli di codice.
Penso che potresti trovare un post di blog del mio su perdente astrazioni utili. Ecco lo sfondo pertinente:
Abstraction è un meccanismo per aiutare a prendere ciò che è comune tra un gruppo di frammenti di programma correlati, rimuovere le loro differenze e consentire ai programmatori di lavorare direttamente con un costrutto che rappresenta quel concetto astratto. Questo nuovo costrutto (virtualmente) ha sempre parametrizzazioni : un mezzo per personalizzare l'uso del costrutto in base alle tue esigenze specifiche.
Ad esempio, una classe List può astrarre i dettagli di un'implementazione di liste collegate-- dove invece di pensare in termini di manipolazione di next e previous puntatori, puoi pensare al livello di aggiunta o rimuovendo valori in una sequenza. L'astrazione è uno strumento essenziale per creare utili, ricche e talvolta complesse funzionalità da un insieme molto più piccolo di concetti più primitivi.
L'astrazione è legata all'incapsulamento e alla modularità e questi concetti sono spesso fraintesi.
Nell'esempio List , incapsulamento può essere utilizzato per nascondere i dettagli di implementazione di una lista concatenata; in un linguaggio orientato agli oggetti, ad esempio, puoi rendere privati i puntatori next e previous , in cui solo l'implementazione Elenco può accedere a questi campi.
L'incapsulamento non è sufficiente per l'astrazione, perché non implica necessariamente una concezione nuova o diversa dei costrutti. Se tutta la classe List ha dato i metodi di accesso allo stile ' getNext ' / ' setNext ', verrebbe incapsulata dai dettagli dell'implementazione (ad esempio, hai nominato il campo ' prev ' o ' previous '? qual era il suo tipo statico?), ma avrebbe un grado di astrazione molto basso.
Modularità si occupa di nascondere le informazioni : le proprietà stabili sono specificate in un'interfaccia e un modulo implementa tale interfaccia, mantenendo tutti i dettagli di implementazione all'interno del modulo. La modularità aiuta i programmatori ad affrontare le modifiche, perché gli altri moduli dipendono solo dall'interfaccia stabile.
L'occultamento delle informazioni è facilitato dall'incapsulazione (in modo che il codice non dipenda da dettagli di implementazione instabili), ma l'incapsulamento non è necessario per la modularità. Ad esempio, puoi implementare una struttura List in C, esponendo i puntatori ' next ' e ' prev ' al mondo, ma fornisci anche un'interfaccia, contenente initList() , addToList() e removeFromList() funzioni. A condizione che le regole dell'interfaccia vengano seguite, è possibile garantire che determinate proprietà rimarranno sempre valide, ad esempio garantendo che la struttura dei dati sia sempre in uno stato valido. [La carta classica di Parna sulla modularità, per esempio, è stata scritta con un esempio in assemblea. L'interfaccia è un contratto e una forma di comunicazione sul design, non deve necessariamente essere controllata meccanicamente, anche se è quello su cui ci basiamo oggi.]
Sebbene termini come astratti, modulari e incapsulati siano usati come descrizioni positive del design, è importante rendersi conto che la presenza di una di queste qualità non ti dà automaticamente un buon design:
Se un algoritmo n ^ 3 è "ben incapsulato", funzionerà ancora peggio di un algoritmo n log n migliorato.
Se un'interfaccia si impegna su uno specifico sistema operativo, nessuno dei vantaggi di un design modulare sarà realizzato quando, per esempio, un videogioco deve essere trasferito da Windows all'iPad.
Se l'astrazione creata espone troppi dettagli inessenziali, non riuscirà a creare un nuovo costrutto con le proprie operazioni: sarà semplicemente un altro nome per la stessa cosa.
Ok, penso di aver capito cosa stai chiedendo: "Cos'è una definizione matematicamente rigorosa di 'An Abstraction."
Se è così, penso che tu sia sfortunato- "astrazione" è un termine di architettura / design del software, e non ha alcun supporto matematico per quanto ne so (forse qualcuno più esperto di CS teorico mi correggerà qui), più che "accoppiamento" o "occultamento dell'informazione" hanno definizioni matematiche.
L'astrazione è quando ignori i dettagli ritenuti irrilevanti a favore di quelli ritenuti rilevanti.
L'astrazione racchiude l'incapsulamento, l'occultamento delle informazioni e la generalizzazione. Non comprende analogie, metafore o euristiche.
Qualsiasi formalismo matematico per il concetto di astrazione sarebbe di per sé essere un'astrazione, poiché richiederebbe necessariamente che la cosa sottostante sia astratta in un insieme di proprietà matematiche! La nozione di teoria della categoria di un morfismo è probabilmente la più vicina a ciò che stai cercando.
L'astrazione non è qualcosa che dichiari, è qualcosa che fai .
Per spiegarlo a un'altra persona, andrei da un'altra parte, dai risultati precedenti:
Abstraction in computer programming is the act of generalizing something to the point that more than one similar thing can be generally treated as the same and handled the same.
Se vuoi espanderci, puoi aggiungere:
Sometimes this is done to achieve polymorphic behavior (interfaces and inheritance) to cut down on repetitive code up front, other times it is done so that the inner workings of something could be replaced at a future date with a similar solution without having to alter the code on the other side of the abstracted container or wrapper, hopefully cutting down on rework in the future.
Oltre a ciò, penso che devi iniziare con degli esempi ...
Potresti voler controllare alcune metriche di Bob Martin
Detto questo, non penso che il suo "Abstractness" sia uguale al tuo. La sua è più una misura della "mancanza di implementazione su una classe" che significa uso di interfacce / classi astratte. Instabilità e distanza dalla sequenza principale probabilmente giocano più a ciò che stai cercando.
Merriam-webster definisce astratto come un aggettivo essendo: dissociato da qualsiasi istanza specifica.
Un'astrazione è un modello di alcuni sistemi. Spesso elencano un gruppo di presupposti che devono essere soddisfatti affinché un sistema reale possa essere modellato dall'astrazione, e sono spesso utilizzati per concettualizzare sistemi sempre più complicati. Passare da un sistema reale a un'astrazione non ha alcun metodo matematico formale per farlo. Questo dipende dal giudizio di chi sta definendo l'astrazione e qual è lo scopo dell'astrazione.
Spesso però le astrazioni sono definite in termini di costrutti matematici. Questo è probabilmente perché sono così spesso usati nella scienza e nell'ingegneria.
Un esempio è la meccanica newtoniana. Presume che tutto sia infinitamente piccolo e tutta l'energia è conservata. Le interazioni tra oggetti sono chiaramente definite da formule matematiche. Ora, come sappiamo, l'universo non funziona in questo modo, e in molte situazioni l'astrazione scorre attraverso. Ma in molte situazioni, funziona molto bene.
Un altro modello astratto è tipico di elementi di circuito lineare, resistori, condensatori e induttori. Anche in questo caso le interazioni sono chiaramente definite da formule matematiche. Per i circuiti a bassa frequenza, o semplici driver di relè, e altre cose, l'analisi RLC funziona bene e fornisce ottimi risultati. Ma altre situazioni, come i circuiti radio a microonde, gli elementi sono troppo grandi e le interazioni sono più sottili e le semplici astrazioni RLC non reggono. Che cosa fare a quel punto dipende dal giudizio dell'ingegnere. Alcuni ingegneri hanno creato un'altra astrazione sugli altri, alcuni sostituiscono gli op-amp ideali con nuove formule matematiche per il loro funzionamento, altri sostituiscono gli op-amp ideali con gli op-amp reali simulati, che a loro volta sono simulati con una rete complessa di piccoli elementi ideali.
Come altri hanno già detto, è un modello semplificato. È uno strumento utilizzato per comprendere meglio i sistemi complessi.
Un'astrazione rappresenta qualcosa (ad esempio un concetto, una struttura di dati, una funzione) in termini di qualcos'altro. Ad esempio usiamo le parole per comunicare. Una parola è un'entità astratta che può essere rappresentata in termini di suoni (parlato) o in termini di simboli grafici (scrittura). L'idea chiave di un'astrazione è che l'entità in questione è distinta dalla rappresentazione sottostante, proprio come una parola non sono i suoni che vengono usati per pronunciarla o le lettere che sono usate per scriverlo.
Quindi, almeno in teoria, la rappresentazione di base di un'astrazione può essere sostituita da una rappresentazione diversa. In pratica, tuttavia, l'astrazione è raramente del tutto distinta dalla rappresentazione sottostante e talvolta la rappresentazione " perdite " attraverso . Ad esempio, la parola porta sfumature emotive che sono molto difficili da comunicare per iscritto. Per questo motivo una registrazione audio e una trascrizione delle stesse parole possono avere effetti molto diversi sul pubblico. In altre parole, l'astrazione delle parole spesso perde.
Le astrazioni in genere vengono fornite in livelli. Le parole sono astrazioni che possono essere rappresentate da lettere, che a loro volta sono astrazioni di suoni, che sono a loro volta astrazioni del modello di movimento delle particelle d'aria che sono create dalle corde vocali e che vengono rilevate dai timpani di una persona .
Nei bit di informatica sono in genere il livello più basso di rappresentazione. Byte, posizioni di memoria, istruzioni di assemblaggio e registri della CPU sono il livello successivo di astrazione. Quindi abbiamo i tipi di dati primitivi e le istruzioni di un linguaggio di livello superiore, che sono implementate in termini di byte, posizioni di memoria e istruzioni di assemblaggio. Quindi funzioni e classi (presupponendo un linguaggio OO) implementate in termini di tipi di dati primitivi e istruzioni di linguaggio incorporate. Quindi sono implementate funzioni e classi più complesse in termini di più semplici. Alcune di queste funzioni e classi implementano strutture di dati, come elenchi, stack, code, ecc. Quelle a loro volta vengono utilizzate per rappresentare entità più specifiche come una coda di processi o un elenco di dipendenti o una tabella hash di titoli di libri . In questo schema di cose ogni livello è un'astrazione rispetto al suo predecessore.
Un modo in cui cerco di descriverlo alle persone, potrebbe non essere il modo migliore
Considera un programma che aggiunge 2 + 2 e output 4
Considera un programma che aggiunge due numeri immessi da un utente, x + y = z
Quale è più utile e generale?
Direi che un'astrazione è qualcosa che nasconde dettagli non necessari. Una delle più elementari unità di astrazione è la procedura. Ad esempio, non voglio preoccuparmi di come sto salvando i dati nel database quando sto leggendo quei dati da un file. Quindi creo una funzione save_to_database.
Le astrazioni possono anche essere unite per formare astrazioni più grandi. Ad esempio, le funzioni possono essere raggruppate in una classe, le classi possono essere unite per formare un programma, i programmi possono essere messi insieme per formare un sistema distribuito, ecc.
Penso sempre all'astrazione nella programmazione come nascondere i dettagli e fornire un'interfaccia semplificata. È la ragione principale per cui i programmatori possono abbattere compiti monumentali in pezzi gestibili. Con l'astrazione, è possibile creare la soluzione a una parte del problema, inclusi tutti i dettagli grintosi e quindi fornire un'interfaccia semplice per utilizzare la soluzione. Quindi puoi in effetti "dimenticare" i dettagli. Questo è importante perché non c'è modo in cui una persona possa tenere tutti i dettagli di un sistema super-complesso nelle loro menti contemporaneamente. Questo non vuol dire che i dettagli al di sotto dell'astrazione non dovranno mai essere rivisitati, ma per il momento, solo l'interfaccia deve essere ricordata.
Nella programmazione, questa interfaccia semplificata può essere qualsiasi cosa, da una variabile (astrae un gruppo di bit e fornisce un'interfaccia matematica più semplice) a una funzione (astrae qualsiasi quantità di elaborazione in una singola chiamata di linea) a una classe e oltre .
Alla fine, il lavoro principale dei programmatori è di solito astrarre tutti i dettagli computazionali e fornire un'interfaccia semplice come una GUI che qualcuno che non conosce una cosa su come funzionano i computer può fare uso di.
Alcuni dei vantaggi dell'astrazione sono:
Consente di suddividere un grosso problema in parti gestibili. Quando si aggiungono i record di una persona a un database, non si vuole avere a che fare con l'inserimento e il bilanciamento degli alberi degli indici sul database. A un certo punto questo lavoro potrebbe essere stato fatto, ma ora è stato rimosso e non devi più preoccupartene.
Consente a più persone di lavorare bene insieme su un progetto. Non voglio conoscere tutti i dettagli del codice del mio collega. Voglio solo sapere come usarlo, cosa fa e come adattarlo al mio lavoro (l'interfaccia).
Consente alle persone che non hanno le conoscenze necessarie per eseguire un'attività complessa. Mia madre può aggiornare Facebook e le persone che conosce in tutto il paese possono vederlo. Senza l'astrazione di un sistema incredibilmente complesso in una semplice interfaccia web, non sarebbe in alcun modo possibile iniziare a fare qualcosa di simile (e nemmeno io per quello).
L'astrazione può, tuttavia, avere l'effetto opposto di rendere le cose meno gestibili in caso di uso eccessivo. Rompendo un problema in troppi pezzi, il numero di interfacce da ricordare aumenta e diventa più difficile capire cosa sta realmente accadendo. Come molte altre cose, è necessario trovare un equilibrio.
Un ulteriore livello di riferimento indiretto.
Non ti interessa sapere se l'oggetto che stai utilizzando è un Cat o un Dog , quindi passi attraverso una tabella delle funzioni virtuale per trovare la giusta funzione makeNoise() .
Sono sicuro che questo potrebbe essere applicato anche ai livelli "inferiore" e "più alto" - pensa a un compilatore che sta cercando l'istruzione giusta da usare per un determinato processore o all'estrazione di Monad di Haskell sugli effetti computazionali chiamando tutto return e >>= .
Questo è qualcosa che volevo davvero blog per un tempo più lungo, ma non ci sono mai riuscito. Per fortuna, sono uno zombi rep e c'è anche una taglia. Il mio post è stato piuttosto lungo , ma ecco l'essenza:
Abstraction in programming is about understanding the essence of an object within a given context.
[...]
Abstraction is not only mistaken with generalization, but also with encapsulation, but these are the two orthogonal parts of information hiding: The service module decides what it is willing to show and the client module decides what it is willing to see. Encapsulation is the first part and abstraction the latter. Only both together constitute full information hiding.
Spero che ti aiuti.
Ecco una risposta non matematica:
Abtracting away nella programmazione fa finta di non preoccuparti dei dettagli ora, mentre in effetti lo fai e dovresti preoccuparti di loro tutto il tempo. Praticamente sta fingendo.
Per me l'astrazione è qualcosa che non esiste "letteralmente", è qualcosa come un'idea. Se lo esprimi matematicamente, non è più astratto perché la matematica è un linguaggio per esprimere ciò che accade nel tuo cervello in modo che possa essere compreso dal cervello di qualcun altro, quindi non puoi strutturare le tue idee, perché se lo fai, non è un'idea più: avresti bisogno di capire come funziona un cervello per esprimere un modello di idea.
L'astrazione è qualcosa che ti permette di interpretare la realtà in qualcosa che può essere indipendente da essa. Puoi astrarre una spiaggia e un sogno, ma la spiaggia esiste ma il sogno no. Ma potresti dire che esistono entrambi, ma non è vero.
La cosa più difficile nell'astrazione è trovare un modo per esprimerlo in modo che le altre persone possano capirlo in modo che possa trasformarsi in realtà. Questo è il lavoro più difficile, e non può essere fatto da solo: devi inventare un modello relativo che funzioni sulle tue idee e che possa essere compreso da qualcun altro.
Per me l'astrazione nel linguaggio del computer dovrebbe essere il nome di "matematico" modello, si tratta di riutilizzare idee che possono essere comunicate, ed è un enorme vincolo rispetto a ciò che può essere ottenuto in modo astratto.
Per dirla semplicemente, gli atomi sono l'uno accanto all'altro, ma a loro non importa. Un grande insieme di molecole organizzate in un essere umano può capire che è vicino a qualcuno, ma non può capire come, è solo il modo in cui gli atomi si posizionano in qualche schema.
Un oggetto che è governato da un concetto, in generale, non può "capire" se stesso. Ecco perché cerchiamo di credere in Dio e perché abbiamo difficoltà a capire il nostro cervello.
Posso avere la mia medaglia ora?
Domanda interessante. Non conosco una singola definizione di astrazione che sia considerata autorevole quando si tratta di programmazione. Sebbene altre persone abbiano fornito collegamenti ad alcune definizioni da vari rami della teoria o della matematica di CS; Mi piace pensarlo in modo simile a "supervenience" vedi link
Quando parliamo di astrazione nella programmazione, stiamo essenzialmente confrontando due descrizioni di un sistema. Il tuo codice è una descrizione di un programma. Un'astrazione del tuo codice sarebbe anche una descrizione di quel programma, ma a un livello "più alto". Ovviamente potresti avere un'astrazione di livello ancora più alto della tua astrazione originale (ad esempio una descrizione del programma in un'architettura di sistema di alto livello rispetto alla descrizione dal programma nel suo design dettagliato).
Ora ciò che rende una descrizione "di livello superiore" rispetto ad un'altra. La chiave è la "realizabilità multipla": la tua astrazione del programma potrebbe essere realizzata in molti modi in molte lingue. Ora si potrebbe dire che si potrebbero produrre più progetti per un singolo programma - due persone potrebbero produrre due diversi disegni di alto livello che descrivono accuratamente il programma. L'equivalenza delle realizzazioni fa la differenza.
Quando confronti programmi o disegni devi farlo in un modo che ti permetta di identificare le proprietà chiave della descrizione a quel livello. Puoi entrare in modi complicati per dire che un design è equivalente a un altro, ma il modo più semplice per pensarci è questo: un singolo programma binario può soddisfare i vincoli di entrambe le descrizioni?
Quindi cosa rende un livello di descrizione più alto dell'altro? Diciamo che abbiamo un livello di descrizione A (ad esempio documenti di progettazione) e un altro livello di descrizione B (ad esempio codice sorgente). A è più alto di B perché se A1 e A2 sono due descrizioni non equivalenti al livello A, allora anche le realizzazioni di tali descrizioni, B1 e B2 devono essere non equivalenti a livello B. Tuttavia, il contrario non è necessariamente vero.
Quindi, se non riesco a produrre un singolo programma binario che soddisfi due distinti documenti di progetto (vale a dire che i vincoli di tali progetti si contraddicono a vicenda), il codice sorgente che implementa tali progetti deve essere diverso. D'altra parte, se prendo due serie di codice sorgente che non possono essere compilate nello stesso programma binario, potrebbe comunque accadere che i binari risultanti dalla compilazione di questi due gruppi di codice sorgente soddisfino entrambi lo stesso progetto documento. Quindi il documento di progettazione è una "astrazione" del codice sorgente.
Le astrazioni di programmazione sono astrazioni fatte da qualcuno su un elemento programmatico. Diciamo che sai come costruire un Menu con i suoi oggetti e cose. Poi qualcuno ha visto quel pezzo di codice e pensato, hey che potrebbe essere utile in altri tipi di strutture simili al hireachy e ha definito il Component Design Pattern con un'astrazione del primo pezzo di codice.
I modelli di progettazione orientata agli oggetti sono un buon esempio di ciò che è l'astrazione e non intendo la vera implementazione ma il modo in cui dovremmo affrontare una soluzione.
Quindi, per riassumere, programmare l'astrazione è un approccio che ci permette di capire un problema, è il mezzo per ottenere qualcosa ma non è la vera cosa
Leggi altre domande sui tag abstraction terminology