Programación orientada a objetos

Barcelona, 7 y 9 de Mayo de 2014

Contenido del curso

1. Introducción a la Programación Orientada a Objetos

i. ¿Que son y para que sirven las clases y objetos?

2. Caso de negocio
i. Encapsulamiento de funcionalidades
ii. Solución aplicada a un cliente
iii. Utilización de clases en ALV sin orientación a objetos

3. Programación Orientada a Objetos

i. Clase global
ii. Eventos
iii. Excepciones

4. Conclusiones del curso

i. ¿Tiene algún benefició utilizar clases?
ii. Pros y contras de la utilización de clases.
Contenido del curso
1. Introducción a la Programación Orientada a Objetos
i. ¿Que son y para que sirven las clases y objetos?

2. Caso de negocio
i. Encapsulamiento de funcionalidades
ii. Solución aplicada a un cliente
iii. Utilización de clases en ALV sin orientación a objetos

3. Programación Orientada a Objetos

i. Clase global
ii. Eventos
iii. Excepciones

4. Conclusiones del curso

i. ¿Tiene algún benefició utilizar clases?
ii. Pros y contras de la utilización de clases.
1. Programación Orientada a Objetos

Introducción
El objetivo de este curso es entender la utilización de clases en lenguajes de programación y
aplicar estos conocimientos al lenguaje ABAP.

Para ello, veremos:

• Definición de clases.

• Métodos, atributos,
excepciones.

• Herencia
1. Programación Orientada a Objetos

Introducción
Para los ejemplos a realizar durante este curso cada alumno se creará un paquete de
desarrollo o personal:

ZFO_POO_NNAABB donde serán las dos primeras letras de su nombre AA serán las dos
primeras letras de su apellido y BB las dos primeras letras de su segundo apellido.
1. Programación Orientada a Objetos

1.1 ¿Que son y para que sirven las clases y objetos?

- Las clases nos permiten definir una abstracción del mundo

real, con ello se permite definir:

- Características que definen esa realidad con atributos.

- Comportamiento de los estados mediante métodos.

- Controlar sus características y comportamientos por

medio de excepciones.

¿Entonces, trabajar con clases es lo mismo que trabajar con

funciones y variables?
1. Programación Orientada a Objetos

1.1 ¿Que son y para que sirven las clases y objetos?

- Las funciones nos permiten modelar comportamientos.

- Los grupos de función nos permiten agrupar las funciones y definir

variables a nivel global

- Las funciones y grupos de funciones también permiten modelar la

realidad como las clases, pero, la gestión de datos puede ser muy
complicada cuando existen varios “objetos” iguales con datos distintos.

- Las excepciones en las funciones las capturamos mediante SY-SUBRC

y no nos aporta mucha información. En clases, podemos configurar el
control de las excepciones.
 1. Programación Orientada a Objetos

1.1 ¿Que son y para que sirven las clases y objetos?

- Si las clases modelan la realidad, ¿Qué son los objetos?

Son el un reflejo de algo real, contienen su estado

(atributos) y funcionamiento (métodos). Estos son descritos
por la clase.
Coca·Cola o OBJETOS

Molde o CLASE

Misma clase (distintos atributos)

1. Programación Orientada a Objetos

1.1 ¿Que son y para que sirven las clases y objetos?

- Por lo tanto, en tiempo de edición podríamos diseñar nuestro

molde o clase, y sus métodos que definirían los estados

Constructor Método llenar Destructor

- Una vez diseñado, podríamos crear objetos a partir de la clase

definida. Estos podrían ir cambiando de estado en función del
estado.
Contenido del curso
1. Introducción a la Programación Orientada a Objetos
i. ¿Que son y para que sirven las clases y objetos?

2. Caso de negocio
i. Encapsulamiento de funcionalidades
ii. Solución aplicada a un cliente
iii. Utilización de clases en ALV sin orientación a objetos

3. Programación Orientada a Objetos

4. Ejercicios
i. Ejemplos de creación de clases
• Clase global
• Clase local
• Excepciones
• ALV

5. Conclusiones del curso

i. ¿Tiene algún benefició utilizar clases?
ii. Pros y contras de la utilización de clases.
2. Caso de negocio

2.1 Encapsulamiento de funcionalidades

- El módulo de Recursos Humanos en ALLIANZ existen

procedimientos que se realizan comúnmente (obtener DNI,
dirección de correo electrónico, etc…).
2. Caso de negocio

2.1 Encapsulamiento de funcionalidades

- Para poder controla los errores al enviar mails, se creo un

método que gestionaba el envió de mails y corta la ejecución
del código en caso de error.
2. Caso de negocio

2.2 Solución aplicada a un cliente

- Para un proyecto de presupuestos en GISA se requería cargar

datos de presupuestos de obras y gastos de estructura y
proyectos diferenciado por años.

- Se analizó la mejor solución y se decidió utilizar clases y

herencia que facilitó las tareas de construcción y ejecución del
código.

- La solución se pudo reutilizar en un módulo extra para

generación de informes.
2. Caso de negocio

2.2 Solución aplicada a un cliente

En el motor se utilizaba herencia para

determinar el tipo de presupuesto
2. Caso de negocio

2.2 Solución aplicada a un cliente

- La solución pasaba por una clase padre que realizaba lecturas

de ficheros y gestión de estados (abierto, en curso, cerrado),
guardar datos.

- Las clases hijas gestionaban cada uno de los presupuestos:

Proyectos, obras, estructura.

- Cada clase tenia como atributos el presupuesto en una tabla

que se utilizaba para los ALV’s y para la generación de informes
en EXCEL.
 2. Caso de negocio

2.2 Utilización de clases en ALV sin orientación a objetos

- Para un informe básico se creo un ALV con la función

REUSE_ALV_GRID_DISPLAY.

- En la fase de pruebas integradas se detecto que los totales no

realizaban el promedio en función de campos calculados.
Cliente Pedido Importe % Pagado % Pagado
1 1 120 44,4 100 83,3%
1 2 150 55,6 130 86,7%
1 270 230 170%

- El resultado del sumatorio es 170, y se debía aplicar un calculo en

función de campos parametrizados en una taba.
 2. Caso de negocio

2.2 Solución aplicada a un cliente

- Para poder modificar una línea de total, se paso el ALV a OO

pero no se modificó el programa principal.
DATA: lo_grid TYPE REF TO cl_gui_alv_grid.

* Obtenemos el ALV en formato OO Obtenemos el ALV y lo

CALL FUNCTION 'GET_GLOBALS_FROM_SLVC_FULLSCR' pasamos a objetos
IMPORTING
e_grid = lo_grid.

* Obtenemos la lina de subtotales Tratamos el ALV como si fuera

DATA: it_01 TYPE REF TO data. Orientado a objetos

CALL METHOD lo_grid->get_subtotals

IMPORTING
ep_collect01 = it_01.
Contenido del curso
1. Introducción a la Programación Orientada a Objetos
i. ¿Que son y para que sirven las clases y objetos?

2. Caso de negocio
i. Encapsulamiento de funcionalidades
ii. Solución aplicada a un cliente
iii. Utilización de clases en ALV sin orientación a objetos

3. Programación Orientada a Objetos

i. Clase global
ii. Eventos
iii. Excepciones
iv. Herencia

4. Conclusiones del curso

i. ¿Tiene algún benefició utilizar clases?
ii. Pros y contras de la utilización de clases.
 3. Programación Orientada a Objetos
Modelo clásico de Programación

- Durante el proceso de encapsulamiento y reutilización de código en ABAP

se acostumbra a crear grupos de funciones y funciones que nos permiten
reutilizar funcionalidades.

- En programación orientada a objetos, un ejemplo clásico de programación

OO es la clase vehículo. Pero… ¿se podría evitar el uso de clases para
simular el vehiculo?

- ¿Como se crearía la típica clase coche si ABAP no soportase orientación a

objetos?
 3. Programación Orientada a Objetos
Modelo clásico de Programación

1. Separación de datos y funciones.

2. Usualmente se acede a los datos no

encapsulados.

3. Posibilidad de encapsular funciones usando

la modularización.

Generalmente las variables globales

contienen los datos del programa y las
subrutinas contiene las variables locales.
 3. Programación Orientada a Objetos
Modelo clásico de Programación

Definición de los Tipos

Definición de los Datos

Programa Principal
- Llamar subrutinas
- Llamar módulo de funciones

Definición de Subrutinas

En el nivel principal del programa no existe una protección especial para los datos.
Las variables pueden ser modificadas en cualquier punto.
 3. Programación Orientada a Objetos
Modelo clásico de Programación

El grupo de funciones S_VEHICLE contiene

los servicios: INC_SPEED, DEC_SPEED, y
GET_SPEED.

Las funciones describen cambios de estado

para un atributo del grupo de funciones
 3. Programación Orientada a Objetos
Modelo clásico de Programación VS OO

- ¿Como gestionamos varios coches? ¿Y si hay mas datos a gestionar, velocidad,

combustible, KM?

- ¿Como protegemos y ordenábamos el acceso y modificación a los datos globales?

 3. Programación Orientada a Objetos
Modelo clásico de Programación VS OO
 3. Programación Orientada a Objetos
Modelo Programación OO

Con la OO, se considera que el

mundo real esta compuesto por
una colección de objetos, por
ejemplo; aviones, coches y gente.

Algunos de estos objetos son muy

similares se pueden describir
utilizando los mismos atributos o
características y se comportan de
la misma forma.

Una clase es una descripción de

una cantidad de objetos que se
caracterizan por las mismas
características y el mismo
comportamiento.
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase

everis acaba de ganar un importante proyecto con una pequeña compañía aérea de
aviones privados:

- Como requisitos se nos plantea:

- Gestión de 2 aviones

- Los datos a gestionar serán:

- Nombre de la compañía
- Nombre del avión (Código)
- Categoría del avión (1 a 5 estrellas)
- Número de vuelos del avión
- Nombre del piloto

- Tener la posibilidad de ampliar la flota con aviones nuevos

 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase

La solución optima pasa por utilizar todas las herramientas que la OO nos brindan:

- Creación de una clase que modelará la gestión de datos de cada avión

- Atributos estáticos para almacenar los datos globales de los aviones

- Atributos instanciados para almacenar los datos de cada avion

 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

Los componentes principales de una clases son:

- Tipo de clase: Visibilidad de la case

- Global / Local: Definida via SE24 o en un include.

- Atributos: “Variables” que contiene los datos que describen los estados
del objeto, estos a su vez pueden ser:
- Estáticos/Instanciados: Hay que crear un objeto o no
- Publicos/Protegidos /Privados: Visibilidad del atributo

- Métodos: Son las “Acciones” que podemos realizar dentro del objeto:
- Instanciados / Estaticos: Hay que crear un objeto o no
- Publicos/Protegidos /Privados: Visibilidad del atributo
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

Estático VS Instanciado

Atributos de Instancias: existen una vez por objeto, es decir una vez por cada
instancia de ejecución de la clase.

Atributos Estáticos: existen atributos una vez para cada clase y son visibles para
todas las instancias de ejecución de esa clase. Por lo general contienen información
que se aplica a todas las instancias, tales como:
• Tipos y Constantes.
• Buffer de Datos de Aplicación Central.
• Administración de Información, por ejemplo instancias de contadores.
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

La creación y mantenimiento de una clase global en SAP se realiza con la

transacción SE24:

La funcionalidad nos permite informar una clase (nueva o existente) y crear,

modificar o visualizar su contenido
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

Al crear una nueva clase un pop up nos permitirá crear la clase de manera rápida

* Al crear una clase se nos pedirá siempre una orden de transporte

 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

Una vez creada la clase se muestran las partes mas importantes del diseño en
pestañas:
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

En la pestaña atributos gestionamos los atributos de una clase, estos pueden ser
vistos como variables (Locales y globales)

- Los atributos pueden ser:

- Estáticos: No hay que crear una instancia (Objeto) de la clase para ser
usados, su modificación se reflejara en todos los objetos de la misma clase,
estos atributos se consideran globales.

- Instanciados: Sera propia de cada método y podrá tener valores distintos

para cada uno de ellos, estos atributos equivalen a las variables locales de
un objeto

- Constantes: Variables que nunca se podrá modificar su valor

 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

- Los atributos se pueden proteger:

- Privados: Solo se tendrá acceso des de métodos de la misma clase

- Públicos: Se podrá acceder des de fuera de la clase

- Protegidos: Se podrá acceder des de la misma clase o des de una clase que
hereda de esta.

- Para los atributos podemos definir su tipo de datos con TYPE/LIKE o TYPE REF TO
para incluir una clase dentro de la clase.

- READ-ONLY, significa los atributos públicos declarados con DATA pueden ser
leídos desde fuera, pero solo pueden ser modificados por los métodos de la
misma clase.
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

En la pestaña métodos gestionamos los métodos de una clase, estos pueden ser
vistos como funciones o performs

- Los métodos pueden ser:

- Estáticos: No hay que crear una instancia (Objeto) de la clase para ser
usados, su modificación se reflejara en todos los objetos de la misma clase,
estos atributos se consideran globales.

- Instanciados: Sera propia de cada método y podrá tener valores distintos

para cada uno de ellos, estos atributos equivalen a las variables locales de
un objeto
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

- Los métodos se pueden proteger:

- Privados: Solo se tendrá acceso des de métodos de la misma clase

- Públicos: Se podrá acceder des de fuera de la clase

- Protegidos: Se podrá acceder des de la misma clase o des de una clase que
hereda de esta.
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase – Teoría inicial

- Mediante la opción paramenters modificamos la interface del método. Esta no es

mas que los parámetros de entrada y salida que le pasaremos al método.

- Los parámetros pueden ser OPCIONALES y/o pasados por referencia

 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase global

- Como requisitos se nos plantea para la ficha del avión:

- Gestión de 2 aviones

- Los datos a gestionar serán:

- Nombre de la compañía
- Nombre del avión (Código) – Privado, solo se podrá visualizar
- Categoría del avión (1 a 5 estrellas)
- Número de vuelos del avión
- Nombre del piloto

- Realizar una prueba de la clase (instanciar un avión para test) .

 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase global

- Ejemplo de creación de atributos

- NOMBRE_COMPANIA: Será siempre el mismo para todos los aviones

- CODIGO_AVION: No se podrá modificar fuera de la clase
- TOTAL_VUELOS: Se modelará para implementar el contador
- MODEL: Solo crearemos tipos “AIRBUS”
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase global

- Ejemplo de creación de métodos

- SET_NOMBRE_COMPANIA: Mantiene el nombre de la compañía para todas las clases

- REALIZAR_VUELO: Añade un vuelo al total de vuelos del avion
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase global
Una vez creada nuestra clase hay que realizar pruebas unitarias de nuestro diseño,

Para ello, utilizaremos la funcionalidad de instanciar objetos:

Clase estática
Objeto
 3. Programación Orientada a Objetos
Aplicación práctica – Crear clase global

Ver ejemplo de generación mediante SE24

 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO – Teoría inicial

- Una vez realizadas las pruebas unitarias, el cliente nos pide que saquemos un
informe con los dos aviones.

- Para ello, realizaremos un report que nos permita trabajar con la nueva clase creada.

- Crearemos un report y 2 instancias de la clase avión, cada una representará uno

de los 2 aviones de la compañía.

- Avión 1: de categoría 3, su piloto será JOSE.

- Avión 2: de categoría 5, su piloto será JUAN.

 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO – Teoría inicial
• Los objetos se crean mediante la instrucción
CREATE OBJECT ref_name …..

• Sólo pueden ser creadas y dirigidas mediante variables de referencia.

Una clase contiene la descripción genérica de un objeto, es decir, todas las características que
todos los objetos de la clase tienen en común. Durante la ejecución del programa, la clase se
utiliza para crear objetos discretos (instancias) en la memoria. Este proceso se denomina
instanciación. Si esta es la primera vez que se accede a la clase, la clase también se carga en
la memoria.
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO – Teoría inicial
La definición de los objetos puede ser con TYPE REF TO
o LIKE

DATA r_vehicle1 TYPE REF TO lcl_vehicle

Para definir una variable de referencia, que es lo que

escribe como un puntero a los objetos del tipo
lcl_vehicle.

La referencia nula es el valor inicial técnica de una

variable de referencia. (El puntero apunta a nada.)
La sentencia CREATE OBJECT crea un objeto
en la memoria. Los valores de los atributos son
iniciales o un VALUE especifico asignado.

Las variables de referencia también pueden ser asignados

el uno al otro.

Para el ejemplo anterior, esto significa que después de la

instrucción MOVE, R_VEHICLE1 y R_VEHICLE2 apuntan
al mismo objeto.
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO – Teoría inicial
Una vez definida nuestra clase, podemos trabajar en ella des de cualquier punto en donde se
permita implementar código en SAP. En el caso de atributos y métodos estáticos, no
necesitamos declarar ningún Objeto

Los métodos estáticos (también

denominados métodos de clase) se llaman
utilizando

CALL METHOD classname=>method_name ....

Como atributos estáticos, métodos

estáticos se abordan con su nombre de la
clase, ya que no necesitan instancias.
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO – Teoría inicial
Los métodos de instancias se llama con

CALL METHOD ref->method_name …

Cuando se llama a un método de instancia

desde otro método de instancia, se puede
omitir el nombre de la instancia ref. El
método se ejecuta de forma automática para
el objeto actual.

Una sintaxis más corta también se admite

como de SAP Web AS 6.10. En este caso,
el CALL METHOD se omite y los
parámetros se indican entre paréntesis.

Los parámetros de RECEIVING, IMPORTING y CHANGING se

excluyen mutuamente. De lo contrario, las mismas reglas se
aplican aquí como lo hacen para llamar a un módulo de función.
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO – Teoría inicial
El típico cas donde el
Garbage Collector nos es
• Y ¿Cuándo se destruyen estos objetos creados en el
útil es en ALV que crean su
programa?. fieldcatalog mediante los
datos definidos en el TOP,
• Todos los objetos que ya no se puede acceder muchas veces al modificar
sintácticamente son eliminadas por el recolector de un campo no vemos esos
basura “Garbage Collector”, esté funciona de manera cambios reflejados en
automática o mediante la instrucción FREE (destructor). tiempo de ejecución.

En este ejemplo,
Forzamos la destrucción del
objeto, el Garbaje Collector nos
eliminara de la memoria estos
objetos
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO
- Ejemplo del código de gestión de los objetos:
- Para ello nos puede ayudar el patrón de creación:

Gestión de métodos estáticos /Instanciados

Constructor
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO
- La definición de los aviones sería la siguiente:

DATA: lc_avion1 TYPE REF TO ZCL_AVION.

DATA: lc_avion2 TYPE REF TO ZCL_AVION.

CREATE OBJECT LC_AVION1

EXPORTING
I_CAT_AVION = '3'
I_NOMBRE_PILOTO = 'JOSE'.

CREATE OBJECT LC_AVION2

EXPORTING
I_CAT_AVION = '5'
I_NOMBRE_PILOTO = 'JUAN'.
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO
- El uso de métodos y variables estáticas permite modificar los objetos de manera masiva:

Atributo NOMBRE_COMPANIA

CALL METHOD LC_AVION1->SET_NOMBRE_COMPANIA

EXPORTING
I_NOMBRE_COMPANIA = ‘…..'.
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO

Analizar ejemplo 1
 3. Programación Orientada a Objetos
Aplicación práctica – Utilización OO

- ¿Cual es el principal problema del

ejemplo anterior?

- ¿Existe una manera mas optima de

gestionar mas de un objeto?
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos

- Después de entregar a nuestro cliente el report y clase, nos comenta que necesitaría
gestionar los datos globales de su empresa, ya que se están expandiendo de 2 a 10
aviones, por tanto necesita:

- Alta masiva de aviones (mediante parámetro de entrada “número de aviones”)

- Baja de aviones de la compañía
- Número de aviones actuales en la flota
- Número total de vuelos en tiempo real

- Por lo tanto nuestra solución pasaría por la creación de una nueva clase y la gestión
de eventos para contar el total de vuelos de la compañía en tiempo real.
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial

Si desea mantener varios objetos de la

misma clase en el programa, se puede
definir una tabla interna que contiene una
columna con las referencias a objetos de
esta clase.

Cuando se utiliza una tabla interna de una

sola columna y desea programar
condiciones lógicas para la instrucción
LOOP, se utiliza el componente
TABLE_LINE.

Para hacer esto, sin embargo, los atributos

pertinentes deben ser públicos.
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial

En ABAP Objects hay ciertos métodos que se conocen como

disparadores (triggers) y otros que se conocen como
manejadores (handlers).

Los eventos se disparan mediante disparadores o triggers

implementados en el código del método

Los manejadores o handlers reciben la orden de los

disparadores y ejecutan su codigo .
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial
Los eventos se registran mediante la
instrucción SET HANDLER. El registro
sólo se activa durante la ejecución del
programa. Si no se registra el evento,
este no se disparará.

Con eventos de instancia, FOR va

seguido de la referencia al objeto que
provoca el evento. Como alternativa,
también puede utilizar la adición ALL
INSTANCES. De esta manera, también
puede registrar los objetos que aún no
se han creado.

La adición,
ACTIVATION ’X’ es opcional. Para
dejar si efecto el registro ACTIVATION
space.

Puede registrar varios métodos con

una sentencia SET-HANDLER:
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial

- Para la utilización del evento el primer paso es definir el evento con su nombre y
parametros:

CLASS <classname> DEFINITION.

EVENTS: <event> EXPORTING VALUE ( <ex_par> ) TYPE type.

CLASS <classname> IMPLEMENTATION. METHOD <m>.

RAISE EVENT <event> EXPORTING VALUE <ex_par> = act_par>.
CLASS lcl_airplane DEFINITION.
- Como en el caso de atributos y métodos, PUBLIC SECTION.
METHODS arrive_at_airport.
EVENTS touched_down EXPORTING VALUE (ex_name) TYPE string.

los eventos también pueden ser PRIVATE SECTION.

DATA: name TYPE string.

Instanciados o estáticos y públicos,

ENDCLASS.

CLASS lcl_airplane IMPLEMENTATION.

protegidos y privados METHOD
……. arrive_at_airport.
RAISE EVENT touched_down EXPORTING ex_name = name.
ENDMETHOD.
ENDCLASS.
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial
- Una vez creado el evento, este se puede disparar en cualquier método de la clase
mediante la instrucción RAISE EVENT

- En tiempo de ejecución el evento se ejecutará en el método asociado igual que si

fuese una llamada a un evento.

- En el ejemplo anterior, primeramente se ejecutaría el código del evento y

posteriormente la suma.
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial

- El siguiente paso es ligar la clase destino con el evento creado en la clase que dispara
el evento, para ello utilizaremos el asistente:
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial

- Una vez creado el evento y definidas las clases asociadas al evento, en el programa
se instanciará el evento.

- Es importante realizar este último paso, ya que sino, no se dispara el evento.

- La sentencia FOR nos permiten discriminar para que clase o clases se escuchará el
evento a ejecutar.
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial

- Ver ejemplo 2
 3. Programación Orientada a Objetos
Aplicación práctica – Eventos – Teoría inicial

- ¿Existe alternativa a los eventos

utilizando funciones?

- ¿Existe algún casos típicos de

utilización de eventos?
 3. Programación Orientada a Objetos
Aplicación práctica – Excepciones

- Nuestro cliente ya dispone de toda la funcionalidad para la gestión, pero nos pide
adecuar nuestras clases a una funcionalidad de selección de vuelos de otro
proveedor y añadir un sistema de errores.

- Los requisitos son llamar a una clase estática que nos devolverá los datos de la tabla
DV_FLIGHTS.

- El cliente nos ha avisado que el otro proveedor esta en fase de pruebas, con lo
que tendremos de blindar nuestras clases para evitar posibles errores.

- Cada avión podrá realizar un máximo de 7 vuelos sin pasar revisión

 3. Programación Orientada a Objetos
Aplicación práctica – Excepciones – Teoría inicial
Utilizamos el término excepción para referirnos a una situación que se presenta mientras un programa no
puede continuar su ejecución (ya sea por error o porque no se dan las condiciones).

Excepciones basadas ​en clases se plantean ya

sea mediante la instrucción RAISE EXCEPTION, o
por el entorno de ABAP. La división por cero, por
ejemplo, sería un ejemplo de esto último.

En una situación de excepción, la excepción está

representada por un objeto de excepción - es decir,
una instancia de una clase de excepción. Los
atributos de cada objeto de excepción contienen
información sobre la situación de error.

Se pueden definir las clases de excepción, pero ya

hay una serie de clases de excepciones
predefinidas en el sistema.

Si una excepción basada en la clase se eleva, el

Todas las clases de excepción se derivan de una clase sistema interrumpe el flujo normal de un programa
CX_NO_CHECK, CX_DYNAMIC_CHECK, o y trata de navegar a un controlador adecuado. Si
CX_STATIC_CHECK, derivados a partir de la no puede encontrar un controlador, se produce un
CX_ROOT superclase común. error en tiempo de ejecución.
 3. Programación Orientada a Objetos
Aplicación práctica – Excepciones – Teoría inicial

La forma en que se asignan clases de excepción a uno de estos tres caminos en la jerarquía define cómo
se propagan las excepciones asociadas.

En el sistema estándar SAP, los nombres de

todas las clases de excepción comienzan con
CX_.

La clase CX_ROOT proporciona algunos

métodos predefinidos que son heredados por
todas las clases de excepción: El método
GET_SOURCE_POSITION
devuelve el nombre del programa principal y (en
su caso) los nombres de los incluirá programa y
el número de línea en el código fuente de donde Todas las clases de excepción heredan el atributo
se produjo la excepción. El método get_text KERNEL_ERRID de CX_ROOT. Este atributo contiene el
devuelve un texto de la excepción en la forma nombre del error de ejecución apropiado si la excepción se
de una cadena. elevó por el entorno de ejecución - tal como
BCD_ZERODIVIDE si el programa de capturas de una
excepción CX_SY_ZERODIVID (división por cero). Si la
excepción no está en la lista, se produce un error en tiempo
de ejecución.
 3. Programación Orientada a Objetos
Aplicación práctica – Excepciones – Teoría inicial
Una excepción sólo puede ser gestionada si está encerrada en un bloque TRY-ENDTRY. La excepción se
trata mediante la instrucción CATCH en el bloque TRY-ENDTRY.

El bloque TRY contiene el conjunto de sentencias

que se encargan de las excepciones.
Si se produce una excepción en el bloque TRY, el
sistema busca (el capturador de excepciónes
CATCH) en el mismo bloque TRY-ENDTRY y luego
paso a paso hacia el exterior en todos los bloques
TRY-ENDTRY envolventes.

Al igual que todas las estructuras de control de

ABAP, la estructuras TRY-ENDTRY se pueden
En algunos casos, el sistema no puede anidar a cualquier profundidad. Así, el bloque TRY,
encontrar un controlador para una excepción bloques CATCH, y el bloque de limpieza en
dentro de un bloque TRY-ENDTRY específico, particular, pueden contener otros bloques TRY-
pero la excepción se maneja en un bloque TRY-
ENDTRY..
ENDTRY rodea o reproducidos a un programa
de llamada. Si esto ocurre, una
LIMPIEZA (cleanup) bloque se ejecuta antes de
abandonar el bloque TRY-ENDTRY.
 3. Programación Orientada a Objetos
Aplicación práctica – Excepciones – Teoría inicial

De manera mas sencilla también podemos generar nuestras propias excepciones mediante la
creación de una excepción básica:
 3. Programación Orientada a Objetos
Aplicación práctica – Excepciones

El resultado final del control de errores seria el siguiente:

TRY.

* "Creamos" los aviones

CREATE OBJECT LC_AVION1
EXPORTING
I_CAT_AVION = '3'
I_NOMBRE_PILOTO = 'JOSE'.

* Seleccionamos los vuelos

CALL METHOD ZCL_VUELOS=>GET_VUELOS
WRITE:/ 'Intentado realizar 8 vuelos:'.
IMPORTING
CALL METHOD LC_AVION1->REALIZAR_VUELO.
T_VUELOS = lt_vuelots.
CALL METHOD LC_AVION1->REALIZAR_VUELO.
CALL METHOD LC_AVION1->REALIZAR_VUELO.
CALL METHOD LC_AVION1->REALIZAR_VUELO.
CREATE OBJECT LC_AVION2
CALL METHOD LC_AVION1->REALIZAR_VUELO.
EXPORTING
CALL METHOD LC_AVION1->REALIZAR_VUELO.
I_CAT_AVION = '5'
CALL METHOD LC_AVION1->REALIZAR_VUELO.
I_NOMBRE_PILOTO = 'JUAN'.
on es

CALL METHOD LC_AVION1->REALIZAR_VUELO

* Capturamos los posibles errores
EXCEPTIONS
por c l excepci

CATCH CX_ROOT INTO CX_ROOT.

REVISION = 1
CALL METHOD CX_ROOT->IF_MESSAGE~GET_TEXT
others = 2.
RECEIVING
IF SY-SUBRC <> 0.
lase
ro

RESULT = l_text. Conun

WRITE:/ 'Se está intentando realizar trovuelo
l excesin revisión!'.
pcion
Cont

WRITE:/ l_text. es
ENDIF.
ENDTRY.
 3. Programación Orientada a Objetos
Aplicación práctica – Excepciones

Ver ejemplo 3
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos
- Nuestro cliente ha decidido invertir en aviones de transporte de mercancías, a partir de
ahora se gestionarán dos tipos de aviones

- Aviones de pasajeros: Contaremos el número de vuelos y de pasajeros.

- Aviones de carga : Contaremos el número de vuelos y de kg transportados.

- Por lo tanto, nuestra solución propuesta deberá incluir herencia que nos permitirá
gestionar los aviones ya sean del tipo pasajeros o del tipo carga.
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos – Teoría inicial

Herencia:
Define la relación de
implementación entre clases, por
lo que una clase (la subclase)
adopta la estructura y el
comportamiento de la otra clase
(superclase).

Polimorfismo:
Es cuando las instancias de
diferentes clases responden
diferente a los mismos mensajes.
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos – Teoría inicial

En la herencia de clases, la super clase puede implementar atributos y métodos

que serán utilizados por la subclase, de esta manera para distintos tipos de
subclases podemos definir comportamientos comunes
Lcl_airplane

-name
-weight
+ get_fuel_level ( )
+ estimate_fuel ( )

Lcl_passenger_airplane Lcl_cargo_airplane
-seats -name
-emergency_exits -weight
…. ….

+ get_seats ( ): + get_cargo ( ):
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos – Teoría inicial

- En herencia se puede aplicar el concepto de CLASE ABSTRACTA, las

clases abstractas son aquellas que no se puede instanciar, Por lo tanto, las
clases abstracta nos servirán exclusivamente para modelar.

- Para poder definir una clase como superclase, deberemos tener el flag de
clase final siempre en “blanco”.
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos – Teoría inicial

- Para poder definir la subclase, crearemos una clase des de la SE24 y

indicaremos la clase hereda, el wizard nos añadira los metodos y atributos
heredados
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos – Teoría inicial

- Una vez implementados los metodos propios de la subclase, podemos

realizar pruebas unitarias como en el caso de la creación de clases
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos – Teoría inicial

- En algunas ocasiones se requiere redefinir la funcionalidad heredada, para

ello, podemos utilizar la funcionalidad de redefinir método:

- La instrucción SUPER->, ejecuta el

método de la superclase
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos – Teoría inicial

- El polimorfismo permite trabajar directamente con un objeto tipo superclase

para referenciar a objetos de la subclase.

- Para asignar la subclase a la superclase lo hacemos mediante:

lc_super ?= lc_subclase

- Una vez asignado, el objeto de la superclase se compará como el de la

subclase
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos

Ver ejemplo 4
Contenido del curso
1. Introducción a la Programación Orientada a Objetos
i. ¿Que son y para que sirven las clases y objetos?

2. Caso de negocio
i. Encapsulamiento de funcionalidades
ii. Solución aplicada a un cliente
iii. Utilización de clases en ALV sin orientación a objetos

3. Programación Orientada a Objetos

i. Clase global
ii. Eventos
iii. Excepciones

4. Conclusiones del curso

i. ¿Tiene algún benefició utilizar clases?
ii. Pros y contras de la utilización de clases.
 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos

¿Tiene algún benefició utilizar clases?

Pros y contras de la utilización de clases.

 3. Programación Orientada a Objetos
Aplicación práctica – Otros conceptos

Para instalar los ejemplos instalar de SAP link.

1 – Crear el paquete ZCURSO_OO, via SE80

2 – Instalar mediante SAPLink el paquete anterior

Instalador

3 – Creamos la tabla de clases, via SE11: