# data[].attributes.body
"Proceso de eliminar detalles o atributos físicos, espaciales o temporales en el estudio de objetos o sistemas para centrar la atención en detalles de mayor importancia".

(Farley, 2022).

# data[].attributes.body
Proceso de generalización para identificar el núcleo común o esencial con base en:

El proceso de formulación general de conceptos para abstraer propiedades comunes de las instancias

Un concepto general formado por la extracción de características comunes a partir de ejemplos específicos.

(Serna, 2011).

# data[].attributes.body
Proceso de eliminar detalles para simplificar y concentrar la atención con base en:

El acto de retirar o remover algo

El acto o proceso de no considerar una o más propiedades de un objeto complejo a fin de atender las demás.

(Serna, 2011).

# data[].attributes.headline
Importancia en la Ingeniería de Software

# data[].attributes.subject
Importancia en la Ingeniería de Software

# data[].attributes.body
La eliminación de detalles innecesarios es evidente en la ingeniería de requisitos y en el diseño de software. La elicitación de requisitos consiste en identificar los aspectos críticos del entorno que requiere el sistema, mientras se abandonan los irrelevantes. El diseño requiere que se evite la implementación innecesaria de restricciones.

El aspecto de generalización de la abstracción se puede ver claramente en el desarrollo, en el uso de abstracciones de datos y de clases en la programación orientada por objetos.

El pensamiento abstracto es fundamental para manipular y razonar sobre abstracciones, ya sean modelos formales para el análisis o programas en un lenguaje de programación.

(Serna, 2011)

# data[].attributes.body
-La encapsulación es un proceso que permite ocultar los detalles de implementación de un objeto y solo exponer una interfaz pública que otros objetos pueden usar para interactuar con él.

-El modelado de objetos es un proceso que implica identificar los objetos relevantes en un sistema y definir sus características y relaciones.

-El diseño orientado a objetos se centra en diseñar sistemas en términos de objetos y sus interacciones.

# data[].attributes.body
Mayor complejidad inicial: Al ocultar detalles internos de un módulo o componente a través de la abstracción, es posible que los desarrolladores tengan que aprender y comprender una interfaz abstracta o API antes de poder utilizar el componente.

Dificultad para depurar: Cuando se ocultan los detalles internos de un componente, puede ser más difícil depurar problemas y errores en el código.

Limitaciones en el control: Al ocultar detalles internos, los desarrolladores pueden tener menos control sobre el comportamiento del componente.

Mayor uso de recursos: La abstracción y el ocultamiento de información pueden aumentar el consumo de recursos (como memoria y procesamiento) debido al uso de capas adicionales.

Mayor complejidad de mantenimiento: Mantener y actualizar estas abstracciones puede aumentar la complejidad y el costo de mantenimiento a lo largo del tiempo.

# data[].attributes.body
Reduce el acoplamiento entre componentes: Al ocultar detalles de implementación, los componentes están menos acoplados entre sí.

Mejora la cohesión al separar responsabilidades: La abstracción ayuda a separar responsabilidades en módulos cohesivos.

Facilita el testing y la validación de cambios: Escribir tests para una interfaz abstracta es más fácil. Los tests validan que los cambios no rompan la abstracción.

Permite cambios en una parte sin afectar el resto: Gracias a la separación de responsabilidades, se pueden hacer cambios aislados.

Oculta complejidad accidental o de implementación: La abstracción separa la complejidad esencial del dominio de la complejidad accidental técnica.

# data[].attributes.attachment_link.readable_text
Las clases abstractas actúan como expresiones de conceptos generales de los que pueden derivarse clases más concretas. No se puede crear un objeto de un tipo de clase abstracta, pero se pueden usar punteros y referencias a tipos de clase abstracta.

Para crear una clase abstracta, declare al menos una función miembro virtual pura. Se trata de una función virtual declarada mediante la sintaxis del especificador puro (= 0). Las clases derivadas de la clase abstracta deben implementar la función virtual pura o deben ser también clases abstractas.

Considere el ejemplo que se presenta en Funciones virtuales. El propósito de la clase Account es proporcionar funcionalidad general, pero los objetos de tipo Account son demasiado generales para resultar útiles. Eso significa que Account es un buen candidato para una clase abstracta:

// deriv_AbstractClasses.cpp // compile with: /LD class Account { public: Account( double d ); // Constructor. virtual double GetBalance(); // Obtain balance. virtual void PrintBalance() = 0; // Pure virtual function. private: double _balance; };

La única diferencia entre esta declaración y la anterior consiste en que PrintBalance se declara con el especificador puro (= 0).

Restricciones para el uso de clases abstractas

No se pueden usar clases abstractas para:

Variables o datos de miembro

Tipos de argumento

Tipos de valor devuelto de función

Tipos de conversiones explícitas

Si el constructor para una clase abstracta llama a una función virtual pura, ya sea directa o indirectamente, el resultado es indefinido. Sin embargo, los constructores y destructores para las clases abstractas pueden llamar a otras funciones miembro.

Funciones virtuales puras definidas

En las clases abstractas, las funciones virtuales puras pueden estar definidas o tener una implementación. Solo se puede llamar a estas funciones mediante la sintaxis completa:

abstract-class-name:: function-name()

Las funciones virtuales puras definidas son útiles al diseñar jerarquías de clases cuyas clases base incluyen destructores virtuales puros. Esto se debe a que siempre se llama a los destructores de clase base durante la destrucción de objetos. Considere el ejemplo siguiente:

// deriv_RestrictionsOnUsingAbstractClasses.cpp // Declare an abstract base class with a pure virtual destructor. // It's the simplest possible abstract class. class base { public: base() {} // To define the virtual destructor outside the class: virtual ~base() = 0; // Microsoft-specific extension to define it inline: // virtual ~base() = 0 {}; }; base::~base() {} // required if not using Microsoft extension class derived : public base { public: derived() {} ~derived() {} }; int main() { derived aDerived; // destructor called when it goes out of scope }

En el ejemplo se muestra la forma en que una extensión del compilador de Microsoft permite agregar una definición insertada a un objeto ~base() virtual puro. También se puede definir fuera de la clase mediante base::~base() {}.

Cuando el objeto aDerived sale del ámbito, se llama al destructor de la clase derived. El compilador genera código para llamar implícitamente al destructor para la clase base después del destructor derived. La implementación vacía para el objeto ~base de la función virtual pura garantiza que al menos existe alguna implementación para la función. Sin él, el enlazador genera un error de símbolo externo sin resolver para la llamada implícita.

Nota:

En el ejemplo anterior, la función virtual pura base::~base se llama implícitamente desde derived::~derived. También es posible llamar a funciones virtuales puras explícitamente mediante el nombre completo de la función miembro. Estas funciones deben tener una implementación; de lo contrario, la llamada produce un error en tiempo de vínculo.

Consulte también

# data[].attributes.attachment_link.description
Obtenga más información sobre las clases abstractas (C++).

# data[].attributes.attachment_link.title
Podcast #11 - El concepto de abstracción en el desarrollo de software | Héctor de Léon | hdeleon.net

# data[].attributes.attachment_caption
Misma funcion con diferentes niveles de abstraccion