¿Qué es la abstracción? [cerrado]

¿Existe una definición generalmente aceptada de lo que es una abstracción de programación , como la usan los programadores? [Tenga en cuenta que la abstracción de programación no debe confundirse con las definiciones de diccionario para la palabra "abstracción"]. ¿Existe una definición inequívoca o incluso matemática? ¿Cuáles son algunos ejemplos claros de abstracciones?

La respuesta a "¿Puedes definir qué es una abstracción de programación más o menos matemáticamente?" no es." La abstracción no es un concepto matemático. Sería como pedirle a alguien que le explique matemáticamente el color de un limón.

Sin embargo, si desea una buena definición: la abstracción es el proceso de pasar de una idea específica a una más general. Por ejemplo, eche un vistazo a su mouse. ¿Es inalámbrico? ¿Qué tipo de sensor tiene? Cuantos botones ¿Es ergonómico? ¿Como es de grande? Las respuestas a todas estas preguntas pueden describir con precisión su mouse, pero independientemente de cuáles sean las respuestas, sigue siendo un mouse, porque es un dispositivo señalador con botones. Eso es todo lo que se necesita para ser un ratón. "Silver Logitech MX518" es un elemento concreto y específico, y "mouse" es una abstracción de eso. Una cosa importante para pensar es que no existe un objeto concreto como un "mouse", es solo una idea. El mouse en su escritorio siempre es algo más específico: '

La abstracción puede ser en capas y tan fina o gruesa como desee (un MX518 es un mouse, que es un objeto señalador, que es un periférico de computadora, que es un objeto alimentado por electricidad), puede ir tan lejos como desee , y en prácticamente cualquier dirección que desee (mi mouse tiene un cable, lo que significa que podría categorizarlo como un objeto con un cable. También es plano en la parte inferior, por lo que podría clasificarlo como un tipo de objeto que no rodará cuando colocado en posición vertical en un plano inclinado).

La programación orientada a objetos se basa en el concepto de abstracciones y familias o grupos de ellas. Una buena OOP significa elegir buenas abstracciones con el nivel de detalle apropiado que tengan sentido en el dominio de su programa y no se "filtren". Lo primero significa que clasificar un mouse como un objeto que no rodará en un plano inclinado no tiene sentido para una aplicación que inventa equipos informáticos, pero podría tener sentido para un simulador de física. Esto último significa que debes tratar de evitar "encerrarte" en una jerarquía que no tiene sentido para algún tipo de objeto. Por ejemplo, en mi jerarquía anterior, ¿estamos seguros de que todoslos periféricos de la computadora funcionan con electricidad? ¿Qué tal un lápiz? Si queremos agrupar un lápiz óptico en la categoría "periférico", tendríamos un problema, porque no usa electricidad, y definimos los periféricos de la computadora como objetos que usan electricidad. El problema círculo-elipse es el ejemplo más conocido de este enigma.

Estoy totalmente en desacuerdo con la mayoría de las respuestas.

Esta es mi respuesta:

Dados dos conjuntos G y H, se puede definir una conexión de Galois (alfa, beta) entre ellos, y se puede decir que uno es una concreción del otro; invierte la conexión, y uno es una abstracción del otro. Las funciones son una función de concretización y una función de abstracción.

Esto es de la teoría de la interpretación abstracta de los programas de computadora, que generalmente es un enfoque de análisis estático hasta la fecha.

La abstracción se enfoca más Whaty menos How. O puede decir, conocer solo las cosas que necesita y simplemente confiar en el proveedor para todos los demás servicios. A veces incluso oculta la identidad del proveedor de servicios.

Por ejemplo, este sitio proporciona un sistema para hacer preguntas y responderlas. Casi todo el mundo aquí sabe cuáles son los procedimientos para preguntar, responder, votar y otras cosas de este sitio. Pero muy pocos saben cuáles son las tecnologías subyacentes. Como si el sitio se desarrolló con ASP.net mvc o Python, si esto se ejecuta en un servidor Windows o Linux, etc. Porque eso no es asunto nuestro. Por lo tanto, este sitio mantiene una capa de abstracción sobre su mecanismo subyacente para que podamos proporcionar el servicio.

Algunos otros ejemplos:

• Un automóvil oculta todos sus mecanismos, pero proporciona una forma de conducir, repostar y mantener a su propietario.

• Cualquier API oculta todos los detalles de su implementación proporcionando el servicio a otros programadores.

• Una clase en OOP oculta a sus miembros privados y la implementación de miembros públicos que brindan el servicio para llamar a los miembros públicos.

• Al usar un objeto de tipo an Interfaceo an abstract classen Java o C ++, la implementación real está oculta. Y no solo oculto, las implementaciones de los métodos declarados en el Interfacetambién es probable que sean diferentes en varias clases implementadas / heredadas. Pero como está obteniendo el mismo servicio, simplemente no se preocupe, ya Howque está implementado y exactamente Who/ Whatestá proporcionando el servicio.

• Ocultación de identidad : para la frase "Sé que Sam puede escribir programas de computadora". la abstracción puede ser: "Sam es un programador. Los programadores saben cómo escribir programas de computadora". En la segunda declaración, la persona no es importante. Pero su habilidad para hacer programación es importante.

Una abstracción de programación es un modelo simplificado de un problema.

Por ejemplo, una conexión TCP / IP es una abstracción sobre el envío de datos. Simplemente incluye una dirección IP y un número de puerto y lo envía a la API. No le preocupan todos los detalles de los cables, señales, formatos de mensajes y fallas.

Una abstracción es solo la versión de programación de un teorema.

Tienes un sistema formal, propones un pensamiento sobre ese sistema. Haces una prueba de ello, y si funciona, entonces tienes un teorema. Sabiendo que su teorema es válido, puede usarlo en más pruebas sobre el sistema. Las primitivas proporcionadas por el sistema (como si las declaraciones y los tipos de valores int) normalmente se considerarían como axiomas, aunque eso no es estrictamente cierto ya que cualquier cosa que no sean instrucciones de CPU escritas en código de máquina es una especie de abstracción.

En la programación funcional, la idea de un programa como una declaración matemática es muy fuerte, y a menudo el sistema de tipos (en un lenguaje fuerte y estáticamente tipado como Haskell, F # u OCAML) se puede usar para probar la teoría de la teoría mediante pruebas.

Por ejemplo: digamos que tenemos la suma y la verificación de igualdad como operaciones primitivas, y enteros y booleanos como tipos de datos primitivos. Estos son nuestros axiomas. Entonces podemos decir que 1 + 3 == 2 + 2es un teorema, luego usar las reglas de suma y enteros e igualdad para ver si esa es una declaración verdadera.

Ahora supongamos que queremos multiplicación, y nuestras primitivas (por razones de brevedad) incluyen una construcción en bucle y un medio para asignar referencias simbólicas. Podríamos sugerir que

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

Voy a fingir que probé eso, demostrando que la multiplicación es válida. Ahora puedo usar la multiplicación para hacer más cosas con mi sistema (el lenguaje de programación).

También puedo verificar mi sistema de tipos. (*) tiene un tipo de int -> int -> int. Se necesitan 2 entradas y genera un int. La adición tiene un tipo de int -> int -> int, por lo que el 0 + (resto) se mantiene siempre que (resto) dé como resultado un int. Mi ciclo podría estar haciendo todo tipo de cosas, pero estoy diciendo que genera una cadena de funciones curry tales que (x + (x + (x ... + 0))) es el resultado. La forma de esa cadena de suma es solo (int -> (int -> (int ... -> int))), así que sé que mi salida final será un int. ¡Entonces mi sistema de tipos mostró los resultados de mi otra prueba!

Comprenda este tipo de idea durante muchos años, muchos programadores y muchas líneas de código, y tiene lenguajes de programación modernos: un conjunto abundante de primitivas y enormes bibliotecas de abstracciones de código "probadas".

¿Sería la respuesta de Wikipedia lo suficientemente buena? http://en.wikipedia.org/wiki/Abstraction_%28programming%29

En ciencias de la computación, el mecanismo y la práctica de la abstracción reduce y elimina los detalles para que uno pueda enfocarse en algunos conceptos a la vez.

Bueno, matemáticamente, "entero" es una abstracción. Y cuando realiza pruebas formales como esa x + y = y + x para todos los enteros, está trabajando con la abstracción "entero" en lugar de números específicos como 3 o 4. Lo mismo sucede en el desarrollo de software cuando interactúa con el máquina en un nivel superior a registros y ubicaciones de memoria. Puedes pensar pensamientos más poderosos a un nivel más abstracto, en la mayoría de los casos.

Estás obteniendo buenas respuestas aquí. Solo advierto: la gente piensa que la abstracción es de alguna manera esta cosa maravillosa que debe colocarse en un pedestal, y de la que no puede obtener suficiente. No lo es. Es sólo sentido común. Es solo reconocer las similitudes entre las cosas, por lo que puede aplicar una solución de problemas a una variedad de problemas.

Permíteme un fastidio ...

En lo alto de mi lista de molestias es cuando la gente habla de "capas de abstracción" como si eso fuera algo bueno. Hacen "envoltorios" alrededor de las clases o rutinas que no les gustan, y los llaman "más abstractos", como si eso los mejorara. ¿Recuerdas la fábula de la "Princesa y el guisante"? La princesa era tan delicada que si hubiera un guisante debajo del colchón no podría dormir, y agregar más capas de colchones no ayudaría. La idea de que agregar más capas de "abstracción" ayudará es así, generalmente no lo hace. Simplemente significa que cualquier cambio en la entidad base debe ser movido a través de múltiples capas de código.

Creo que puede ser útil una publicación mía en el blog sobre abstracciones con fugas. Aquí está el trasfondo relevante:

La abstracción es un mecanismo para ayudar a tomar lo que es común entre un conjunto de fragmentos de programas relacionados, eliminar sus diferencias y permitir a los programadores trabajar directamente con una construcción que represente ese concepto abstracto. Esta nueva construcción (virtualmente) siempre tiene parametrizaciones : un medio para personalizar el uso de la construcción para satisfacer sus necesidades específicas.

Por ejemplo, una Listclase puede abstraer los detalles de una implementación de lista enlazada, donde en lugar de pensar en términos de manipulación nexty previouspunteros, puede pensar en el nivel de agregar o eliminar valores a una secuencia. La abstracción es una herramienta esencial para crear características útiles, ricas y a veces complejas a partir de un conjunto mucho más pequeño de conceptos más primitivos.

La abstracción está relacionada con la encapsulación y la modularidad, y estos conceptos a menudo se malinterpretan.

En el Listejemplo, la encapsulación se puede usar para ocultar los detalles de implementación de una lista vinculada; en un lenguaje orientado a objetos, por ejemplo, puede hacer que los punteros nexty sean previousprivados, donde solo la implementación de la Lista tiene acceso a estos campos.

La encapsulación no es suficiente para la abstracción, porque no implica necesariamente que tenga una concepción nueva o diferente de las construcciones. Si todo lo que hizo una Listclase fue darle métodos de acceso de estilo ' getNext' / ' setNext', se encapsularía de usted a partir de los detalles de implementación (por ejemplo, ¿nombró el campo ' prev' o ' previous'? ¿Cuál era su tipo estático?), Pero tendría un grado muy bajo de abstracción.

La modularidad se refiere a la ocultación de información : las propiedades estables se especifican en una interfaz, y un módulo implementa esa interfaz, manteniendo todos los detalles de implementación dentro del módulo. La modularidad ayuda a los programadores a hacer frente al cambio, porque otros módulos dependen solo de la interfaz estable.

La encapsulación ayuda a ocultar la información (de modo que su código no dependa de detalles de implementación inestables), pero la encapsulación no es necesaria para la modularidad. Por ejemplo, se puede implementar una Listestructura en C, la exposición de los ' next' y ' prevpunteros' al mundo, sino que también proporcionan una interfaz, que contiene initList(), addToList()yremoveFromList()funciones Siempre que se sigan las reglas de la interfaz, puede garantizar que ciertas propiedades siempre se mantendrán, como garantizar que la estructura de datos esté siempre en un estado válido. [El clásico artículo de Parnas sobre modularidad, por ejemplo, fue escrito con un ejemplo en asamblea. La interfaz es un contrato y una forma de comunicación sobre el diseño, no necesariamente tiene que verificarse mecánicamente, aunque eso es en lo que confiamos hoy.]

Aunque los términos abstracto, modular y encapsulado se usan como descripciones de diseño positivas, es importante darse cuenta de que la presencia de cualquiera de estas cualidades no le proporciona automáticamente un buen diseño:

• Si un algoritmo n ^ 3 está "bien encapsulado", seguirá funcionando peor que un algoritmo n log n mejorado.

• Si una interfaz se compromete con un sistema operativo específico, ninguno de los beneficios de un diseño modular se logrará cuando, por ejemplo, un videojuego necesite ser portado de Windows al iPad.

• Si la abstracción creada expone demasiados detalles no esenciales, no podrá crear una nueva construcción con sus propias operaciones: simplemente será otro nombre para la misma cosa.

Ok, creo que descubrí lo que estás preguntando: "¿Cuál es una definición matemáticamente rigurosa de 'Una abstracción'?"

Si ese es el caso, creo que no tienes suerte: 'abstracción' es un término de arquitectura / diseño de software, y no tengo ningún respaldo matemático hasta donde yo sepa (tal vez alguien mejor versado en CS teórico me corrija aquí), más que "acoplamiento" u "ocultación de información" tienen definiciones matemáticas.

La abstracción es cuando ignoras los detalles que se consideran irrelevantes a favor de los que se consideran relevantes.

La abstracción abarca encapsulación, ocultación de información y generalización. No abarca analogías, metáforas o heurísticas.

Cualquier formalismo matemático para el concepto de abstracción sería en sí ser una abstracción, ya que requeriría necesariamente la cosa subyacente que ser abstraído en un conjunto de propiedades matemáticas! La noción de teoría de categoría de un morfismo es probablemente la más cercana a lo que estás buscando.

La abstracción no es algo que declaras, es algo que haces .

Como una forma de explicárselo a otra persona, iría al revés, desde los resultados:

La abstracción en la programación de computadoras es el acto de generalizar algo hasta el punto de que más de una cosa similar generalmente puede ser tratada como la misma y manejada igual.

Si desea ampliar eso, puede agregar:

A veces esto se hace para lograr un comportamiento polimórfico (interfaces y herencia) para reducir el código repetitivo por adelantado, otras veces se hace para que el funcionamiento interno de algo se pueda reemplazar en una fecha futura con una solución similar sin tener que alterar el código en el otro lado del contenedor o envoltorio abstraído, con suerte reduciendo el reprocesamiento en el futuro.

Más allá de eso, creo que debes comenzar con ejemplos ...

Es posible que desee ver algunas de las métricas de Bob Martin

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

Dicho esto, no creo que su "abstracción" sea la misma que la tuya. La suya es más una medida de "falta de implementación en una clase", lo que significa el uso de interfaces / clases abstractas. La inestabilidad y la distancia desde la secuencia principal probablemente influyan más en lo que estás buscando.

Merriam-webster define el resumen como un ser adjetivo: desasociado de cualquier instancia específica.

Una abstracción es un modelo de algún sistema. A menudo enumeran un grupo de supuestos que deben cumplirse para que un sistema real pueda ser modelado por la abstracción, y a menudo se usan para permitirnos conceptualizar sistemas cada vez más complicados. Pasar de un sistema real a una abstracción no tiene ningún método matemático formal para hacerlo. Eso depende del juicio de quien defina la abstracción, y cuál es el propósito de la abstracción.

A menudo, sin embargo, las abstracciones se definen en términos de construcciones matemáticas. Probablemente sea porque se usan con mucha frecuencia en ciencia e ingeniería.

Un ejemplo es la mecánica newtoniana. Asume que todo es infinitesimalmente pequeño, y toda la energía se conserva. Las interacciones entre objetos están claramente definidas por fórmulas matemáticas. Ahora, como sabemos, el universo no funciona de esa manera, y en muchas situaciones la abstracción se filtra. Pero en muchas situaciones, funciona muy bien.

Otro modelo abstracto son los elementos típicos de circuitos lineales, resistencias, condensadores e inductores. Nuevamente, las interacciones están claramente definidas por fórmulas matemáticas. Para circuitos de baja frecuencia, o simples controladores de relé, y otras cosas, el análisis RLC funciona bien y proporciona muy buenos resultados. Pero en otras situaciones, como los circuitos de radio de microondas, los elementos son demasiado grandes y las interacciones son más finas, y las simples abstracciones RLC no se sostienen. Qué hacer en ese momento depende del juicio del ingeniero. Algunos ingenieros han creado otra abstracción sobre los demás, algunos reemplazan los amplificadores operacionales ideales con nuevas fórmulas matemáticas de cómo funcionan, otros reemplazan los amplificadores operacionales ideales con amplificadores operacionales reales simulados, que a su vez se simulan con una red compleja de pequeños Elementos ideales.

Como otros han dicho, es un modelo simplificado. Es una herramienta utilizada para comprender mejor los sistemas complejos.

Una abstracción representa algo (por ejemplo, un concepto, una estructura de datos, una función) en términos de otra cosa. Por ejemplo, usamos palabras para comunicarnos. Una palabra es una entidad abstracta que se puede representar en términos de sonidos (habla) o en términos de símbolos gráficos (escritura). La idea clave de una abstracción es que la entidad en cuestión es distinta de la representación subyacente, así como una palabra no son los sonidos que se usan para pronunciarla o las letras que se usan para escribirla.

Por lo tanto, al menos en teoría, la representación subyacente de una abstracción puede ser reemplazada por una representación diferente. En la práctica, sin embargo, la abstracción rara vez es completamente distinta de la representación subyacente y, a veces, la representación "se filtra ". Por ejemplo, el habla conlleva matices emocionales que son muy difíciles de transmitir por escrito. Debido a esto, una grabación de audio y una transcripción de las mismas palabras pueden tener un efecto muy diferente en la audiencia. En otras palabras, la abstracción de las palabras a menudo se filtra.

Las abstracciones generalmente vienen en capas. Las palabras son abstracciones que pueden representarse mediante letras, que a su vez son abstracciones de los sonidos, que a su vez son abstracciones del patrón de movimiento de las partículas de aire creadas por las cuerdas vocales y detectadas por los tímpanos. .

En informática, los bits suelen ser el nivel más bajo de representación. Bytes, ubicaciones de memoria, instrucciones de ensamblaje y registros de CPU son el siguiente nivel de abstracción. Luego tenemos tipos de datos primitivos e instrucciones de un lenguaje de nivel superior, que se implementan en términos de bytes, ubicaciones de memoria e instrucciones de ensamblaje. Luego, funciones y clases (suponiendo un lenguaje OO) que se implementan en términos de tipos de datos primitivos e instrucciones de lenguaje incorporadas. Luego, se implementan funciones y clases más complejas en términos de las más simples. Algunas de estas funciones y clases implementan estructuras de datos, como listas, pilas, colas, etc. Estas, a su vez, se utilizan para representar entidades más específicas, como una cola de procesos, una lista de empleados o una tabla hash de títulos de libros. .

Una forma en que trato de describirlo a las personas, puede que no sea la mejor manera

Considere un programa que agrega 2 + 2 y produce 4

Considere un programa que agrega dos números ingresados ​​por un usuario, x + y = z

¿Cuál es más útil y general?

Yo diría que una abstracción es algo que oculta detalles innecesarios. Una de las unidades más básicas de abstracción es el procedimiento. Por ejemplo, no quiero preocuparme por cómo estoy guardando datos en la base de datos cuando estoy leyendo esos datos desde un archivo. Entonces creo una función save_to_database.

Las abstracciones también se pueden unir para formar abstracciones más grandes. Por ejemplo, las funciones se pueden juntar en una clase, las clases se pueden juntar para formar un programa, los programas se pueden juntar para formar un sistema distribuido, etc.

Siempre pienso en la abstracción en la programación como ocultar detalles y proporcionar una interfaz simplificada. Es la razón principal por la que los programadores pueden dividir las tareas monumentales en piezas manejables. Con la abstracción, puede crear la solución a una parte del problema, incluidos todos los detalles, y luego proporcionar una interfaz simple para usar la solución. Entonces, en efecto, puede "olvidarse" de los detalles. Esto es importante porque no hay forma de que una persona pueda tener todos los detalles de un sistema súper complejo en sus mentes a la vez. Esto no quiere decir que los detalles debajo de la abstracción nunca tendrán que revisarse, pero por el momento, solo se debe recordar la interfaz.

En programación, esta interfaz simplificada puede ser cualquier cosa, desde una variable (extrae un grupo de bits y proporciona una interfaz matemática más simple) hasta una función (extrae cualquier cantidad de procesamiento en una sola llamada de línea) a una clase y más.

Al final, el trabajo principal de los programadores es generalmente abstraer todos los detalles computacionales y proporcionar una interfaz simple como una GUI que alguien que no sabe una cosa sobre cómo funcionan las computadoras puede hacer uso.

Algunas de las ventajas de la abstracción son:

• Permite dividir un gran problema en piezas manejables. Al agregar los registros de una persona a una base de datos, no querrá tener que meterse con la inserción y el equilibrio de los árboles de índice en la base de datos. Es posible que este trabajo se haya realizado en algún momento, pero ahora se ha abstraído y ya no tiene que preocuparse por ello.

• Permite que varias personas trabajen bien juntas en un proyecto. No quiero tener que conocer todos los entresijos del código de mi colega. Solo quiero saber cómo usarlo, qué hace y cómo combinarlo con mi trabajo (la interfaz).

• Permite a las personas que no tienen el conocimiento requerido realizar una tarea compleja para hacerlo. Mi madre puede actualizar su facebook y las personas que conoce en todo el país pueden verlo. Sin la abstracción de un sistema increíblemente complejo para una interfaz web simple, no hay forma de que ella pueda comenzar a hacer algo similar (ni yo lo haría).

Sin embargo, la abstracción puede tener el efecto inverso de hacer las cosas menos manejables si se usa en exceso. Al dividir un problema en demasiadas piezas pequeñas, la cantidad de interfaces que debe recordar aumenta y se hace más difícil entender lo que realmente está sucediendo. Como la mayoría de las cosas, se debe encontrar un equilibrio.

Un nivel extra de indirección.

No le importa si el objeto que está utilizando es a Cato a Dog, por lo que debe pasar por una tabla de funciones virtuales para encontrar la makeNoise()función correcta .

Estoy seguro de que esto también podría aplicarse a los niveles 'inferior' y 'superior'. Piense en un compilador que busca las instrucciones correctas para un procesador determinado o en el Monadresumen de Haskell sobre los efectos computacionales llamando a todo returny >>=.

Esto es algo sobre lo que realmente quería bloguear durante más tiempo, pero nunca lo logré. Afortunadamente, soy un zombie representante e incluso hay una recompensa. Mi publicación resultó bastante larga , pero aquí está la esencia:

La abstracción en la programación se trata de comprender la esencia de un objeto dentro de un contexto dado.

[...]

La abstracción no solo se confunde con la generalización, sino también con la encapsulación, sino que estas son las dos partes ortogonales de la ocultación de la información: el módulo de servicio decide lo que está dispuesto a mostrar y el módulo del cliente decide lo que está dispuesto a ver. La encapsulación es la primera parte y la abstracción la última. Solo ambos juntos constituyen la ocultación de información completa.

Espero que ayude.

Aquí, una respuesta no matemática:

Si te distraes de la programación, pretendes que no te importan los detalles ahora, mientras que en realidad sí lo haces y debes preocuparte por ellos todo el tiempo. Básicamente es fingir.

Para mí, la abstracción es algo que no existe "literalmente", es algo así como una idea. Si lo expresa matemáticamente, ya no es abstracto porque las matemáticas son un lenguaje para expresar lo que sucede en su cerebro para que pueda ser entendido por el cerebro de otra persona, por lo que no puede estructurar sus ideas, porque si lo hace, no es una idea más: necesitaría comprender cómo funciona un cerebro para expresar un modelo de idea.

La abstracción es algo que te permite interpretar la realidad en algo que puede ser independiente de ella. Puedes abstraer una playa y un sueño, pero la playa existe pero el sueño no. Pero se podría decir que ambos existen, pero no es cierto.

Lo más difícil en la abstracción es encontrar una manera de expresarlo para que otras personas puedan entenderlo y que se convierta en realidad. Ese es el trabajo más difícil, y realmente no se puede hacer solo: tienes que inventar un modelo relativo que funcione con tus ideas y que pueda ser entendido por otra persona.

Para mí, la abstracción en lenguaje de computadora debe llamarse "matematizar" el modelo, se trata de reutilizar ideas que se pueden comunicar, y es una limitación enorme en comparación con lo que se puede lograr de manera abstracta.

En pocas palabras, los átomos están uno al lado del otro, pero no les importa. Un gran conjunto de moléculas organizadas en un ser humano puede entender que está al lado de alguien, pero no puede entender cómo, es solo cómo los átomos se posicionaron en algún patrón.

Un objeto que se rige por un concepto, en general, no puede "entenderse" a sí mismo. Es por eso que tratamos de creer en Dios y por qué nos cuesta entender nuestro cerebro.

¿Puedo tener mi medalla ahora?

Interesante pregunta. No conozco una sola definición de abstracción que se considere autorizada cuando se trata de programación. Aunque otras personas han proporcionado enlaces a algunas definiciones de varias ramas de la teoría CS o las matemáticas; Me gusta pensarlo de forma similar a "superveniencia", consulte http://en.wikipedia.org/wiki/Supervenience

Cuando hablamos de abstracción en la programación, esencialmente estamos comparando dos descripciones de un sistema. Su código es una descripción de un programa. Una abstracción de su código también sería una descripción de ese programa, pero a un nivel "superior". Por supuesto, podría tener una abstracción de nivel superior de su abstracción original (por ejemplo, una descripción del programa en una arquitectura de sistema de alto nivel frente a la descripción del programa en su diseño detallado).

Ahora, ¿qué hace que una descripción sea de "nivel superior" a otra? La clave es la "realizabilidad múltiple": su abstracción del programa podría realizarse de muchas maneras en muchos idiomas. Ahora podría decir que también se podrían producir múltiples diseños para un solo programa: dos personas podrían producir dos diseños diferentes de alto nivel que describan con precisión el programa. La equivalencia de las realizaciones hace la diferencia.

Al comparar programas o diseños, debe hacerlo de una manera que le permita identificar las propiedades clave de la descripción en ese nivel. Puede entrar en formas complicadas de decir que un diseño es equivalente a otro, pero la forma más fácil de pensarlo es esto: ¿puede un solo programa binario satisfacer las limitaciones de ambas descripciones?

Entonces, ¿qué hace que un nivel de descripción sea más alto que el otro? Digamos que tenemos un nivel de descripción A (por ejemplo, documentos de diseño) y otro nivel de descripción B (por ejemplo, código fuente). A es un nivel más alto que B porque si A1 y A2 son dos descripciones no equivalentes en el nivel A, entonces la realización de esas descripciones, B1 y B2 también deben ser no equivalentes en el nivel B. Sin embargo, lo contrario no necesariamente es cierto .

Entonces, si no puedo producir un solo programa binario que satisfaga dos documentos de diseño distintos (es decir, las restricciones de esos diseños se contradicen entre sí), entonces el código fuente que implementa esos diseños debe ser diferente. Pero, por otro lado, si tomo dos conjuntos de código fuente que posiblemente no podrían compilarse en el mismo programa binario, aún podría ser el caso de que los binarios resultantes de compilar esos dos conjuntos de código fuente cumplan el mismo diseño documento. Por lo tanto, el documento de diseño es una "abstracción" del código fuente.

Las abstracciones de programación son abstracciones hechas por alguien en un elemento programático. Digamos que sabes cómo construir un menú con sus elementos y demás. Entonces alguien vio ese fragmento de código y pensó, bueno, eso podría ser útil en otro tipo de estructuras similares a las de la contratación, y definió el Patrón de diseño de componentes con una abstracción del primer fragmento de código.

Los patrones de diseño orientados a objetos son un buen ejemplo de lo que es la abstracción, y no me refiero a la implementación real sino a la forma en que debemos abordar una solución.

En resumen, la abstracción de programación es un enfoque que nos permite comprender un problema, es el medio para obtener algo, pero no es lo real