Comprender la diferencia entre clases y objetos en ABAP es uno de los pasos más importantes y confusos para los desarrolladores que se trasladan a los objetos ABAP.
Si vienes de procesal ABAP o de lenguajes totalmente orientados a objetos como Javaes fácil confundir lo que realmente es una clase con lo que representa un objeto en tiempo de ejecución.
En términos simples, una clase define lo que puede ser un objeto, mientras que un objeto es una instancia específica creada a partir de esa clase. Sin embargo, en el modelo de programación híbrida de ABAP, esta relación no siempre se explica claramente, especialmente cuando se compara con conceptos familiares como estructuras y tablas internas.
Esta publicación analiza clases versus objetos en ABAP en términos prácticos. Aprenderá qué representan realmente los objetos, cómo las clases definen el comportamiento y la estructura de los objetos, cómo se comparan las clases ABAP con otros tipos de datos abstractos y por qué los métodos forman la interfaz pública de un objeto. Al final, tendrá un modelo mental claro de cómo funcionan los objetos ABAP tanto en tiempo de diseño como en tiempo de ejecución.
¿Qué es un objeto en ABAP?
Desde una perspectiva técnica, un objeto es un tipo especial de variable que tiene características y comportamientos distintos. Las características (o atributos) de un objeto se utilizan para describir el estado de un objeto. Por ejemplo, un objeto Auto podría tener atributos para capturar información como el color del auto, su marca y modelo, o incluso su velocidad de conducción actual. Comportamientos (o metodos) representan el comportamiento realizado por un objeto. En nuestro ejemplo de Coche, puede haber métodos que se puedan utilizar para conducir, girar y detener el coche, por ejemplo.
Por qué los objetos representan conceptos del mundo real en programación orientada a objetos
Con estos dos conceptos en mente, nuestra definición inicial de objeto sería algo como esto: «Un objeto es una variable que combina datos y comportamientos en un paquete autónomo». Sin embargo, si nos detuviéramos ahí, nuestra definición sería bastante limitante. En su libro, Patrones de diseño explicados: una nueva perspectiva sobre el diseño orientado a objetos, segunda edición (Addison-Wesley, 2004), Alan Shalloway enfatiza que los objetos hacen posible «… empaquetar datos y funcionalidad juntos mediante conceptopor lo que puedes representar una idea apropiada del espacio del problema en lugar de verte obligado a utilizar los modismos de la máquina subyacente”. Esta distinción, aunque sutil, es importante para llevarle a donde realmente quiere llegar con la programación orientada a objetos: crear entidades autónomas con roles y responsabilidades definidas que puedan pensar y actuar por sí mismas.
¿Qué es una clase en ABAP?
Ahora que tienes una idea de qué objetos sonQuizás te preguntes cómo son los objetos. definido en primer lugar. A diferencia de otros tipos de variables con los que quizás esté acostumbrado a trabajar (por ejemplo, números enteros o cadenas), este proceso requiere bastante reflexión. Dado que un objeto, por definición, puede referirse literalmente a cualquier cosa (es decir, una persona, lugar, cosa o idea), primero necesitas descubrir la tipos de objetos que necesita para modelar el dominio de su problema. Por ejemplo, si está creando una solución de contabilidad financiera, probablemente necesitará objetos para representar elementos como cuentas y libros mayores.
A veces este proceso de análisis es intuitivo; otras veces, no tanto. En estos últimos casos, deberás ordenar tus pensamientos mediante un proceso ordenado y metódico. Un enfoque común para iniciar este proceso es revisar los documentos de requisitos y subrayar todos los sustantivos que se utilizan para describir diversos aspectos del dominio del problema. Luego, a partir de ahí, puede organizar aún más los objetos examinando sus funciones y responsabilidades, así como sus relaciones con otros objetos. Los primeros investigadores de POO observaron que la naturaleza de este proceso de análisis tenía muchas similitudes con las técnicas de clasificación utilizadas por los biólogos para identificar, categorizar y comprender las relaciones entre plantas y animales. En consecuencia, el término clase fue usado para describir (o clasificar) estos tipos de datos abstractos y, a lo largo de los años, el nombre se ha mantenido.
Cómo las clases definen los tipos de objetos (en comparación con las estructuras)
En términos prácticos, puedes pensar en una clase como si fuera una declaración de tipo especializada. Es decir, una declaración de clase define la tipo de un objeto. Este concepto de escritura debería resultar intuitivo para los desarrolladores ABAP que están acostumbrados a trabajar con estructuras y tablas internas. Por ejemplo, a continuación puede ver cómo definimos una variable de estructura llamada LS_PERSON en términos de un tipo personalizado que declaramos llamado TY_PERSON. Esta declaración de tipo personalizado le dice al compilador ABAP cómo se verá la estructura LS_PERSON en tiempo de ejecución (es decir, qué campos de componentes tendrá la estructura).
TYPES: BEGIN OF ty_person,
first_name TYPE string,
last_name TYPE string,
END OF ty_person.
DATA ls_person TYPE ty_person.
De clase a objeto: creación de instancias en tiempo de ejecución
Con las declaraciones de tipo de clase, básicamente estás intentando lograr lo mismo; La única diferencia es que estás declarando una clase de objetos en lugar de una estructura o tabla interna. Por ejemplo, en el siguiente listado puede ver cómo definimos un tipo de clase personalizada llamada LCL_PERSON. Observe las similitudes entre esta declaración de tipo de clase y la declaración de tipo TY_PERSON anterior. Esto no es casualidad, ya que las clases son, en muchos aspectos, simplemente otra forma de ADT.
CLASS lcl_person DEFINITION.
PRIVATE SECTION.
DATA mv_first_name TYPE string.
DATA mv_last_name TYPE string.
ENDCLASS.
DATA lo_person TYPE REF TO lcl_person.
Cuando observa las declaraciones de tipos de clases desde esta perspectiva, puede comenzar a apreciar la relación entre clases y objetos. Conceptualmente hablando, es apropiado pensar en clases como plantillas (o planos) que un entorno de ejecución de programación orientada a objetos puede utilizar para descubrir cómo crear instancias de objetos en tiempo de ejecución. Por lo tanto, la relación entre un objeto y una clase normalmente se describe como un objeto es una instancia de una clase en la jerga de programación orientada a objetos.
Cómo varias instancias de objetos comparten una definición de clase
Esta relación se ilustra desde una perspectiva de tiempo de ejecución en la siguiente figura. Aquí puede ver cómo se crea (o se crea) un número arbitrario de instancias de la clase LCL_PERSON. instanciado) en tiempo de ejecución. Cada instancia de objeto creada es única e independiente por derecho propio (es decir, tiene su propio espacio de memoria). Por ejemplo, observe cómo cada instancia de objeto contiene sus propios valores para los atributos FIRST_NAME y LAST_NAME. Si cambiara el atributo FIRST_NAME para la primera instancia de objeto, las otras instancias de objeto no se verían afectadas porque son entidades independientes. De hecho, lo único que estos objetos realmente tienen en común en tiempo de ejecución es su clase de definición compartida.
Comprensión de las interfaces de clase y los métodos públicos
En la sección anterior, destacamos algunas de las similitudes entre los tipos de clases y otros ADT familiares, como estructuras o tablas internas. Si bien esta analogía es útil para comprender cómo se definen conceptualmente los objetos, comienza a fallar cuando nos acercamos a la especificación de los métodos de una clase. Métodos, que son conceptualmente como subrutinas (formas en lenguaje ABAP) o funciones en programación procedimental, definen los puntos de interacción que permiten comunicar con instancias de objetos en tiempo de ejecución. En términos más formales, los métodos constituyen el conjunto de una clase. interfaz.
Para ilustrar la idea de la interfaz de una clase, considere la declaración de tipo de clase LCL_PERSON revisada.
CLASS lcl_person DEFINITION.
PUBLIC SECTION.
METHODS:
talk,
walk.
PRIVATE SECTION.
DATA mv_first_name TYPE string.
DATA mv_last_name TYPE string.
ENDCLASS.
CLASS lcl_person IMPLEMENTATION.
METHOD talk.
WRITE: / 'Hello'.
ENDMETHOD.
METHOD walk.
...
ENDMETHOD.
ENDCLASS.
Cómo los métodos permiten la interacción con objetos
Con la adición de métodos como talk() y walk(), las instancias de la clase LCL_PERSON de repente adquieren bastante más personalidad. De hecho, puede utilizar estos métodos para (programáticamente) decirle a sus objetos qué hacer. Por ejemplo, puede decirle a una instancia de persona que hable llamando al método talk() o que camine invocando el método walk(). Tales comportamientos transforman objetos de estructuras de datos inanimadas en entidades vivas que respiran, que son conscientes de sí mismas y, hasta cierto punto, autónomas. Además, con los datos de sus atributos en contexto, los objetos saben inherentemente qué son, cuál es su estado actual y qué tipo de operaciones pueden realizar.
La diferencia entre clases y objetos en ABAP queda clara una vez que se separan las definiciones en tiempo de diseño del comportamiento en tiempo de ejecución. Una clase es un modelo que define la estructura de un objeto y las acciones disponibles, mientras que un objeto es una instancia concreta creada a partir de ese modelo durante la ejecución del programa.
En los objetos ABAP, las clases desempeñan un papel similar a las declaraciones de tipos personalizados, pero con una mejora crucial: definen no sólo los datos, sino también el comportamiento a través de métodos. Los objetos, a su vez, encapsulan tanto el estado como la funcionalidad, lo que permite a los programas ABAP modelar entidades del mundo real como unidades independientes y autónomas.
Una vez que comprenda que los objetos son instancias de clases y que los métodos forman la interfaz a través de la cual los objetos interactúan con el resto de su programa, ABAP orientado a objetos comienza a parecer mucho más intuitivo. Este modelo mental sienta las bases para conceptos avanzados como encapsulación, polimorfismo y diseño de aplicaciones ABAP limpio y mantenible.
Nota del editor: esta publicación ha sido adaptada de secciones de los libros. Programación orientada a objetos con objetos ABAP por Jeffrey Boggess, Colby Hemond, James Maderay José Ruperto. jeffrey es un especialista en integración empresarial de Bowdark Consulting enfocado en crear integraciones perfectas entre SAP, Azure y Dataverse para resolver desafíos comerciales complejos y brindar soluciones confiables para los clientes. colby es consultor técnico senior en Bowdark Consulting, donde se dedica a brindar ideas y soluciones innovadoras a los clientes y apoyarlos en su transformación digital. Jaime es el fundador y director ejecutivo de Bowdark Consulting, Inc., una firma de consultoría especializada en tecnología y desarrollo personalizado en el panorama de SAP. José es arquitecto de datos senior en Bowdark Consulting, Inc. con experiencia en la migración de entornos SAP complejos a plataformas en la nube, lo que permite ecosistemas de datos escalables, seguros y de alto rendimiento.
Esta publicación se publicó originalmente el 1/2026.
