TAW12_01

431
TAW12_1 Objetos ABAP y Æreas de aplicacin SAP NetWeaver Fecha Centro de formacin Instructores PÆgina Web de formacin Manual del instructor Versin del curso: 63 Duracin del curso: 5 da(s) Nœmero de material: 50090661 Responsable: Christian Braun (D035329) An SAP Compass course - use it to learn, reference it for work

description

TAW12_01

Transcript of TAW12_01

Page 1: TAW12_01

TAW12_1Objetos ABAP y áreas de

aplicaciónSAP NetWeaver

Fecha

Centro de formación

Instructores

Página Web deformación

Manual del instructorVersión del curso: 63Duración del curso: 5 día(s)Número de material: 50090661Responsable: Christian Braun (D035329)

An SAP Compass course - use it to learn, reference it for work

Page 2: TAW12_01

Copyright

Copyright © 2009 SAP AG. Reservados todos los derechos.

Esta publicación no puede ser reproducida o trasmitida, total o parcialmente, de ninguna forma nipara ningún propósito sin el permiso expreso de SAP AG. La información aquí contenida puede sermodificada sin previo aviso.

Algunos productos de software distribuidos por SAP AG y sus distribuidores contienen componentesde software que pertenecen a otros proveedores de software.

Marcas registradas

� Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® y SQL Server® sonmarcas registradas certificadas de Microsoft Corporation.

� IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®,S/390®, AS/400®, OS/390® y OS/400® son marcas registradas certificadas de IBMCorporation.

� ORACLE® es una marca registrada certificada de ORACLE Corporation.� INFORMIX®-OnLine para SAP y INFORMIX® Dynamic ServerTM son marcas registradas

certificadas de Informix Software Incorporated.� UNIX®, X/Open®, OSF/1® y Motif® son marcas registradas certificadas de Open Group.� Citrix®, Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,

VideoFrame®, MultiWin® y otros nombres de productos Citrix referidos aquí son marcasregistradas de Citrix Systems, Inc.

� HTML, DHTML, XML, XHTML son marcas registradas o marcas registradas certificadas deW3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

� JAVA® es una marca registrada certificada de Sun Microsystems, Inc.� JAVASCRIPT® es una marca registrada certificada de Sun Microsystems, Inc., utilizada bajo

licencia para tecnología desarrollada e implementada por Netscape.� SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow,

SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo y mySAP.comson marcas registradas o marcas registradas certificadas de SAP AG en Alemania y en otrospaíses en todo el mundo. Todos los otros productos mencionados son marcas registradas omarcas registradas certificadas de sus respectivas empresas.

Declaración de renuncia

SAP DISTRIBUYE ESTE MATERIAL SOBRE UNA BASE "AS IS" Y NO SE HACERESPONSABLE EXPRESAMENTE, DE FORMA DIRECTA NI INDIRECTA, INCLUYENDOSIN RESTRICCIÓN LAS GARANTÍAS DE COMERCIABILIDAD E IDONEIDAD PARA UNOBJETIVO PARTICULAR, EN LO QUE CONCIERNE A ESTE MATERIAL Y AL SERVICIO,LA INFORMACIÓN, EL TEXTO, GRÁFICOS, LINKS O CUALQUIER OTRO MATERIAL YPRODUCTOS AQUÍ CONTENIDOS. EN NINGÚN CASO SAP SE RESPONSABILIZARÁ DECUALQUIER DAÑO DIRECTO, INDIRECTO, ESPECIAL, SECUNDARIO, CONSIGUIENTE,O PUNITIVO DE CUALQUIER CLASE, INCLUIDOS SIN LIMITACIÓN INGRESOS OGANANCIAS PÉRDIDAS, QUE PUEDAN SER RESULTADO DEL EMPLEO DE ESTOSMATERIALES O COMPONENTES DE SOFTWARE INCLUIDOS.

g20090710145054

Page 3: TAW12_01

Sobre este manualLa función de este manual es complementar la presentación del instructor deeste curso y servir como fuente de referencia. Este manual no está pensado parael estudio autodidacta.

Convenciones tipográficasEn esta guía se utilizan las siguientes convenciones tipográficas.

Estilo de tipo Descripción

Texto de ejemplo Palabras o carácteres que aparecen en la pantalla.Aquí se incluyen nombres de campos, títulos depantallas, pulsadores así como nombres de menús,vías de acceso y opciones.

También se usan como referencia a otra documentacióntanto interna como externa.

Texto de ejemplo Palabras o frases acentuadas en textos principales,títulos de gráficos y tablas

TEXTO DE EJEMPLO Nombres de elementos en el sistema. Aquí se incluyennombres de informes, nombres de programas, códigosde transacciones, nombres de tablas y algunas palabrasclaves de un lenguaje de programación cuando seencuentran en el texto principal, por ejemplo SELECTe INCLUDE.

Texto de ejemplo Salida en pantalla. Aquí se incluyen nombres dearchivos y directorios y sus vías de acceso, mensajes,nombres de variables y parámetros y párrafos deltexto fuente de un programa.

Texto deejemplo

Entrada exacta de usuario. Son palabras y carácteresque se introducen en en el sistema exactamente comoaparecen en la documentación.

<Texto deejemplo>

Entrada variable de usuario. Las entradas entrecorchetes indican que se deben sustituir estas palabrasy carácteres con entradas apropiadas.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. iii

Page 4: TAW12_01

Sobre este manual TAW12_1

Iconos en el texto principalEn este manual se utilizan los siguientes iconos.

Icono Significado

Para más información, sugerencias o detalles

Nota o más explicaciones sobre el punto anterior

Excepción o precaución

Procedimientos

Indica que el objeto está visualizado en la presentacióndel instructor.

iv © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 5: TAW12_01

ContenidoResumen del curso ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Metas del curso .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .viiObjetivos del curso... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Capítulo 1: Introducción a la programación orientada aobjetos..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

El modelo de programación orientado a objetos .. . . . . . . . . . . . . . . . . .3Análisis y diseño con UML... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Elementos sintácticos fundamentales orientados a objetos... . . 37

Capítulo 2: Conceptos orientados a objetos y técnicas deprogramación ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Herencia y casting ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105Interfaces y casting .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149Eventos... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192

Capítulo 3: Objetos de Repository orientados a objetos..... . 231Clases e interfases globales... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233Técnicas de programación especiales orientadas a objetos.. .272

Capítulo 4: El concepto de la excepción basada en clase .... 297Excepciones basadas en clases .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298

Capítulo 5: Objetos compartidos ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Objetos compartidos.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334

Capítulo 6: Programación dinámica..... . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Programación dinámica con símbolos de campo y referencias 367Run Time Type Services .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387

Índice..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. v

Page 6: TAW12_01

Contenido TAW12_1

vi © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 7: TAW12_01

Resumen del cursoEste curso ofrece una introducción detallada y amplia de los principios básicos dela programación de objetos ABAP. El curso tiene una duración de dos semanas.También se explica cómo realizar modificaciones de nivel especializado en laversión estándar del sistema SAP. Además, aprenderá a evaluar los distintosmétodos de modificación y a elegir el método correcto para cada caso. WebDynpro es la tecnología de vanguardia de SAP para la creación de interfasesde usuario de aplicaciones (UI). En este curso se explica detalladamente cómodesarrollar aplicaciones ABAP con Web Dynpro.

Grupo destinoEste curso está dirigido a los siguientes grupos destino:

� Los consultores de desarrollo responsables de adaptar y desarrollarprogramas/objetos ABAP

Prerrequisitos para el cursoConocimientos necesarios

� TAW10 (Principios básicos del Workbench ABAP)� Incluido cuando se reserva: TAW11 E-Learning (info detallada de ABAP)

Conocimientos recomendados

� BC410: Programación de diálogos de usuario con dynpro

Detalles de la duración del cursoCapítulo 1: Introducción a la programación orientada a objetosEl modelo de programación orientado a objetos 30 MinutosAnálisis y diseño con UML 30 MinutosEjercicio 1: Diagramas de clases UML 30 MinutosElementos sintácticos fundamentales orientadosa objetos 200 MinutosEjercicio 2: Clases locales 45 MinutosEjercicio 3: Objetos 20 MinutosEjercicio 4: Llamadas de métodos 45 MinutosEjercicio 5: Constructores 45 MinutosEjercicio 6: Métodos privados 45 Minutos

Capítulo 2: Conceptos orientados a objetos y técnicas deprogramaciónHerencia y casting 160 Minutos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. vii

Page 8: TAW12_01

Resumen del curso TAW12_1

Ejercicio 7: Jerarquías de clases 60 MinutosEjercicio 8: Polimorfismo 20 MinutosEjercicio 9: Agregación y llamadas genéricas 45 MinutosInterfaces y casting 120 MinutosEjercicio 10: Definición e implementación deinterfaces 45 Minutos

Ejercicio 11: Uso de interfaces 45 MinutosEventos 75 MinutosEjercicio 12: Eventos en clases superiores 40 MinutosEjercicio 13: Eventos en interfaces (opcional) 30 Minutos

Capítulo 3: Objetos de Repository orientados a objetosClases e interfases globales 180 MinutosEjercicio 14: Clases globales 40 MinutosEjercicio 15: Interfases globales 30 MinutosEjercicio 16: Asistente de refactoring (opcional) 15 MinutosTécnicas de programación especiales orientadasa objetos 60 MinutosEjercicio 17: Clases singleton (opcional) 45 MinutosEjercicio 18: Relaciones de amistad (opcional) 45 Minutos

Capítulo 4: El concepto de la excepción basada en claseExcepciones basadas en clases 90 MinutosEjercicio 19: Gestión de excepciones basadas enclases 20 Minutos

Ejercicio 20: Creación y uso de clases de excepciónglobales 25 Minutos

Capítulo 5: Objetos compartidosObjetos compartidos 60 MinutosEjercicio 21: Objetos compartidos 35 Minutos

Capítulo 6: Programación dinámicaProgramación dinámica con símbolos de campo yreferencias 120 MinutosEjercicio 22: Casting de tipo para estructuras 30 MinutosRun Time Type Services 50 MinutosEjercicio 23: RTTI: consulta de los atributos deun tipo de datos 40 Minutos

viii © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 9: TAW12_01

TAW12_1 Resumen del curso

Metas del cursoEste curso le permitirá:

� Utilizar elementos fundamentales de la modelación orientada a objetos enUML

� Crear programas de objetos ABAP que contengan todas las técnicas deprogramación útiles orientadas a objetos

� Utilizar las herramientas relevantes para crear objetos de Repositoryorientados a objetos

� Describir y usar las áreas de aplicación de los objetos ABAP� Definir, emitir y tratar excepciones basadas en clases� Consultar atributos de tipo y de clase en el tiempo de ejecución� Realizar modificaciones especializadas en la versión estándar del sistema

SAP� Evaluar los distintos métodos de modificación y elegir el método adecuado

en cada caso� Explicar la arquitectura de un componente Web Dynpro� Describir las partes de un controlador Web Dynpro� Crear elementos de contexto en controladores Web Dynpro� Explicar cómo se puede navegar y realizar transferencias de datos en

componentes Web Dynpro y entre ellos� Definir la interfase de usuario de un componente Web Dynpro� Internacionalizar una aplicación Web Dynpro� Definir y enviar mensajes en un componente Web Dynpro� Definir la ayuda para entradas y la ayuda semántica para elementos de UI en

un componente Web Dynpro

Objetivos del cursoAl finalizar este curso podrá:

� Utilizar elementos fundamentales de la modelación orientada a objetos enUML

� Crear programas de objetos ABAP que contengan todas las técnicas deprogramación útiles orientadas a objetos

� Utilizar las herramientas relevantes para crear objetos de Repositoryorientados a objetos

� Describir y aprovechar el rango de aplicaciones de objetos ABAP� Definir, emitir y tratar excepciones basadas en clases� Consultar atributos de tipo y de clase en el tiempo de ejecución

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. ix

Page 10: TAW12_01

Resumen del curso TAW12_1

� Realizar modificaciones especializadas en la versión estándar del sistemaSAP

� Evaluar los distintos métodos de modificación y elegir el adecuado en cadacaso

� Explicar la arquitectura de un componente Web Dynpro� Describir las partes de un controlador Web Dynpro� Crear elementos de contexto en controladores Web Dynpro� Explicar cómo se puede implementar la navegación y las transferencias de

datos en componentes Web Dynpro y entre ellos� Definir la interfase de usuario de un componente Web Dynpro� Internacionalizar una aplicación Web Dynpro� Definir y enviar mensajes en un componente Web Dynpro� Definir la ayuda para entradas y la ayuda semántica para elementos de UI en

un componente Web Dynpro

Información de los componentes de software de SAPLa información de este curso se refiere a los siguientes componentes de softwarede SAP:

� SAP NetWeaver Application Server 7.0� SAP Web Application Server 6.20

It is imperative that you read these notes, even if you have already completed anearlier version of this course. If available, read the list of the known errors for thiscourse as well. If it exists, this list has deliberately been saved separately from thisprinted course on SAP Service Marketplace (http://service.sap.com/curr-abap), tokeep the course as up-to-date as possible and minimize technical inputs.

x © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 11: TAW12_01

TAW12_1 Resumen del curso

Training courses recommended as preparation:

� SAPTEC� BC400� BC401� BC402� BC410� BC425� BC427� BC430� NET310

1. Learn the contents of this course including all items of the Onlinedocumentation for the respective subject areas. Solve all exercises on yourown at least once (without the help of model solutions, including all detailsand optional sections).

2. Obtain answers to any questions you have about the course materials andthe exercises.

3. Develop your own presentation methods and run through each demonstrationat least once yourself.

4. Clear up any questions you have on these methods.5. Attend this course at least once when it is held by an experienced instructor

and possibly supervise participants during an exercise yourself.

Training system:

� SAP NetWeaver 7.0 (Support Package 13 or higher) or higher (ABAP engineis sufficient).

The training administration team should provide you with a system, includinga client. If problems arise with the server assignment, create a messageunder the component SR-KPS-ISM.

� Either a Windows Terminal Server (WTS) or local PCs with SAP GUI 6.40(patch level 21 or later version) or higher installed.

At the time this document was put together, the WTS address washttp://wts:1080/portal/corp/training.html→ Common_Training.

Training courses at a customer site or in a third-party training center

You can only establish a connection using the SAP Citrix Secure Gateway (SAPCSG) for training courses at the customer site. Therefore, you requirea CSG userID. The training department should have created the user ID for the course date.The training department sends you the data (user ID and password). Instructorsand participants use the same CSG user ID for the training course. Use the linkhttp://mywts.sap.com to establish a connection to the training WTS farms. Enter

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. xi

Page 12: TAW12_01

Resumen del curso TAW12_1

the CSG user ID and the password. Choose your region (US, EMEA or APJ).Choose Training - Zone. Connect to Common Training if no other WTS farmoption is executed for the training course.

Make all the preparations with regard to the following two points in accordancewith the �General instructor guide for all BC4XX courses� . It is locatedin the same area of the corporate portal as this handbook. Refer to the generalhandbook first.

The required system preparations are described below.

Data for exercises and demonstrations: As a rule, the necessary data has alreadybeen generated for your training client. If this is not the case, (for example, ifyour training course takes place at a customer site) you will have to run the datageneration program (report SAPBC_DATA_GENERATOR). This will queryyou on the type and quantity of the data. Select the standard setting and set theindicator for Postings also cancelled.

User IDs and initial passwords for participants: Unlike the application data,you must always generate the user IDs. Use the (locked) user ID TAW12_USER asa copy template.

Change requests for participants� exercises: In the program used to generateuser IDs (transaction ZUSR), you also have the option of creating a commonchange request that contains a task for each user generated in this way. Use it.

Presentation: Make sure you can open the offline presentation for this trainingcourse (version 63).

Example objects: All repository objects for this training course belong to thefollowing packages BC401, BC425, DNW7AW and NET310. The followingnaming conventions were used for the course objects:

� ...BC401_CCC D_...: Demonstration and example objects� ...BC401_CCC S_...: Model solutions� ...BC401_CCC T_...: Templates

In each case, CCC is a three-character unit code.

Atención: Never modify these standard objects. Always create copies, ifyou want to change something for demonstration purposes. Otherwise,you may cause errors in other objects, or prevent other courses from beingheld in this system.

The same applies for your course participants. If, however, you use thecorrect copy template for their user IDs, they will probably not have theauthorization to do so.

General notes for the course: The time specifications are recommendationsonly. They contain sufficient time �intervals� for more detailed questions.However, you should bear in mind that the more participants learn, the more

xii © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 13: TAW12_01

TAW12_1 Resumen del curso

questions they tend to ask. The group may not be particularly homogenous. Youmust always guarantee that the entire content can be presented. We recommendkeeping within the time limits from very start.

The course materials should be suitable for participants to work through againafter the course. This is why we provide extensive explanations and additionalinformation. It is your task to pick out the most important statements in thematerial. The decisive factor should be the graphics that appear in the offlinepresentation and the aspects they represent.

Similar principles apply to the objects of all packages. These packages containmore objects than you will need to present the course successfully. Much of thecode is also available as source code extracts in the presentation or in participants�material (or both). It is up to you whether you want to discuss these in detail,use the demonstration objects themselves, or create similar objects during thepresentation and use them. We recommend direct demonstration in the system.

Additional notes for instructors: In addition to these general notes, you will findadditional, more detailed notes in each unit and lesson. You will also find othershort notes in the material wherever we believe they are necessary to ensure thatthe content is explained in sufficient detail.

Introductory phase at the start of the course:

� Introduce yourself as the course instructor� Outline organizational issues� Introduction of participants (optional, depends on time available.)� Provide overview of the course material� Refer to more in-depth information� Provide overview of the course content

Additional Information about Certification

� Open the browser and enter the following link: http://www.sap.com/ser-vices/education/certification/index.epx. Select the following criteria: SAPNetWeaver, Development, Developer/Development Consultant. For moreinformation, select the following option on the next page: SAP CertifiedDevelopment Associate - ABAP - SAP NetWeaver 7.0.

Other Training Courses

� TAW10� TAW11

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. xiii

Page 14: TAW12_01

Resumen del curso TAW12_1

xiv © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 15: TAW12_01

Capítulo 11 Introducción a la programación

orientada a objetos

Surprisingly, we have noticed that many participants are not yet used to theobject-oriented way of thinking. They are still very inclined to follow theprocedural approach. However, the last few years have shown that participantsare increasingly willing to deal with object orientation and need less prompting.Most participants have �accepted� that they must confront the issue. The firstlesson will probably not be enough to convert them completely and they maystill need some motivational help. Ideally, each participant will have learned byexperience by the end of the course and will be fully convinced by the advantagesof object-oriented programming.

The second lesson is only intended as a brief introduction to modeling. We areconvinced that modeling alone � without the background knowledge to determinewhat is or is not possible in a programming context � is not sufficient for effectivelearning. We say: Learn by doing. That way, participants create executableprograms and can see the effects of what they are doing right away.

This course therefore takes a more introductory approach to modeling. After abrief introduction, other aspects of UML notation will be examined in relation tothe different object-oriented concepts. This is the only way for participants tolearn both object-oriented programming with ABAP Objects and basic modelingat the same time.

Resumen del capítuloEsta unidad le ofrece una introducción a los conceptos básicos del desarrollo desoftware orientado a objetos. La primera unidad es una introducción a los nuevosmétodos de planteamiento y a los conceptos relacionados con ellas.

La segunda unidad es una introducción compacta a la modelación, el paso en elproceso de desarrollo de software que se realiza inmediatamente después de laprogramación en sí. Esto se demostrará mediante el estándar de modelación UML.Para empezar, sólo verá los elementos más básicos y relevantes. Las unidades iránampliando la información sucesivamente, introduciendo en paralelo los conceptos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 1

Page 16: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

de la programación orientada a objetos y las notaciones UML correspondientes.Por lo tanto, este curso le aportará simultáneamente información acerca de lamodelación orientada a objetos y sobre programación.

El contenido de las dos primeras unidades es aplicable, en lo esencial, a otroslenguajes modernos orientados a objetos. A partir de la tercera unidad seintroducen los elementos sintácticos específicos de objetos ABAP. Deberáaprender muchos de estos elementos sintácticos de forma bastante seguida.

La mayor parte del contenido de las demás unidades está relacionada conconceptos completamente nuevos. La sintaxis tendrá un papel mucho másreducido en estas unidades.

Objetivos del capítuloAl finalizar este capítulo podrá:

� Explicar las diferencias entre modelos de programación procedimental yorientados a objetos

� Enumerar las ventajas del modelo de programación orientado a objetos� Nombrar los tipos de diagrama más importantes en UML� Crear diagramas de clases simples� Crear diagramas de objetos simples� Describir diagramas de secuencias� Definir clases� Generar y borrar objetos� Tener acceso a atributos� Llamar métodos

Contenido del capítuloLección: El modelo de programación orientado a objetos ... . . . . . . . . . . . . . . . .3Lección: Análisis y diseño con UML... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Ejercicio 1: Diagramas de clases UML ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Lección: Elementos sintácticos fundamentales orientados a objetos .. . . 37

Ejercicio 2: Clases locales ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Ejercicio 3: Objetos .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Ejercicio 4: Llamadas de métodos .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Ejercicio 5: Constructores .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Ejercicio 6: Métodos privados .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

2 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 17: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

Lección:3

El modelo de programación orientado a objetosDuración de la lección: 30 Minutos

Resumen de la lecciónBasándonos en sus conocimientos de programación procedimental con ABAP,le explicaremos el enfoque orientado a objetos y le animaremos a utilizarlo.El énfasis principal recaerá en la explicación. En esta etapa, es importanteintroducirle en el tema y en sus conceptos, de manera que podamos basarnosen estos conocimientos más adelante.

Por ahora, no tendría sentido intentar encontrar un caso conclusivo a favor oen contra del enfoque orientado a objetos. Antes de poder tomar una decisióncualificada, debe conocer todos los conceptos orientados a objetos, así comosus ventajas e inconvenientes.

Aunque este tipo de decisión sea tomada por su equipo o por su jefe de desarrollo,debería ser capaz de contribuir en la discusión.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Explicar las diferencias entre modelos de programación procedimental yorientados a objetos

� Enumerar las ventajas del modelo de programación orientado a objetos

Finding the best way to handle this lesson depends on the individual groupof participants. Experience shows that participants often have some previousknowledge of procedural programming, particularly the contents of the previouscourse BC400. Sometimes, for no apparent reason, these participants hesitate touse object-orientation. Try to overcome this hesitation.

It would therefore be counterproductive to put too much emphasis on the lastsection. The attributes that are described there need to be dealt with graduallyin the specific lessons. The final section is more suitable for participants withobject-oriented programming experience in other languages. You can assure theseparticipants that they will soon be re-introduced to some familiar concepts.

It is important to clarify that the object-oriented programming model does notextend the range of problems that can be solved algorithmically. Object orientationis just another programming approach. It can solve exactly the same number ofproblems as other approaches.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 3

Page 18: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Ejemplo empresarialDebe explicar los puntos fundamentales del modelo de programación orientado aobjetos y sus ventajas a su jefe de proyectos de desarrollo.

Transición desde el modelo de programaciónprocedimental al modelo de programación orientadoa objetosTal como podemos ver en el lenguaje de programación Simula 67, la programaciónorientada a objetos se desarrolló aproximadamente al mismo tiempo que losmodelos de programación lógicos y procedimentales. En el pasado, COBOL y,por encima de todo, el modelo de programación procedimental en su expresión enlenguajes como C o Pascal, fueron dominantes en el desarrollo de aplicaciones parala empresa. Antes de ABAP, SAP utilizaba originalmente un assembler de macros.

Incluso hoy, muchos programadores aún tienen más experiencia con laprogramación procedimental que con la programación orientada a objetos. Porlo tanto, esta introducción a la programación orientada a objetos también utilizareferencias al modelo de proceso para sus explicaciones.

Gráfico 1: Historial de lenguajes de programación seleccionados

ABAP fue creado con la intención de mejorar el reporting. Fue desarrollado deforma relativamente independiente como un lenguaje de programación interno,aunque tuvo influencias de otros lenguajes de programación como COBOL yPASCAL. ABAP/4 fue ampliado entonces para formar objetos ABAP. Por ello,los objetos ABAP comprenden elementos orientados a objetos y de proceso enun lenguaje de programación.

4 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 19: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

Para la parte orientada a objetos, sólo los conceptos orientados a objetos quedemostraron sus cualidades para el desarrollo de aplicaciones para la empresa enotros lenguajes, como Java, C++ y Smalltalk, fueron integrados. Los objetosABAP, como los ABAP/4 antes de ellos, también contienen algunos conceptosúnicos y muy útiles.

You should repeat these points whenever they are relevant throughout the entirecourse and illustrate them with specific syntax examples to ensure that they arenot merely seen as empty phrases.

Gráfico 2: Características del modelo de programación procedimental

Los datos y las funciones acostumbran a mantenerse separados en el modelo deprogramación procedimental. Las variables globales de un programa contienennormalmente los datos, mientras que las subrutinas contienen las funciones.

Básicamente, cada subprograma puede tener acceso a todas las variables. Estosignifica que el modelo de programación en sí no soporta el acceso consistente aalgunas partes relacionadas de los datos.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 5

Page 20: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 3: Programa ABAP de proceso típico

Un programa ABAP procedimental típico consiste en definiciones de tipo ydeclaraciones de datos, que describen la estructura de los datos que utiliza elprograma al ejecutarse. Las unidades de modularización (por ejemplo subrutinas omódulos de funciones) pueden encapsularse. Sin embargo, en el nivel de programaprincipal no hay ninguna protección especial para los objetos de datos globales.Se puede acceder a todas las variables en cualquier caso.

Gráfico 4: Encapsulación de grupos de funciones que utilizan datos

6 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 21: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

Cada vez que se solicita un módulo de funciones en un programa principal, sugrupo de funciones se carga en la sesión interna. El grupo de funciones sigueactivo hasta que el programa principal ha terminado. El programa principal y losgrupos de funciones que fueron solicitados en él están almacenados en áreas dememoria separadas. Incluso si sus objetos de datos tienen los mismos nombres,no están compartidos.

Sólo puede solicitar los módulos de funciones de los grupos de funciones desdeel programa principal. A su vez, los módulos de funciones pueden acceder aotros componentes, especialmente los datos globales, de los grupos de funciones.En otras palabras, no es posible tener acceso a los datos globales del grupo defunciones directamente desde el programa principal.

La encapsulación también incorpora la idea de que la implementación de unservicio puede ocultarse desde los otros componentes del sistema, de maneraque éstos no pueden ni deben hacer presuposiciones acerca del status internode la unidad de modularización. De esta manera, el diseño de estos otroscomponentes no depende de una implementación específica de las otras unidadesde modularización.

Por ello, un grupo de funciones es una unidad de datos y funciones que gestionaestos datos. El acceso encapsulado a datos y servicios, uno de los muchosconceptos del modelo de programación orientado a objetos, puede ser soportadopor lo tanto en la parte de procedimental de objetos ABAP. Esto significabaque las BAPI podían implementarse como módulos de funciones y los objetosempresariales podían implementarse como grupos de funciones.

It may be helpful to mention some other characteristics of function modules here,such as remote capability or optional parallelization. In doing so, you risk beingdrawn away from the core subject matter, but you will be able to emphasize thepower and versatility of even the procedural part of ABAP Objects.

It can also help participants to understand that object-orientation is just anotherprogramming method and does not necessarily lead to more technical possibilities.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 7

Page 22: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 5: Ejemplo de un grupo de funciones

El grupo de funciones ficticio S_VEHICLE ofrece los servicios INC_SPEED,DEC_SPEED y GET_SPEED a un usuario o cliente. Estos servicios representanel interface de grupo de funciones y tienen acceso al objeto de datos globalesSPEED, que pertenece al grupo de funciones completo.

Gráfico 6: Ejemplo de uso del grupo de funciones

El programa principal no puede tener acceso directamente al objeto de datos delgrupo de funciones SPEED.

8 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 23: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

We feel that the best way to learn about the new aspects is to highlight thedifferences between these and the old characteristics. Multiple instantiationis a new characteristic that could be suitable for this purpose. Some otherobject-oriented concepts also exist in procedural languages or they are easy toimagine.

However, this is not the case for inheritance. It is more difficult, and therefore lesssuitable for defining the limits of the object-oriented approach.

Gráfico 7: ¿Distintas instancias de un grupo de funciones?

Si el programa principal debe trabajar con varios vehículos, son necesariasacciones adicionales de programación y de administración. Y lo que es másimportante, un vehículo específico ya no podría ser representado por un grupo defunciones entero.

Gráfico 8: Instanciación múltiple en la programación orientada a objetos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 9

Page 24: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

La posibilidad de crear diversas instancias en tiempo de ejecución en unespacio para cada contexto de programa es una de las características clave dela programación orientada a objetos.

En este ejemplo se crearon cuatro vehículos, los cuales tienen distintas instanciasde característica. Sin embargo, todos ellos comparten la misma estructura dedatos, el mismo rango de funciones y la capacidad de proteger sus datos ante elacceso desde el exterior.

Gráfico 9: Memoria principal ABAP y encapsulación

Al igual que los grupos de funciones, los objetos también están almacenados en lamisma sesión interna que el programa que se está utilizando. Además, todas lasáreas de datos están separadas las unas de las otras, y por lo tanto están protegidas.

10 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 25: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

Gráfico 10: Gestión de datos en modelos de proceso y orientados a objetos� Resumen

A diferencia de lo habitual en la programación procedimental, el uso de lainstanciación múltiple en la programación orientada a objetos le permite crear unaabstracción directa de un objeto real. El concepto de encapsulación establecidofue extendido sistemáticamente en el proceso.

El modelo de programación orientado a objetos deobjetos ABAPLos conceptos orientados a objetos de objetos ABAP son básicamente los mismosque los de otros lenguajes modernos orientados a objetos como C++ o Java. Unpequeño número de conceptos que no demostraron ser eficaces en estos otroslenguajes no se incluyeron en objetos ABAP. Por el otro lado, los objetos ABAPtambién tienen elementos lingüísticos útiles que no ofrecen C++ ni Java.

Algunas funciones específicas de objetos ABAP sólo existen gracias a lacompatibilidad superior garantida de elementos lingüísticos ABAP anteriores.

Las mayores diferencias en comparación con otros lenguajes orientados a objetosse encuentran en el entorno de desarrollo. Puede utilizar el rango completo defunciones del Workbench ABAP con objetos ABAP.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 11

Page 26: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 11: Los objetos ABAP como una extensión compatible de ABAP

Los objetos ABAP no son un nuevo lenguaje, sino que han sido diseñados comouna extensión sistemática de ABAP. Todas las extensiones, incluyendo las partesde proceso antiguas, son compatibles hacia arriba.

Los controles de tipos de los contextos orientados a objetos de objetos ABAP sonmás estrictos que los realizados en los contextos de proceso.

Al desarrollar los objetos ABAP, el lenguaje ABAP fue depurado, especialmenteen los contextos orientados a objetos. Esto significa que las referencias obsoletasconducen a errores sintácticos.

Sin embargo, también es aconsejable evitar las referencias obsoletas en el entornopuramente de proceso, ya que así se crean textos fuente más seguros y másflexibles. De todas maneras, dado que el lenguaje es compatible hacia arriba, noes posible prevenir el uso de estas referencias por completo.

Para ver una lista de elementos de lenguaje obsoletos, consulte la documentaciónde palabras clave ABAP. Cada una de las referencias obsoletas también estáanotada específicamente como prohibida en el contexto orientado a objetos.

It may be useful to mention the great advantages of SAP�s approach: The upwardcompatibility saves developers from having to carry out a migration when a newrelease is implemented. With a small number of exceptions, the Repository objectsfrom the first SAP R/3 Basis release can still be used without restrictions in SAPWeb AS 6.20. No competitor can match this.

12 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 27: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

Gráfico 12: Relaciones de cliente/servidor entre objetos

Los objetos se comportan como sistemas de cliente/servidor: Cuando un objetomanda un mensaje a otro objeto diciéndole que se comporte de una maneradeterminada, el primer objeto puede verse como un cliente y el otro como unservidor.

Para poder separar solicitudes y entregas de servicios, debe cumplirse lo siguiente:

� El objeto de cliente debe adherirse al protocolo de objeto del servidor.� El protocolo debe estar descrito claramente, de manera que un cliente

potencial pueda seguirlo sin problemas.

En principio, los objetos pueden realizar ambos roles simultáneamente: Puedenofrecer servicios a otros objetos mientras solicitan servicios al mismo tiempo.

En la programación orientada a objetos, los servicios se distribuyen entre losobjetos de manera que se eviten redundancias, y de manera que cada objetoofrezca exactamente los servicios que están en su área de responsabilidad. Si unobjeto necesita otros servicios, los solicita a otros objetos. Esto se conoce comoel principio de delegación de tareas.

Ejemplo:

La tarea común �obtención y salida de datos� debería distribuirse entre almenos dos objetos. Uno es responsable de la obtención de datos y el otro dela salida. Mientras el objeto de obtención de datos no cambie su protocolo, suimplementación interna puede ser alterada, sin que sea necesario realizar ningúncambio en el objeto de salida. De manera alternativa, el objeto de obtención dedatos podría incluso sustituirse por un objeto diferente, siempre que el objetonuevo utilice el mismo protocolo. Estos cambios también pueden realizarse entiempo de ejecución.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 13

Page 28: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 13: Conceptos adicionales del modelo de programación orientado aobjetos

herenciaLa herencia define las relaciones de implementación entre clases, de maneraque una clase (la subclase) adopta la estructura y el comportamiento de otraclase (clase superior), posiblemente también adaptándolos o extendiéndolos.

polimorfismoEn la orientación a objetos, el polimorfismo es cuando instancias dediferentes clases responden de manera distinta a los mismos mensajes.

control de eventosEn lugar de mandar mensajes directamente a objetos específicos, los objetostambién pueden desencadenar eventos. Los eventos pueden desencadenarsesi aún no se conoce en el momento del desarrollo si los objetos reaccionarán,y si lo hacen, cómo será esta reacción.

En resumen, el modelo de programación orientado a objetos de objetos ABAPtiene las siguientes características clave:

Características del modelo de programación orientado a objetos

� Los objetos son una abstracción directa del mundo real� Los objetos son unidades hechas de datos y de funciones que pertenecen a

estos datos� Los procesos pueden implementarse de manera realista

El modelo tiene las ventajas siguientes:

14 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 29: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

Ventajas del modelo de programación orientado a objetos respecto al modelode programación procedimental

� Estructura y consistencia de software mejoradas en el proceso de desarrollo� Trabajo de mantenimiento reducido y menor susceptibilidad a errores� Mejor integración del cliente/usuario en el proceso de análisis, diseño y

mantenimiento� Las opciones para extender el software son más simples y más seguras

Se utiliza un lenguaje estándar en las distintas fases de desarrollo del software(análisis, especificación, diseño e implementación). La comunicación es muchomás sencilla al cambiar entre fases.

The features will only become apparent to the participants after they havecompleted the relevant lessons. Make sure they understand that the claims madein this course will be verified by their own experience.

En la programación orientada a objetos, las decisiones de análisis y diseño tienenun efecto aún mayor en la implementación que el que tienen en la programaciónprocedimental.

Gráfico 14: El proceso de desarrollo del software

Por lo tanto, ya debería estructurar y estandarizar formalmente la fase de análisis ydiseño. Puede utilizar lenguajes de modelado a tal efecto.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 15

Page 30: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Discusión con moderadorHere you have an opportunity to discuss any open issues that may have arisen.In most cases, however, we suggest moving swiftly forwards to the morepractice-based lessons.

Preguntas para la discusiónUtilice las siguientes preguntas para que los participantes del curso tomen parte enla discusión. También puede utilizar sus propias preguntas.

Use the questions as appropriate to find out what participants know.

16 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 31: TAW12_01

TAW12_1 Lección: El modelo de programación orientado a objetos

Resumen de la lección

Ahora podrá:� Explicar las diferencias entre modelos de programación procedimental y

orientados a objetos� Enumerar las ventajas del modelo de programación orientado a objetos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 17

Page 32: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Lección:15

Análisis y diseño con UMLDuración de la lección: 30 Minutos

Resumen de la lecciónEsta unidad le ayudará a descubrir cómo desarrollar una solución orientada aobjetos para un problema de aplicación empresarial, desde la clasificación deobjetos hasta la definición de las relaciones entre ellos.

Utilizaremos partes del estándar de modelación UML como ayuda visual.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Nombrar los tipos de diagrama más importantes en UML� Crear diagramas de clases simples� Crear diagramas de objetos simples� Describir diagramas de secuencias

In this lesson, it is important to make clear distinctions between modelingconcepts and the related programming concepts. Example: When looking ata class diagram, we often speak of �inheritance�, although we actually meana �generalization/specialization relationship�. This requires strict discipline,especially from people who are new to the subject matter and may still besomewhat unsure. For the moment, we are only dealing with modeling.

Ejemplo empresarialUn requisito de aplicación empresarial debe ser modelado antes de serimplementado.

ClasificaciónCon la programación orientada a objetos, el mundo real se muestra como unacolección de objetos; por ejemplo, diferentes aviones, coches y gente. Algunos deestos objetos son muy similares. En otras palabras, pueden describirse utilizandolas mismas características y muestran el mismo comportamiento.

Todas las características y el comportamiento de estos objetos similares se agrupanahora en una clase central. Esta clase se utiliza para describir todos los objetosque derivan de ella. Una clase es, por lo tanto, una descripción de una cantidadde objetos que están tipificados mediante las mismas características y el mismocomportamiento.

18 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 33: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

Gráfico 15: Clasificación de objetos

Por ejemplo, el vehículo �marca x, ... serie n�, es un objeto de clase �coche�. Esteobjeto es, por lo tanto, una instancia concreta de su clase.

Como consecuencia, un objeto tiene una identidad, un status (número de instanciascaracterísticas) y un comportamiento. No confunda los conceptos de identidady status. La identidad es un atributo que distingue cada objeto de entre el restode objetos de su clase. Dos objetos diferentes pueden tener valores de atributoidénticos pero no ser idénticos.

Ejemplo:Dos tazas de café tienen la misma altura y el mismo diámetro, tienen lamisma asa y ambas son blancas. Aunque sus status son completamente idénticos,se trata claramente de dos tazas de café diferentes.

La bibliografía acerca del tema del enfoque de objetos habla a menudo deinstancias. Esto significa únicamente un objeto.

Nota: En el sentido literal de la palabra instancia, el significado esligeramente más específico. Significa una instancia concreta (es decir,identificable de forma única) de una clase.

En las páginas siguientes distinguiremos entre instancia y objeto.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 19

Page 34: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 16: Clases como formas de abstracción

En un contexto de software, las abstracciones son representaciones simplificadasde relaciones complejas en el mundo real. Un objeto real y existente es abstraído alas dimensiones que son relevantes para simular la sección requerida del mundoreal.

Este ejemplo trata de vehículos. El software para un entusiasta del motor y elsoftware para un chatarrero contienen diferentes abstracciones (clases) para estosobjetos. Así, en función del tipo de abstracción, una clase puede contener aspectosmuy distintos de los objetos.

In reality, classification is the decisive step. Therefore, it requires extensiveconsiderations that would go far beyond the framework of this course. This mustbe emphasized to the participants. At this point, you will need to keep questions toa minimum and ask participants to be patient to keep up the necessary pace. Asthis is a training situation, a certain starting situation has to be accepted as given.

Explain the different symbols used in this course.

Many of the following slides will show not only the official UML symbols forclasses and objects, but also symbols from recognized ABAP books. A (5) appearsin the graphic against your own object symbols. Point out to the participants herethat this is to symbolize an object. An object �lives� and takes up space in themain memory. (Of course, you cannot find the object at the main memory address5!) This display format comes from the debugger and is only intended to representa general address! The participants are guaranteed to ask you about this later!

20 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 35: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

Gráfico 17: Comparación de clases y objetos

Una comprensión completa de la relación entre clases y objetos, tal como seresume aquí de nuevo, es un requisito indispensable para seguir con las siguientesunidades.

Modelación en UMLUnified Modeling Language (UML) es un lenguaje de modelación estandarizadoa nivel global. Se utiliza para especificar, construir, visualizar y documentarmodelos de sistemas de software, y permite una comunicación uniforme entreusuarios.

El UML es un estándar y el Object Management Group (OMG) lo ha estandodesarrollando desde septiembre de 1997. SAP utiliza UML como el estándar dela empresa para la modelación orientada a objetos.

Puede encontrar las epecificaciones de UML en la página inicial de OMG, en:http://www.omg.org

UML describe varios tipos de diagrama diferentes para representar distintasvistas de un sistema. Los tres siguientes tipos de diagrama son especialmentesignificativos en este contexto:

Diagramas de clasesMuestran las clases y las relaciones entre ellas, es decir, una vista estática deun modelo.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 21

Page 36: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Diagramas de comportamientoPrestan una atención especial a la secuencia en la que los objetos serelacionan entre ellos.

Diagramas de componentesMuestran la organización y las dependencias entre componentes.

Más adelante, deberemos encontrar métodos concretos para realizar los dosprimeros aspectos de la lista en el lenguaje de programación.

El tercer aspecto se realiza en el paquete de objetos de Repository. En otraspalabras: Los paquetes pueden utilizarse para realizar la estructura de componentesde software dentro de SAP Web AS, según la especificación de la estructura enun diagrama de componentes.

Gráfico 18: Representación de una clase

Una clase se representa con un rectángulo en notación UML. En primer lugar seadjudica el nombre de la clase, después sus atributos y, finalmente, sus métodos.Sin embargo, también se tiene la opción de omitir la parte del atributo y/o la partedel método.

Los atributos describen los datos que pueden almacenarse en los objetos de unaclase. También determinan el status de un objeto.

Los métodos describen las funciones que puede realizar un objeto. Determinan,por lo tanto, el comportamiento de un objeto.

22 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 37: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

Gráfico 19: Ejemplo de un diagrama de clases

For the modeler of this example, a vehicle is a car with 4 wheels. Of course, theexample with car rental companies and cars could also have been described andmodeled differently. Don�t forget to point this out to the participants!

Explain to the participants that modeling in OO is only dealt with in a very basicway, and that it is advisable after the course to go into this in greater depth andacquire more literature on the subject. The topic of modeling is dealt with in thiscourse on a �learning by doing� basis!

Un diagrama de clases describe todas las relaciones estáticas entre las clases. Haydos formas básicas de relaciones estáticas:

AsociaciónEn este ejemplo: Un cliente encarga un coche en una compañía de vehículosde alquiler.

Generalización/EspecializaciónEn este ejemplo: un coche, un autobús y un camión son todos vehículos.

Nota: Tal como se ha mencionado anteriormente, las clases tambiénpueden mostrarse en diagramas de clases con sus atributos y métodos.Aquí, éstos se han omitido para mejorar la claridad.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 23

Page 38: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 20: asociación

Una asociación describe una relación semántica entre clases. La relaciónespecífica entre objetos en estas clases se conoce como un enlace de objetos. Losenlaces de objetos son, por lo tanto, instancias de asociaciones.

Una asociación suele ser una relación entre diferentes clases (asociación binaria).Sin embargo, una asociación también puede ser recursiva; en este caso, la clasetiene una relación con ella misma. En la mayoría de los casos, las asociacionesrecursivas se utilizan para enlazar dos objetos diferentes en una clase. Los puntosque siguen presuponen que las asociaciones son binarias.

Cada asociación tiene dos roles, uno para cada dirección de la asociación. Cada rolpuede describirse con un nombre de asociación. Cada rol tiene una cardinalidadque muestra cuántas instancias pueden participar en esta relación. La multiplicidades el número de objetos participantes en una clase que tienen una relación con unobjeto de la otra clase. Como el resto de elementos del modelo, las cardinalidadesdependen de la situación concreta que se está modelando.

24 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 39: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

En este ejemplo, también podría necesitar una cardinalidad de �al menos una�,para indicar que sólo una persona que realmente realiza una reserva se convierteen cliente de la compañía de vehículos de alquiler. Por otro lado, la cardinalidad�cualquier número� permitiría una definición más general de un cliente.

� Una asociación se representa con una línea entre los símbolos de clase.� La cardinalidad (también llamada multiplicidad) de la relación puede

especificarse en ambos extremos de la línea.� Pueden utilizarse flechas para indicar las opciones de navegación, es decir, la

accesiblidad del interlocutor de asociación.� Este nombre de asociación se escribe en cursiva por encima de la línea, y

puede contener una flecha que muestre la dirección de lectura.� Si se han definido roles para ambos interlocutores, los nombres de rol pueden

introducirse a ambos extremos de las líneas.

Inform the participants that you will now be providing some additional detailedexamples of associations to demonstrate the options for modeling with classdiagrams. However, recursive and multiple associations and association classeswill not be mentioned again for the rest of the course and are not used in theexercises. Nevertheless, one objective of this course is to learn how to distinguishbetween association, aggregation/composition and generalization/specialization.It is important that the participants have understood this!

Gráfico 21: Asociación con roles - Ejemplos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 25

Page 40: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

En el ejemplo de asociación múltiple que se muestra aquí, los nombres de rol seutilizan al final de las líneas de asociación para describir con mayor detalle lasrelaciones entre las clases involucradas. Una persona podría aparecer en el rol deempleado o de director de la empresa.

En la asociación recursiva que se muestra aquí, los dos roles de �niño� y �padre�se definen de manera parecida utilizando nombres de rol. Por tanto, las dosinstancias de la clase LCL_PERSON tienen una relación entre ellas y representandos roles.

Gráfico 22: Clases de asociación

Si se utiliza una asociación para enlazar dos clases, esta relación puederepresentarse mejor con una clase especial. Las distintas características de larelación se describen utilizando los atributos de la clase de asociación. Una líneapunteada conecta esta clase adicional con la línea de asociación.

26 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 41: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

Gráfico 23: Agregación y composición

La agregación y la composición son especializaciones de asociación. Indicanque un objeto está formado por otros objetos o contiene otros objetos (parte decomposición). La relación puede describirse con las palabras �está formado por�o �es una parte de�. Por ejemplo, un coche está formado por ruedas, entre otrascosas.

La agregación y la composición se muestran en forma de línea entre dos clases,marcada con un pequeño rombo. El rombo indica el agregado, es decir, lacomposición. Por lo demás, las convenciones de notación son las mismas quepara las de las asociaciones.

La composición es una especialización de agregación. Composición significaque el objeto contenido no puede existir sin el agregado (por ejemplo, unareserva de un coche no puede existir sin la compañía de vehículos de alquiler). Portanto, la cardinalidad del agregado sólo puede ser exactamente una. La vida útilde las partes individuales está vinculada a la vida útil del agregado: Las partesse crean con o después del agregado, y se destruyen con el agregado o antes queel agregado.

En la notación UML, la composición se indica con un rombo relleno.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 27

Page 42: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 24: Generalización y especialización

Las relaciones de generalización y especialización son siempre bidireccionales.La generalización puede describirse con las palabras �es un especial.�

Las relaciones de generalización y especialización se indican con una flechatriangular. Esta flecha siempre apunta a la clase más general. El nivel degeneralización aumenta en la dirección de la flecha. Pueden construirse árbolesmediante varias de estas relaciones.

Gráfico 25: diagrama de objetos

28 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 43: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

Un diagrama de objetos es una �instantánea� hecha durante la ejecución delprograma que describe las instancias de las clases y las relaciones entre ellas.

No es un nuevo tipo de diagrama. Más bien es una variante del diagrama de clasesy sólo es útil para representar un diagrama de clases complejo.

Here you can use the optional exercise relating to object diagrams to underline thedifference between classes and objects.

Explain the structure of the exercise on object diagrams. There are 8 possibleobject diagrams for a class diagram, although some of these are incorrect. Theparticipants should determine the right and the wrong ones in a form of �multiplechoice�.

The following sequence diagrams complete the unit on modeling. They will notbe mentioned again for the rest of the course!

There is no exercise for this.

Gráfico 26: diagrama de secuencias

Los diagramas de secuencias se utilizan para visualizar ciertos procesos osituaciones. Los diagramas de secuencias se centran en la secuencia de tiempo delcomportamiento:

� Crear y eliminar objetos� Intercambiar mensajes entre objetos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 29

Page 44: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

En notación UML, la línea vital del objeto se representa con líneas verticalespunteadas con un cuadro que contiene el nombre del objeto en la parte superior.Una "X" marca el final de la línea vital.

El foco de control se muestra como un rectángulo vertical en la línea vital delobjeto. El foco de control muestra el período �activo� del objeto:

� Un objeto está activo cuando se ejecutan acciones� Un objeto está activo indirectamente si está esperando que termine un

procedimiento subordinado

Los mensajes se visualizan como flechas horizontales entre las líneas de objeto.El mensaje se escribe encima de la flecha de la siguiente manera nachricht(parameter)

. Existen varias maneras de representar la respuesta; en esteejemplo, se muestra como una flecha punteada de retorno.

También es posible incluir una descripción del proceso y añadir comentarios a lalínea vital del objeto según sea necesario.

Gráfico 27: Principio de delegación en un diagrama de secuencias

En la delegación, dos objetos participan en el tratamiento de una solicitud: Eldestinatario de la solicitud delega la ejecución de la solicitud a un representante.

En este ejemplo, el conductor (objeto DRIVER) envía el mensajeGET_FUEL_LEVEL al vehículo (objeto CAR). La recepción de este mensajehace que el coche envíe un mensaje al depósito (objeto TANK) para averiguar loque contiene el depósito. En otras palabras, el coche delega esta tarea al depósito.Si es necesario, el coche formatea la información que contiene el valor actual delcontenido del depósito antes de enviarlo de vuelta al conductor.

30 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 45: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

27 Ejercicio 1: Diagramas de clases UMLDuración del ejercicio: 30 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Diseñar diagramas de clases UML simples� Modelar clasificaciones de objetos básicas

Ejemplo empresarialModelación de la gestión simple de aviones.

Tarea 1: Modelar un diagrama de clases UMLDesea modelar algunas clases clave para la gestión simple de aviones.

1. Su diagrama de clases UML debería contener las siguientes clases:

LCL_CARRIER para las compañías aéreasLCL_AIRPLANE para los aviones (en general)LCL_PASSENGER_PLANE para los aviones de pasajerosLCL_CARGO_PLANE para los aviones de carga

2. Incluya algunos atributos y métodos apropiados para cada clase.

3. Defina las relaciones entre las clases.

Seleccione tipos de asociación adecuados.

4. Seleccione cardinalidades adecuadas.

Tarea 2: Opcional: Diagramas de objetos

The advantage of this exercise is that it gives the participants another opportunityto practice (with your help) distinguishing between classes and objects. Youshould therefore include this exercise if you have enough time.

Decida si los siguientes diagramas de objetos son correctos o no.

1. Se muestra un diagrama de clases (véanse los gráficos siguientes).

Se dibujan ocho diagramas de objetos para este diagrama de clases.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 31

Page 46: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Decida si cada diagrama de objetos es correcto y en caso positivo, márqueloen el cuadro existente.

Gráfico 28: ¿Diagramas de objetos posibles? (1)

Gráfico 29: ¿Diagramas de objetos posibles? (2)

32 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 47: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

Solución 1: Diagramas de clases UMLTarea 1: Modelar un diagrama de clases UMLDesea modelar algunas clases clave para la gestión simple de aviones.

1. Su diagrama de clases UML debería contener las siguientes clases:

LCL_CARRIER para las compañías aéreasLCL_AIRPLANE para los aviones (en general)LCL_PASSENGER_PLANE para los aviones de pasajerosLCL_CARGO_PLANE para los aviones de carga

a) Utilice la solución modelo como guía.

2. Incluya algunos atributos y métodos apropiados para cada clase.

a) Los atributos y métodos generales para los aviones deberían encontrarseen LCL_AIRPLANE. Siga utilizando la solución modelo como guía.

3. Defina las relaciones entre las clases.

Seleccione tipos de asociación adecuados.

a) Una relación de generalización/especialización entre LCL_AIRPLANEy LCL_PASSENGER_PLANE o LCL_CARGO_PLANE pareceapropiada. Debería existir una agregación entre LCL_AIRPLANEy LCL_CARRIER.

Utilice la solución modelo como guía.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 33

Page 48: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

4. Seleccione cardinalidades adecuadas.

a) Pueden utilizarse varias cardinalidades en este caso. Utilice lassecciones relevantes de la unidad y la solución modelo como guía.

Gráfico 30: Diagrama de clases para ejercicio:CARRIER/AIRPLANE

Tarea 2: Opcional: Diagramas de objetos

The advantage of this exercise is that it gives the participants another opportunityto practice (with your help) distinguishing between classes and objects. Youshould therefore include this exercise if you have enough time.

Decida si los siguientes diagramas de objetos son correctos o no.

1. Se muestra un diagrama de clases (véanse los gráficos siguientes).

Se dibujan ocho diagramas de objetos para este diagrama de clases.

Decida si cada diagrama de objetos es correcto y en caso positivo, márqueloen el cuadro existente.

Continúa en la página siguiente

34 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 49: TAW12_01

TAW12_1 Lección: Análisis y diseño con UML

Gráfico 31: ¿Diagramas de objetos posibles? (1)

Gráfico 32: ¿Diagramas de objetos posibles? (2)

a) Los diagramas de objetos número 2, 4, 5, 6 y 8 son correctos.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 35

Page 50: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Resumen de la lección

Ahora podrá:� Nombrar los tipos de diagrama más importantes en UML� Crear diagramas de clases simples� Crear diagramas de objetos simples� Describir diagramas de secuencias

36 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 51: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Lección:33

Elementos sintácticos fundamentales orientados aobjetosDuración de la lección: 200 Minutos

Resumen de la lecciónA lo largo de esta unidad, pondrá sus modelos en práctica. En primer lugar, debeconocer los elementos sintácticos fundamentales orientados a objetos.

Recibirá una introducción paso a paso acerca de la definición de clases locales yde sus usos básicos, acompañada de varios ejercicios.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Definir clases� Generar y borrar objetos� Tener acceso a atributos� Llamar métodos

This is one of the most comprehensive lessons. It introduces many new conceptsand syntax elements in quick succession. It is very important that you proceedone small step at a time.

We highly recommend running all demonstrations in the system. Otherwise, theparticipants will not be able to complete the exercises.

The best approach is for you to create an empty program. First, define an emptylocal class in the program and then build on it with each step.

However, remember to emphasize that the example you are implementing relatesto the graphics and the presentation in the lesson and that it differs from theprogram the participants will use in the accompanying exercises.

This lesson is the key to understanding all further lessons about object-orientedprogramming in ABAP Objects. Make sure there are no unanswered questions.

Ejemplo empresarialDesea implementar clases, objetos y asociaciones de su modelo en objetos ABAP.

Clases, atributos y métodosEl concepto de clases es la base de todo el pensamiento orientado a objetos. Estasección explica y define los componentes principales de una clase.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 37

Page 52: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 33: Ejemplo de una clase

Esta imagen muestra un vehículo como ejemplo de una clase. Mediante esteejemplo, examinaremos los conceptos individuales. El nodo de la izquierda indicaque puede accederse a los componentes públicos de la clase �desde fuera�. Porotro lado, los atributos privados de la clase no deberían ser accesibles �desdeel exterior�.

Gráfico 34: Definición de clases

Una clase es un conjunto de objetos que tienen la misma estructura y el mismocomportamiento. Una clase, por lo tanto, es como un anteproyecto a partir del cualse crean todos los objetos de esta clase.

Todos los componentes de la clase se definen en la parte de definición. Loscomponentes son atributos, métodos, eventos, constantes, tipos e interfacesimplementados. Sólo los métodos se implementan en la parte de implementación.

38 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 53: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

La sentencia CLASS no puede anidarse, es decir, no puede definirse una clasedentro de una clase.

Nota: Sin embargo, se pueden definir clases auxiliares locales paraclases globales.

Gráfico 35: Ejemplo de atributos

Los atributos contienen los datos que pueden almacenarse en los objetos deuna clase. Los atributos de clase pueden pertenecer a uno de estos tres tipos:elemental, estructurado o de tipo tabla. Pueden consistir en tipos de datos localeso globales o tipos de referencia.

A continuación, algunos ejemplos de atributos para la clase LCL_VEHICLE:

MAKE Marca del vehículoMODEL Tipo o modeloSER_NO Número de serieCOLOR ColorMAX_SEATS Número de asientosR_MOTOR Referencia a la clase LCL_MOTOR

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 39

Page 54: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 36: Definición de atributos, tipos y constantes

En las clases, sólo se puede utilizar el suplemento TYPE para hacer referencia atipos de datos. La referencia LIKE está permitida para objetos de datos locales ocampos SY (por ejemplo SY-DATE, SY-UNAME, etc).

El suplemento READ-ONLY significa que un atributo público que fue declaradocon DATA puede ser leído desde el exterior, pero sólo puede modificarse pormétodos en la misma clase. Actualmente sólo se puede utilizar el suplementoREAD-ONLY en la sección de visibilidad pública (PUBLIC SECTION) de unadeclaración de clase o en una definición de interface.

Con TYPE REF TO, un atributo puede ser tipificado como cualquier referencia.Esta cuestión se discutirá de manera más detallada posteriormente.

40 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 55: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 37: Secciones de visibilidad de atributos

Puede proteger los atributos contra el acceso desde el exterior caracterizándoloscomo atributos privados. No se puede tener acceso directo desde el exterior a loscomponentes privados de la clase. No son visibles para el usuario externo.

Nota: El concepto de amistad es una excepción de esta regla.

Los atributos a los que un usuario externo puede acceder directamente son losatributos públicos. Los componentes públicos de una clase se conocen a vecesde manera colectiva como el interface de la clase.

El uso de la sección de visibilidad privada también se conoce como supresión deinformación o encapsulación. En parte, tiene como fin proteger al usuario deuna clase: Supongamos que los componentes privados de una clase se modificanen algún punto, pero que su interface sigue siendo el mismo. Todos los usuariosexternos sólo pueden acceder a sus componentes a través del interface de laclase, y así pueden continuar trabajando con la clase de la manera habitual unavez realizado el cambio. El usuario no nota el cambio. Sólo se ha modificado laimplementación interna.

En cambio, si los componentes públicos de una clase se modifican de maneraincompatible, todos los usuarios exteriores deberán tener en cuenta estos cambios.Por lo tanto, los atributos públicos deben utilizarse con moderación o se debeevitar realizar cambios incompatibles subsiguientes a los componentes públicosde las clases.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 41

Page 56: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 38: Acceso a atributos privados

Defina atributos privados en la PRIVATE SECTION de una clase. Defina atributospúblicos en la PUBLIC SECTION.

Es sintácticamente imposible acceder directamente a métodos privados desde elexterior. Sin embargo, esto es posible mediante el uso de métodos públicos queemiten o cambian los atributos. El requisito de tiempo de ejecución ligeramentesuperior (llamadas de método en comparación con asignación directa de valor) setiene en cuenta para satisfacer el concepto de encapsulación:

La firma del método público establece claramente qué valores deben o puedentransferirse, y qué tipos deben ser asignados. Esto exime al usuario externo detoda responsabilidad. El método en sí mismo es responsable de asegurar que todoslos atributos privados se tratan de manera consistente.

Para este ejemplo, imagínese que los atributos MAKE y MODEL son públicos. Elriesgo sería demasiado grande, ya que un usuario podría olvidarse de suministraruno de los dos atributos o especificar dos atributos inconsistentes. En sulugar, podría utilizar un método público SET_TYPE para asegurarse de que seespecifican valores para ambos atributos. Un control estricto de la sintaxis regulalas llamadas de método para verificar que se transfieren todos los parámetrosobligatorios. Incluso sería posible que el método en sí mismo realizara unaverificación de consistencia (para ver si una marca determinada de vehículofabrica el modelo escogido), y emitiera una excepción si se produce un error.

Para ahorrar tiempo de ejecución, a veces se definen atributos individuales en lasección de visibilidad pública, pero éstos deben obtener después el suplementoREAD-ONLY.

42 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 57: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 39: Comparación de atributos de instancia con atributos estáticos

Existen dos tipos de atributos:

Atributos de instanciaLos atributos de instancia son atributos que existen una vez por objeto, esdecir, una vez por instancia de tiempo de ejecución de la clase. Estándefinidos con el elemento sintáctico DATA.

Atributos estáticosLos atributos estáticos existen una vez para cada clase y son visibles paratodas las instancias de tiempo de ejecución de esta clase. Están definidos conel elemento sintáctico CLASS-DATA.Los atributos estáticos suelen contener información que se refiere a todaslas instancias, como:

� Tipos y constantes� Memoria intermedia de datos de aplicación central� Información administrativa, como el contador de instancias

La documentación técnica se refiere a menudo a los atributos estáticos comoatributos de clase (compárese con el elemento sintáctico CLASS-DATA). Enobjetos ABAP, como en C++ y Java, el término oficial es atributo estático.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 43

Page 58: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 40: Atributos de instancia y atributos estáticos en el contexto deprograma

El gráfico muestra un ejemplo de cómo el atributo estático N_O_VEHICLESestá relacionado con el resto de elementos de programa en la memoria: Sóloexiste una vez (en la clase cargada) sin tener en cuenta el número de instanciasde LCL_VEHICLE. Por lo tanto, puede decirse que las instancias compartensus atributos comunes.

Atención: Aquí, un objeto de datos entero se define para contar lasinstancias. No es posible averiguar el número de instancias creadas desdeel sistema.

44 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 59: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 41: Sintaxis para métodos

Los métodos son procesos internos en clases que determinan el comportamientode los objetos. Pueden tener acceso a todos los atributos de su clase y, por lo tanto,pueden cambiar el estado de otros elementos.

Los métodos tienen una firma (parámetros y excepciones de interface) queles permite recibir valores cuando se les llama y devolver valores al programade llamada. Los métodos pueden tener cualquier número de parámetrosIMPORTING, EXPORTING y CHANGING. Todos los parámetros pueden sertransmitidos por valor o referencia.

Un código de retorno de método puede definirse con el parámetro RETURN.Siempre debe transmitirse como un valor. En este caso, no se pueden definir losparámetros EXPORTING y CHANGING. También puede utilizarse el parámetroRETURNING para definir métodos funcionales. Esta cuestión se discutirá demanera más detallada posteriormente.

Todos los parámetros de entrada (parámetros IMPORTING y CHANGING)pueden definirse como parámetros opcionales en la declaración mediante lossuplementos OPTIONAL o DEFAULT. No es necesario transferir estos parámetrosde forma obligatoria cuando se llama el objeto. Si se utiliza el suplementoOPTIONAL, el parámetro permanecerá inicializado según el tipo, mientras que elsuplemento DEFAULT permite introducir un valor de inicio.

Al igual que los módulos de funciones, los métodos también permiten el usodel código de retorno SY-SUBRC, pero sólo si las excepciones de firma fuerondefinidas mediante EXCEPTIONS (véase punto 1 del gráfico). A partir de

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 45

Page 60: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

SAP Web AS 6.10, el suplemento RAISING puede utilizarse en su lugar parapropagar excepciones basadas en clases (véase punto 2 del gráfico). El programade llamada trata estas excepciones basadas en clases sin evaluar el código deretorno SY-SUBRC.

¡No utilice ambos conceptos juntos en un programa!

Gráfico 42: Secciones de visibilidad de métodos

Los métodos también deben asignarse a una sección de visibilidad. Ésta determinasi los métodos se llaman desde el exterior de la clase o sólo desde dentro dela clase. En cambio, los métodos privados sólo cumplen el propósito de lamodularización interna.

46 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 61: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 43: Acceso a métodos privados

Los métodos privados se definen en la PRIVATE SECTION de una clase. Losatributos públicos se definen en la PUBLIC SECTION.

No es posible tener acceso directo a métodos privados desde el exterior. Sinembargo, un método privado puede ser llamado por un método público.

En este ejemplo, INIT_TYPE es un método privado que es llamado por el métodopúblico SET_TYPE. La instrucción de inicializar los atributos también podríaexistir en otros contextos, por lo que la definición de este �método auxiliar�privado resulta útil.

Nota: Se trata de un ejemplo introductorio. Más adelante, aprenderá mástécnicas de programación para evaluar parámetros formales.

Área de nombres: Dentro de una clase, los nombres de atributo, los nombresde método, los nombres de evento, los nombres de constante, los nombres detipo y los nombres alias comparten la misma área de nombres. Como con lassubrutinas y los módulos de funciones, existe un área de nombres local adicionaldentro de los métodos. Esto significa que las declaraciones locales sustituyenaquéllas para toda la clase.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 47

Page 62: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 44: Comparación de métodos de instancia y métodos estáticos

Los métodos de instancia se definen mediante la palabra clave sintácticaMETHODS.

Los métodos estáticos se definen a nivel de clase. La restricción que dice quesólo puede accederse a los componentes estáticos tiene efecto en la parte deimplementación. Esto significa que los métodos estáticos no necesitan instancias,es decir, puede tenerse acceso a ellos directamente a través de la clase. Esteaspecto se discutirá con más detalle posteriormente. Los métodos se definenmediante la palabra clave sintáctica CLASS-METHODS.

En este ejemplo, sólo puede accederse al atributo estático N_O_VEHICLES dentrodel método estático GET_N_O_VEHICLES. El resto de atributos de la clase sonatributos de instancia, y sólo pueden aparecer dentro de los métodos de instancia.

La documentación técnica se refiere a menudo a los métodos estáticos como �métodos de clase� (compárese con el elemento sintáctico CLASS-METHODS).En objetos ABAP, como en C++ y Java, el término oficial es método estático.

48 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 63: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 45: Secciones de visibilidad y notación UML

Un diagrama de clases UML enumera primero el nombre de clase y debajo delmismo, los atributos y métodos de clase. La visibilidad de los componentes en unaclase se muestra en UML mediante los caracteres + y -: De manera alternativa,public y private pueden estar por delante del método.

UML también permite a los creadores de herramientas de modelación crear suspropios símbolos de visibilidad. La representación de características de visibilidades opcional y se utiliza normalmente sólo para modelos que están cerca de laimplementación.

Los componentes estáticos están marcados con un carácter de subrayado.

La firma del método se representa de la manera siguiente (opcional):

� Los parámetros de entrada y salida y los parámetros que deben sermodificados se muestran entre paréntesis detrás del nombre de método. Lostipos siempre se especifican después de dos puntos.

� Para un método de función, el nombre de método y los paréntesis van delantedel parámetro de evento, separado por dos puntos.

Your demonstration program should now resemble the executable programSAPBC401_VEHD_MAIN_A.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 49

Page 64: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

This is a good time to include the first exercise of this lesson.

Objetos: Instancias de clasesLas clases podrían utilizarse para escribir aplicaciones completas utilizandosólo componentes estáticos. Sin embargo, el razonamiento de fondo de laprogramación orientada a objetos es crear y trabajar con instancias de clases entiempo de ejecución.

Gráfico 46: Resumen de instancias de clases

Una clase contiene la descripción genérica de un objeto y describe todas lascaracterísticas que tienen en común todos los objetos de la clase. Durante eltiempo de ejecución del programa, la clase se utiliza para crear objetos discretos(instancias) en la memoria. Este proceso se llama instanciación. Si es la primeravez que se tiene acceso a la clase, la clase también se cargará en la memoria.

No es relevante saber qué valores van a escribirse en qué atributos. Técnicamente,el objeto tiene un ID (en este caso, 5) que, sin embargo, no es accesible.

Ejemplo: La instanciación de clase LCL_VEHICLE crea un objeto de vehículo.Los atributos privados siguen conteniendo los valores iniciales técnicos.

50 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 65: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 47: Definición de variables de referencia

DATA r_vehicle1 TYPE REF TO lcl_vehiclese utiliza para definir una variable de referencia tipificada como un puntero haciaobjetos de tipo lcl_vehicle. La referencia cero es el valor inicial técnico deuna variable de referencia. (El puntero no apunta a nada.)

Gráfico 48: Creación de objetos

La sentencia CREATE OBJECT crea un objeto en la memoria. Sus valores deatributo son o bien iniciales o se asignan de acuerdo con la especificación VALUE.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 51

Page 66: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 49: Semántica de referencia de referencias de objeto

Las variables de referencia también pueden asignarse unas a otras.

Para el ejemplo anterior, esto significa que después de la sentencia MOVE,R_VEHICLE1 y R_VEHICLE2 apuntan al mismo objeto.

Sometimes, experienced participants suggest using field symbols for this. If thishappens, it is a good opportunity to clarify the principal differences again.

It is important that you complete and discuss the exercises at the relevant stagesof this lesson. These are arranged so that each one prepares the way for thenext. It can be especially motivating if you demonstrate the exercises for theparticipants, or have them demonstrate their exercises themselves. The topicscovered here, and the successful completion of the exercises, are very importantfor the remainder of the course!

52 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 67: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 50: Recolector de basura

Las referencias independientes son referencias que no han sido definidas dentrode una clase. El recolector de basura es una rutina de sistema que se iniciaautomáticamente siempre que el sistema de tiempo de ejecución no tenga tareasmás importantes por realizar.

En este ejemplo, la referencia al objeto (2)LCL_OBJECT está inicializada.Después no hay referencias que apunten a este objeto. Por ello, el recolector debasura lo borra. En consecuencia, ya no hay referencias que apunten al objeto(4)LCL_OBJECT, por lo tanto, también se borra.

Puede utilizar la consulta lógica IF r_obj IS INITIAL para determinar sir_obj contiene la referencia cero, en otras palabras, si no apunta a ningún objeto.

Do not spend more than 60 seconds discussing the Garbage Collector. Applicationdevelopers cannot influence it. Developers also do not have to work anydifferently depending on whether the Garbage Collector is running.

Some experienced participants refuse to accept that they can no longer have accessto objects if those objects� addresses have been lost.

Caution: The query for IS BOUND would also be possible here, but only makes adifference for data references. If you encounter a question on this, the answer isthat in the case of object references, you can work with both.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 53

Page 68: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 51: Administración de referencia con instanciación múltiple

The component selector -> displayed on the slide will be discussed later: Refer tothis preview!

Si desea mantener varios objetos de la misma clase en su programa, puede definiruna tabla interna que contenga una columna con las referencias de objeto para estaclase. Estos objetos pueden administrarse en la tabla interna con las sentenciashabituales para tablas internas, como APPEND, READ o LOOP.

Para utilizar condiciones lógicas, el pseudocomponente TABLE_LINE debeutilizarse cuando se utilizan tablas internas de una única columna. Para ello, sinembargo, los atributos relevantes deben ser públicos.

54 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 69: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 52: Ejemplo de agregación

During an aggregation, the WHEEL objects must be able to exist on their own, inother words independently of the vehicle. Independent references must thereforestill exist to them. This is indicated by the green arrows pointing to the WHEELobjects.

Los objetos de la clase LCL_WHEEL tienen su propia identidad. Pueden crearseen este ejemplo, sin importar la existencia de un objeto en la clase LCL_VEHICLE.

Las referencias se transfieren a objetos de la clase LCL_VEHICLE para crearla asociación deseada.

Your demonstration program should now resemble the executable programSAPBC401_VEHICLE_MAIN_B.

Here, the next exercise would be suitable for the airplane objects referenced inthe internal table.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 55

Page 70: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Acceso a atributos y métodosEn esta sección aprenderá cómo puede utilizar las clases y sus instancias. Es decir,obtendrá información acerca del proceso entero, empezando por las conexionesestáticas de varias instancias hasta sus efectos prácticos.

Gráfico 53: Métodos de llamada

Un objeto que requiere los servicios de otro objeto envía un mensaje al objeto queofrece los servicios. Este mensaje nombra la operación que debe ser ejecutada. Laimplementación de esta operación se conoce como un método. Para simplificarlas cosas, la palabra método se utilizará a partir de ahora como un sinónimode operación y mensaje. Por lo tanto, el comportamiento de un objeto vienedeterminado por su método. La firma de un método también puede utilizarsepara intercambiar valores.

El ejemplo muestra la sintaxis más breve para llamadas de método (soportadasdesde SAP Web AS 6.10) en las que se omite el prefijo CALL-METHOD.

56 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 71: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 54: Llamada de métodos de instancia � Sintaxis

Los métodos de instancia se llaman conCALL METHOD ref->method_name .... Al llamar

un método de instancia desde otro método de instancia se puede omitir el nombrede instancia ref. El método se ejecuta automáticamente para el objeto actual.

Una sintaxis más corta también está permitida a partir de SAP Web AS 6.10. En estecaso, se omite CALL METHOD y los parámetros se enumeran entre paréntesis.No debe haber ningún espacio antes de los paréntesis, pero debe haber al menosuno después de los paréntesis. Cuando se llama a un método que sólo tiene unparámetro de importación, se puede especificar el parámetro real en los paréntesissin la necesidad de otros suplementos. Cuando se llama a un método que sólotiene parámetros de importación, se puede omitir el suplemento EXPORTING.

Los parámetros RECEIVING, IMPORTING y CHANGING se excluyenmutuamente. Par más detalles, léase la sección acerca de métodos funcionales.Por lo demás, son válidas las mismas reglas que rigen para llamar a un módulode funciones.

It is not worth making a big deal of the shorter syntax. It was introduced to makeABAP Objects syntax resemble C++ and Java even more closely. However,participants will also have to maintain older source code, so they need to know theexplicit syntax as well.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 57

Page 72: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 55: Llamada de métodos estáticos - Sintaxis

Los métodos estáticos (también llamados métodos de clase) se llaman utilizandoCALL METHOD classname=>method_name ....

Como los atributos estáticos, los métodos estáticos se llaman por su nombre declase, ya que no necesitan instancias.

Como con los métodos de instancia, cuando se llama a un método estático desdedentro de una clase se puede omitir el classname. Por lo demás son válidas lasmismas reglas que rigen para llamar a un método de instancia.

It is time to do the exercise for the method calls. It is better to do the sub-exerciseon the functional methods separately, in other words afterwards. Otherwise, theparticipants are bound to become confused and mix up all of the techniques.

58 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 73: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 56: Métodos funcionales

Los métodos que tienen un parámetro RETURNING se describen como métodosfuncionales. Esto significa que no pueden tener ni un parámetro EXPORTING niun parámetro CHANGING. El parámetro RETURNING siempre debe transmitirsemediante el suplemento VALUE, es decir, debe ser transmitido por un valor.

Los métodos funcionales pueden llamarse directamente dentro de variasexpresiones:

� Expresiones lógicas: IF, ELSEIF, WHILE, CHECK, WAIT� Condiciones de caso: CASE, WHEN� Expresiones aritméticas y expresiones de bit: COMPUTE� Fuentes de valores como una copia local: MOVE� Buscar cláusulas para tablas internas, suponiendo que el operando no es un

componente de la entrada en tabla: LOOP AT ... WHERE

Functional method calls are sometimes confused with the short form of othermethod calls. The former are possible from the beginning (that is, as of SAP R/34.6A). The latter are only possible as of SAP Web AS 6.10.

The exercise step that handles functional methods should be performed on itsown, in other words, as a separate step.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 59

Page 74: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 57: Métodos funcionales � Ejemplos

En el primero de estos ejemplos, dos llamadas de métodos de instancia funcionalesrepresentan los dos sumandos de un suplemento.

El segundo ejemplo muestra la llamada de un método estático funcional en laforma corta: El objeto de datos NUMBER es el parámetro real para el parámetrode método RETURNING. La sintaxis detallada es la siguiente:

DATA number TYPE i.

...

CALL METHOD lcl_vehicle=>get_n_o_vehicles RECEIVINGre_count = number.

60 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 75: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Gráfico 58: Acceso a atributos públicos

Se accede a atributos públicos desde fuera de una clase de la misma maneraque las llamadas de método: Se accede a los atributos estáticos medianteclassname=>static_attribute. Se accede a los atributos de instanciacon ref->instance_attribute.

Your demonstration program should now resemble the executable programSAPBC401_VEHICLE_MAIN_C.

ConstructoresExisten dos tipos de métodos en objetos ABAP. Generalmente no se llamanexplícitamente con CALL METHOD (o la forma corta relevante), sino que sellaman de forma implícita. Los constructores son el primer tipo de método.

Some participants who have experiences with other object-oriented languages maystruggle at this point. In some of these languages, the constructor concept is useddifferently than in ABAP Objects. This may cause confusion.

Try to avoid this confusion because the concept is actually very simple.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 61

Page 76: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Gráfico 59: Constructor (instancia)

El constructor es un método de instancia especial en una clase y siempre sellama CONSTRUCTOR. Este término abreviado significa en realidad constructorde instancia.

El constructor se llama automáticamente en tiempo de ejecución con la sentenciaCREATE OBJECT. Al definir constructores, siempre se deben tener en cuentalos puntos siguientes:

� Cada clase puede tener como máximo un constructor (de instancia).� El constructor debe definirse en el área pública.� La firma del constructor sólo puede tener parámetros de importación y

excepciones.� Si se emiten excepciones en el constructor, no se crearán instancias, de

manera que no se ocupa espacio de memoria principal.� Con la excepción de un caso extraordinario, generalmente no se puede llamar

el constructor de forma explícita.

Nota: No hay ningún destructor en objetos ABAP. Es decir, no existeningún método de instancia que se llame automáticamente desde lamemoria inmediatamente antes de que se borre el objeto.

(Los comentarios correspondientes en la biblioteca SAP y los accesosvía menús fuera de Workbench ABAP sólo existen en las llamadas desistema internas.)

62 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 77: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Unfortunately, they are not dynamically hidden. If they were, we would not needto deal with the participants� questions. Avoid any discussion about this topic.

Gráfico 60: Constructor � Ejemplo

Por ejemplo, un constructor es necesario si, después de la instanciación de unaclase:

� se deben asignar recursos� se deben inicializar atributos que no pueden cubrirse con el suplemento

VALUE en la sentencia DATA� se deben modificar atributos estáticos� se deben enviar mensajes que contengan la información de que se ha creado

un objeto nuevo

Your demonstration program should now resemble the executable programSAPBC401_VEHICLE_MAIN_D.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 63

Page 78: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Now you can perform the appropriate exercise for the constructors in this lesson.The exercise for the static constructor should be done later.

Gráfico 61: Ejemplo de un constructor estático

El constructor estático es un método estático especial en una clase y siempre sellama CLASS_CONSTRUCTOR. Se ejecuta una vez como máximo por programa(y clase). El constructor estático se llama automáticamente antes de que se accedapor primera vez a la clase, y antes de que cualquiera de las siguientes accionesse ejecuten por primera vez:

� crear una instancia de esta clase (CREATE OBJECT)� acceder a un atributo estático de esta clase� llamar un método estático de esta clase� registrar un método de programa de control de eventos para un evento en

esta clase

Deberán tenerse siempre en cuenta los puntos siguientes al definir constructoresestáticos:

� cada clase tiene, como máximo, un constructor estático� el constructor estático debe definirse en el área pública� la firma del constructor no puede tener parámetros de importación ni

excepciones� el constructor estático no puede ser llamado de forma explícita

64 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 79: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

The exercise for the static constructor should be done here! It also has theadvantage that the participants finally get to grips with SQL accesses and learnthat nothing changes in terms of their SQL knowledge: How comforting!

You could make a careful comparison with the LOAD-OF-PROGRAM ABAPevent for function groups.

AutoreferenciaEn algunos casos es necesario tener una autoreferencia disponible. En objetosABAP, las autoreferencias siempre están predefinidas, pero sólo son útiles enciertos contextos y sólo allí están disponibles sintácticamente.

Gráfico 62: Autoreferencia

Es posible dirigirse a un objeto en sí mediante la variable de referencia predefinidaME dentro de sus métodos de instancia. Normalmente no es necesario utilizarel prefijo

me-> en estos casos, pero se puede utilizar para mejorarla facilidad de lectura.

Sin embargo, es necesario cuando se desea indicar una distinción entre objetos dedatos locales y atributos de instancia con el mismo nombre.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 65

Page 80: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

El siguiente caso muestra otro uso importante: Cuando se llama un métodoexterno, un objeto de cliente debe exportar una referencia a sí mismo. ME puedeutilizarse entonces como un parámetro actual con EXPORTING o CHANGING.

Your demonstration program should now resemble the executable programSAPBC401_VEHICLE_MAIN_E.

This is a good time to include the fifth exercise of this lesson. You must carry outthis exercise, as a the private method to be developed here forms the basis for alesson that appears later in the course. Participants with considerable programmingexperience can tackle the final, optional exercise in the lesson !

66 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 81: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

61 Ejercicio 2: Clases localesDuración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Declarar clases locales� Definir atributos� Definir e implementar métodos

Ejemplo empresarialUsted es un programador de una corporación aérea propietaria de varias compañíasaéreas. Empiece a desarrollar un programa orientado a objetos que pueda gestionarlas compañías aéreas.

Tarea 1:Cree un programa nuevo.

1. Cree un programa ejecutable sin un Include TOP.

Nombre del programa: ZBC401_##_MAIN

(donde ## es su número de grupo de dos cifras). )

2. Cree un programa de Include e inclúyalo en su programa principalZBC401_##_MAIN.

Nombre del programa: ZBC401_##_AIRPLANE

(donde ## es su número de grupo de dos cifras). )

Tarea 2:Declare una clase para aviones.

1. Dentro de su programa de Include, declare la clase localLCL_AIRPLANE.

2. Defina los dos atributos de instancia privados

NAME (nombre del avión), tipo de datos STRING

PLANETYPE (tipo de avión), tipo de datos SAPLANE-PLANETYPE

y el atributo estático privado

N_O_AIRPLANES (contador de instancias), tipo de datos I.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 67

Page 82: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

3. Defina el método de instancia público SET_ATTRIBUTES para configurarlos atributos de instancia privados.

Su firma debería constar de dos parámetros de importación adecuados queestén definidos como compatibles con los dos atributos.

Implemente el método de manera que los dos atributos de instancia esténfijados.

4. Defina el método de instancia público DISPLAY_ATTRIBUTES paravisualizar los atributos de instancia privados.

Implemente el método de manera que los valores de los dos atributos deinstancia se emitan como una lista ABAP. También puede dar salida a iconossi el grupo de tipo ICON está cargado.

Consejo: Para ello, utilice la sentenciaTYPE-POOLS icon.

.

Nota: Siendo exactos, para cumplir el principio de delegación,la lectura de los valores de atributo y su salida no deberíanimplementarse en el mismo método. Sin embargo, hágalo en estecaso por motivos de tiempo.

5. Defina el método estático público DISPLAY_N_O_AIRPLANES paravisualizar los atributos estáticos privados.

Implemente el método de manera que el valor de los atributos estáticosse emita en la lista ABAP.

Nota: Hasta aquí, su clase no dispone de un mecanismo quegarantice que el contador de instancias aumente cada vez que secrea un objeto. Usted decide si desea dejarlo así de momento, o siquiere controlar temporalmente el incremento mediante el métodoSET_ATTRIBUTES.

68 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 83: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Solución 2: Clases localesTarea 1:Cree un programa nuevo.

1. Cree un programa ejecutable sin un Include TOP.

Nombre del programa: ZBC401_##_MAIN

(donde ## es su número de grupo de dos cifras). )

a) Lleve a cabo este paso de la manera habitual. Puede encontrarinformación adicional en la biblioteca SAP.

Solución modelo: SAPBC401_AIRS_MAIN_A

2. Cree un programa de Include e inclúyalo en su programa principalZBC401_##_MAIN.

Nombre del programa: ZBC401_##_AIRPLANE

(donde ## es su número de grupo de dos cifras). )

a) Lleve a cabo este paso de la manera habitual. Puede encontrarinformación adicional en la biblioteca SAP.

Solución modelo: SAPBC401_AIRS_A

b) Véase el extracto del código fuente de la solución modelo.

Tarea 2:Declare una clase para aviones.

1. Dentro de su programa de Include, declare la clase localLCL_AIRPLANE.

a) Véase el extracto del código fuente de la solución modelo.

2. Defina los dos atributos de instancia privados

NAME (nombre del avión), tipo de datos STRING

PLANETYPE (tipo de avión), tipo de datos SAPLANE-PLANETYPE

y el atributo estático privado

N_O_AIRPLANES (contador de instancias), tipo de datos I.

a) Véase el extracto del código fuente de la solución modelo.

3. Defina el método de instancia público SET_ATTRIBUTES para configurarlos atributos de instancia privados.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 69

Page 84: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Su firma debería constar de dos parámetros de importación adecuados queestén definidos como compatibles con los dos atributos.

Implemente el método de manera que los dos atributos de instancia esténfijados.

a) Véase el extracto del código fuente de la solución modelo.

4. Defina el método de instancia público DISPLAY_ATTRIBUTES paravisualizar los atributos de instancia privados.

Implemente el método de manera que los valores de los dos atributos deinstancia se emitan como una lista ABAP. También puede dar salida a iconossi el grupo de tipo ICON está cargado.

Consejo: Para ello, utilice la sentenciaTYPE-POOLS icon.

.

Nota: Siendo exactos, para cumplir el principio de delegación,la lectura de los valores de atributo y su salida no deberíanimplementarse en el mismo método. Sin embargo, hágalo en estecaso por motivos de tiempo.

a) Véase el extracto del código fuente de la solución modelo.

5. Defina el método estático público DISPLAY_N_O_AIRPLANES paravisualizar los atributos estáticos privados.

Implemente el método de manera que el valor de los atributos estáticosse emita en la lista ABAP.

Nota: Hasta aquí, su clase no dispone de un mecanismo quegarantice que el contador de instancias aumente cada vez que secrea un objeto. Usted decide si desea dejarlo así de momento, o siquiere controlar temporalmente el incremento mediante el métodoSET_ATTRIBUTES.

a) Véase el extracto del código fuente de la solución modelo.

ResultadoExtracto del código fuente:

Continúa en la página siguiente

70 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 85: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

SAPBC401_AIRS_MAIN_A

REPORT sapbc401_airs_main_a.

TYPE-POOLS icon.

INCLUDE sapbc401_airs_a.

SAPBC401_AIRS_A

*&---------------------------------------------------------------------*

*& Include SAPBC401_AIRS_A *

*&---------------------------------------------------------------------*

*------------------------------------------------------------------*

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

CLASS lcl_airplane DEFINITION.

PUBLIC SECTION.

"--------------------------------

CONSTANTS: pos_1 TYPE i VALUE 30.

METHODS: set_attributes IMPORTING

im_name TYPE string

im_planetype TYPE saplane-planetype,

display_attributes.

CLASS-METHODS: display_n_o_airplanes.

PRIVATE SECTION.

"----------------------------------

DATA: name TYPE string,

planetype TYPE saplane-planetype.

CLASS-DATA: n_o_airplanes TYPE i.

ENDCLASS. "lcl_airplane DEFINITION

*------------------------------------------------------------------*

* CLASS lcl_airplane IMPLEMENTATION *

*------------------------------------------------------------------*

CLASS lcl_airplane IMPLEMENTATION.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 71

Page 86: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

METHOD set_attributes.

name = im_name.

planetype = im_planetype.

* doesn’t make sense so much -

* only in order to get an effect

* after calling display_n_o_airplanes:

n_o_airplanes = n_o_airplanes + 1.

ENDMETHOD. "set_attributes

METHOD display_attributes.

WRITE: / icon_ws_plane AS ICON,

/ ’Name of airplane:’(001), AT pos_1 name,

/ ’Airplane type’(002), AT pos_1 planetype.

ENDMETHOD. "display_attributes

METHOD display_n_o_airplanes.

WRITE: /, / ’Total number of planes’(ca1),

AT pos_1 n_o_airplanes LEFT-JUSTIFIED, /.

ENDMETHOD. "display_n_o_airplanes

ENDCLASS. "lcl_airplane IMPLEMENTATION

72 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 87: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

67 Ejercicio 3: ObjetosDuración del ejercicio: 20 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Definir variables de referencia� Instanciar objetos� Procesar referencias de objeto mediante una tabla interna

Ejemplo empresarialCree instancias de su clase de avión y asegúrese de que sus direcciones no sepierdan.

Tarea 1:Defina variables de referencia.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Defina una variable de referencia para las instancias de la claseLCL_AIRPLANE.

2. Defina una tabla interna para grabar referencias en memoria intermedia eninstancias de la clase LCL_AIRPLANE.

Tarea 2:Cree objetos de avión.

1. Cree varias instancias de la clase local LCL_AIRPLANE y grabe susreferencias en memoria intermedia en la tabla interna.

2. Observe la ejecución del programa en el ABAP Debugger.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 73

Page 88: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Solución 3: ObjetosTarea 1:Defina variables de referencia.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Defina una variable de referencia para las instancias de la claseLCL_AIRPLANE.

a) Solución modelo: SAPBC401_AIRS_MAIN_B

b) Véase el extracto del código fuente de la solución modelo.

2. Defina una tabla interna para grabar referencias en memoria intermedia eninstancias de la clase LCL_AIRPLANE.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 2:Cree objetos de avión.

1. Cree varias instancias de la clase local LCL_AIRPLANE y grabe susreferencias en memoria intermedia en la tabla interna.

a) Véase el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

74 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 89: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

2. Observe la ejecución del programa en el ABAP Debugger.

a) Lleve a cabo este paso de la manera habitual. Para más información,consulte la biblioteca SAP.

ResultadoExtracto del código fuente:

SAPBC401_AIRS_MAIN_B

REPORT sapbc401_airs_main_b.

TYPE-POOLS icon.

INCLUDE sapbc401_airs_a.

DATA: r_plane TYPE REF TO lcl_airplane,

plane_list TYPE TABLE OF REF TO lcl_airplane.

START-OF-SELECTION.

*##############################

CREATE OBJECT r_plane.

APPEND r_plane TO plane_list.

CREATE OBJECT r_plane.

APPEND r_plane TO plane_list.

CREATE OBJECT r_plane.

APPEND r_plane TO plane_list.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 75

Page 90: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

76 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 91: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

71 Ejercicio 4: Llamadas de métodosDuración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Llamar métodos no funcionales� Definir métodos funcionales� Llamar métodos funcionales

Ejemplo empresarialDebe rellenar los atributos de los objetos de avión �vacíos� con valores adecuados.

Tarea 1:Llame los métodos de su clase.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Llame el método estático DISPLAY_N_O_AIRPLANES dos veces: Unavez antes y otra vez después de las instanciaciones.

Atención: Por los motivos que se explican en el primer ejercicio, nonotará ningún efecto por el momento.

2. Utilice el método SET_ATTRIBUTES para fijar los atributos de todos losobjetos que ya se han creado. Seleccione un nombre único para los aviones.Cuando asigne los tipos de avión, utilice la información incluida en la tablaSAPLANE como guía (por ejemplo, ’747-400’). Utilice también almenos un tipo de avión no válido.

3. Visualice los valores de atributo de todos los aviones en un loop en la listaABAP mediante el método DISPLAY_ATTRIBUTES.

Tarea 2:Añada un método funcional a su clase.

1. En su clase, defina el método funcional estático públicoGET_N_O_AIRPLANES. La firma debe consistir sólo en el parámetroresultante RE_COUNT, que debe ser un número entero.

2. Llame este método en el programa principal y emita el valor en la lista ABAP.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 77

Page 92: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Solución 4: Llamadas de métodosTarea 1:Llame los métodos de su clase.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Llame el método estático DISPLAY_N_O_AIRPLANES dos veces: Unavez antes y otra vez después de las instanciaciones.

Atención: Por los motivos que se explican en el primer ejercicio, nonotará ningún efecto por el momento.

a) Solución modelo: SAPBC401_AIRS_MAIN_C

b) Véase el extracto del código fuente de la solución modelo.

2. Utilice el método SET_ATTRIBUTES para fijar los atributos de todos losobjetos que ya se han creado. Seleccione un nombre único para los aviones.Cuando asigne los tipos de avión, utilice la información incluida en la tablaSAPLANE como guía (por ejemplo, ’747-400’). Utilice también almenos un tipo de avión no válido.

a) Véase el extracto del código fuente de la solución modelo.

3. Visualice los valores de atributo de todos los aviones en un loop en la listaABAP mediante el método DISPLAY_ATTRIBUTES.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 2:Añada un método funcional a su clase.

1. En su clase, defina el método funcional estático públicoGET_N_O_AIRPLANES. La firma debe consistir sólo en el parámetroresultante RE_COUNT, que debe ser un número entero.

a) Véase el extracto del código fuente de la solución modelo.

2. Llame este método en el programa principal y emita el valor en la lista ABAP.

a) Véase el extracto del código fuente de la solución modelo.

ResultadoCódigo fuente:

Continúa en la página siguiente

78 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 93: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

SAPBC401_AIRS_MAIN_C

REPORT sapbc401_airs_main_c.

TYPE-POOLS icon.

INCLUDE sapbc401_airs_c.

DATA: r_plane TYPE REF TO lcl_airplane,

plane_list TYPE TABLE OF REF TO lcl_airplane,

count TYPE i.

START-OF-SELECTION.

*##############################

lcl_airplane=>display_n_o_airplanes( ).

CREATE OBJECT r_plane.

APPEND r_plane TO plane_list.

r_plane->set_attributes( im_name = ’LH Berlin’

im_planetype = ’A321’ ).

CREATE OBJECT r_plane.

APPEND r_plane TO plane_list.

r_plane->set_attributes( im_name = ’AA New York’

im_planetype = ’747-400’ ).

CREATE OBJECT r_plane.

APPEND r_plane TO plane_list.

r_plane->set_attributes( im_name = ’US Hercules’

im_planetype = ’747-500’ ).

LOOP AT plane_list INTO r_plane.

r_plane->display_attributes( ).

ENDLOOP.

* long syntax for functional call:

* CALL METHOD lcl_airplane=>get_n_o_airplanes

* RECEIVING

* re_count = count.

* a little bit shorter:

* lcl_airplane=>get_n_o_airplanes( RECEIVING re_count = count ).

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 79

Page 94: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

* the shortest syntax for functional call:

count = lcl_airplane=>get_n_o_airplanes( ).

SKIP 2.

WRITE: / ’Gesamtzahl der Flugzeuge’(ca1), count.

SAPBC401_AIRS_C

*&---------------------------------------------------------------------*

*& Include SAPBC401_AIRS_C *

*& Show functional static method get_n_o_airplanes *

*&---------------------------------------------------------------------*

*------------------------------------------------------------------*

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

CLASS lcl_airplane DEFINITION.

PUBLIC SECTION.

"--------------------------------

CONSTANTS: pos_1 TYPE i VALUE 30.

METHODS: set_attributes IMPORTING

im_name TYPE string

im_planetype TYPE saplane-planetype,

display_attributes.

CLASS-METHODS: display_n_o_airplanes,

get_n_o_airplanes RETURNING value(re_count) TYPE i.

PRIVATE SECTION.

"----------------------------------

DATA: name TYPE string,

planetype TYPE saplane-planetype.

CLASS-DATA: n_o_airplanes TYPE i.

ENDCLASS. "lcl_airplane DEFINITION

*------------------------------------------------------------------*

* CLASS lcl_airplane IMPLEMENTATION *

*------------------------------------------------------------------*

CLASS lcl_airplane IMPLEMENTATION.

Continúa en la página siguiente

80 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 95: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

METHOD set_attributes.

name = im_name.

planetype = im_planetype.

n_o_airplanes = n_o_airplanes + 1.

ENDMETHOD. "set_attributes

METHOD display_attributes.

WRITE: / icon_ws_plane AS ICON,

/ ’Name des Flugzeugs:’(001), AT pos_1 name,

/ ’Flugzeugtyp’(002), AT pos_1 planetype.

ENDMETHOD. "display_attributes

METHOD display_n_o_airplanes.

WRITE: /, / ’Gesamtzahl der Flugzeuge’(ca1),

AT pos_1 n_o_airplanes LEFT-JUSTIFIED, /.

ENDMETHOD. "display_n_o_airplanes

METHOD get_n_o_airplanes.

re_count = n_o_airplanes.

ENDMETHOD. "get_n_o_airplanes

ENDCLASS. "lcl_airplane IMPLEMENTATION

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 81

Page 96: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

82 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 97: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

77 Ejercicio 5: ConstructoresDuración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Definir e implementar constructores de instancia� Crear instancias de clases que contengan un constructor de instancia� Definir e implementar constructores estáticos

Ejemplo empresarialHaga que su programa sea más realista: Los objetos de avión reciben sus atributosen cuanto se crean.

Tarea 1:Defina un constructor de instancia.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior. (donde ## es su número de grupo de dos cifras). )

Defina una variable de referencia con una firma adecuada para las instanciasde su clase LCL_AIRPLANE.

Impleméntela de manera que los dos atributos de instancia estén fijados yque el contador de instancias N_O_AIRPLANES aumente en uno.

2. Si anteriormente utilizó el método SET_ATTRIBUTES para incrementar elcontador de instancias, elimine ahora la sentencia relevante del método.

Tarea 2:Cree objetos de avión.

1. Sus sentencias CREATE OBJECT del ejercicio anterior deberían ser ahoraincorrectas desde un punto de vista sintáctico. Adáptelas y corríjalas.

2. Si es necesario, elimine las llamadas del método SET_ATTRIBUTES.

3. Siga la ejecución del programa en el ABAP Debugger.

Tarea 3:Defina e implemente el constructor estático

1. Defina la tabla interna LIST_OF_PLANETYPES como un atributo de claseprivado.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 83

Page 98: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Para especificar el tipo de esta tabla interna, defina los tipos de tablaZ_##_PLANETYPE en el Dictionary ABAP. De manera alternativa, tambiénpuede utilizar los tipos predefinidos TY_PLANETYPES.

Utilice el campo PLANETYPE como una clave para la tabla interna.

2. Defina el constructor estático en la clase LCL_AIRPLANE.

Implemente el constructor de manera que la tabla internaLIST_OF_PLANETYPES se rellene con todas las filas de la tabla de base dedatos SAPLANE. Para este fin puede utilizar la técnica ARRAY FETCH.

3. Compruebe que el constructor estático se llama correctamente y que la tablainterna se ha rellenado en el programa principal. ¿Dónde se ha llamado elconstructor estático en el programa principal?

84 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 99: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Solución 5: ConstructoresTarea 1:Defina un constructor de instancia.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior. (donde ## es su número de grupo de dos cifras). )

Defina una variable de referencia con una firma adecuada para las instanciasde su clase LCL_AIRPLANE.

Impleméntela de manera que los dos atributos de instancia estén fijados yque el contador de instancias N_O_AIRPLANES aumente en uno.

a) Solución modelo: SAPBC401_AIRS_MAIN_D

b) Véase el extracto del código fuente de la solución modelo.

2. Si anteriormente utilizó el método SET_ATTRIBUTES para incrementar elcontador de instancias, elimine ahora la sentencia relevante del método.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 2:Cree objetos de avión.

1. Sus sentencias CREATE OBJECT del ejercicio anterior deberían ser ahoraincorrectas desde un punto de vista sintáctico. Adáptelas y corríjalas.

a) Véase el extracto del código fuente de la solución modelo.

2. Si es necesario, elimine las llamadas del método SET_ATTRIBUTES.

a) Véase el extracto del código fuente de la solución modelo.

3. Siga la ejecución del programa en el ABAP Debugger.

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional acerca de ABAP Debugger en la biblioteca SAP.

Tarea 3:Defina e implemente el constructor estático

1. Defina la tabla interna LIST_OF_PLANETYPES como un atributo de claseprivado.

Para especificar el tipo de esta tabla interna, defina los tipos de tablaZ_##_PLANETYPE en el Dictionary ABAP. De manera alternativa, tambiénpuede utilizar los tipos predefinidos TY_PLANETYPES.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 85

Page 100: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Utilice el campo PLANETYPE como una clave para la tabla interna.

a) Véase el extracto del código fuente de la solución modelo.

2. Defina el constructor estático en la clase LCL_AIRPLANE.

Implemente el constructor de manera que la tabla internaLIST_OF_PLANETYPES se rellene con todas las filas de la tabla de base dedatos SAPLANE. Para este fin puede utilizar la técnica ARRAY FETCH.

a) Véase el extracto del código fuente de la solución modelo.

3. Compruebe que el constructor estático se llama correctamente y que la tablainterna se ha rellenado en el programa principal. ¿Dónde se ha llamado elconstructor estático en el programa principal?

a) Antes de acceder a la clase por primera vez (antes deDISPLAY_N_O_AIRPLANES, en este caso).

ResultadoExtracto del código fuente:

SAPBC401_AIRS_MAIN_D

REPORT sapbc401_airs_main_d.

TYPE-POOLS icon.

INCLUDE sapbc401_airs_d.

DATA: r_plane TYPE REF TO lcl_airplane,

plane_list TYPE TABLE OF REF TO lcl_airplane.

START-OF-SELECTION.

*##############################

lcl_airplane=>display_n_o_airplanes( ).

CREATE OBJECT r_plane EXPORTING im_name = ’LH Berlin’

im_planetype = ’A321’.

APPEND r_plane TO plane_list.

r_plane->display_attributes( ).

CREATE OBJECT r_plane EXPORTING im_name = ’AA New York’

im_planetype = ’747-400’.

Continúa en la página siguiente

86 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 101: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

APPEND r_plane TO plane_list.

r_plane->display_attributes( ).

CREATE OBJECT r_plane EXPORTING im_name = ’US Hercules’

im_planetype = ’747-500’.

APPEND r_plane TO plane_list.

r_plane->display_attributes( ).

lcl_airplane=>display_n_o_airplanes( ).

SAPBC401_AIRS_D

*&---------------------------------------------------------------------*

*& Include SAPBC401_AIRS_D *

*&---------------------------------------------------------------------*

*------------------------------------------------------------------*

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

CLASS lcl_airplane DEFINITION.

PUBLIC SECTION.

"--------------------------------

CONSTANTS: pos_1 TYPE i VALUE 30.

METHODS: constructor IMPORTING

im_name TYPE string

im_planetype TYPE saplane-planetype,

display_attributes.

CLASS-METHODS: class_constructor.

CLASS-METHODS: display_n_o_airplanes.

PRIVATE SECTION.

"----------------------------------

DATA: name TYPE string,

planetype TYPE saplane-planetype.

CLASS-DATA: n_o_airplanes TYPE i.

CLASS-DATA: list_of_planetypes TYPE ty_planetypes. "itab type in Dic.

ENDCLASS.

*------------------------------------------------------------------*

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 87

Page 102: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

* CLASS lcl_airplane IMPLEMENTATION *

*------------------------------------------------------------------*

CLASS lcl_airplane IMPLEMENTATION.

METHOD constructor.

name = im_name.

planetype = im_planetype.

n_o_airplanes = n_o_airplanes + 1.

ENDMETHOD. "constructor

METHOD class_constructor.

SELECT * FROM saplane INTO TABLE list_of_planetypes.

ENDMETHOD.

METHOD display_attributes.

WRITE: / icon_ws_plane AS ICON,

/ ’Name des Flugzeugs’(001), AT pos_1 name,

/ ’Type of airplane: ’(002), AT pos_1 planetype.

ENDMETHOD. "display_attributes

METHOD display_n_o_airplanes.

WRITE: /, / ’Number of airplanes: ’(ca1),

AT pos_1 n_o_airplanes LEFT-JUSTIFIED, /.

ENDMETHOD. "display_n_o_airplanes

ENDCLASS. "lcl_airplane IMPLEMENTATION

88 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 103: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

83 Ejercicio 6: Métodos privadosDuración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Utilizar el principio de delegación� Estructurar y llamar métodos privados� Utilizar la palabra clave ME

Ejemplo empresarialDesea visualizar los datos de status técnico de un avión.

Tarea 1:Declare otro método.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Dentro de su clase LCL_AIRPLANE, defina el método estático privadoGET_TECHNICAL_ATTRIBUTES.

La firma debe estar formada por el parámetro de importación del tipo deavión y los dos parámetros de exportación de peso y capacidad del depósito.Utilice la tabla transparente SAPLANE como guía para especificar los tiposde estos parámetros formales.

2. Implemente el método de manera que los valores de los parámetros deexportación puedan determinarse mediante el acceso de registro individual ala tabla interna LIST_OF_PLANETYPES.

Nota: Si la tabla no contiene ningún valor para el tipo avión, deberáignorarse de momento.

Para ser exactos, la unidad de medida correcta también deberíaseleccionarse y exportarse. Sin embargo, por razones de tiempo nohace falta que lo haga en este ejercicio.

Tarea 2:Llame al método.

1. Si es posible, llame al método GET_TECHNICAL_ATTRIBUTES desde elprograma principal.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 89

Page 104: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

2. Llame el método GET_TECHNICAL_ATTRIBUTES desde el métodoDISPLAY_ATTRIBUTES para obtener datos técnicos adicionales.Introduzca estos datos adicionales en el método de llamada.

3. Observe la ejecución del programa en el ABAP Debugger.

4. ¿Qué soluciones alternativas podrían utilizarse para resolver las tareas?

Tarea 3: (opcional)Cree y trate una excepción.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Si la lectura del tipo de avión en el método GET_TECHNICAL_AT-TRIBUTES no se lleva a cabo con éxito (SY-SUBRC <> 0), debería crearsela excepción WRONG_PLANETYPE.

Para ello, utilice el suplemento EXCEPTION en el interface de método.

La excepción debería crearse o desencadenarse mediante el comando RAISE.

Nota: Probablemente conozca aún esta técnica clásica de tratamientode excepciones de usar módulos de funciones.

Más adelante en este curso, sustituiremos esta técnica clásica másantigua por una técnica moderna de tratamiento de excepcionesutilizando clases de excepción.

2. Si llama el método privado GET_TECHNICAL_ATTRIBUTES en elmétodo de llamada DISPLAY_ATTRIBUTES, esta excepción deberádeclararse mediante el suplemento EXCEPTIONS.

Si se produce una excepción en GET_TECHNICAL_ATTRIBUTES,podrá verificarlo utilizando el SY-SUBRC en el método de llamada (véaseconcepto conocido con módulos de funciones).

En este ejercicio, el uso de un tipo de avión incorrecto con SY-SUBRC <> 0,simplemente debería documentarse con una sentencia WRITE.

90 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 105: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

Solución 6: Métodos privadosTarea 1:Declare otro método.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Dentro de su clase LCL_AIRPLANE, defina el método estático privadoGET_TECHNICAL_ATTRIBUTES.

La firma debe estar formada por el parámetro de importación del tipo deavión y los dos parámetros de exportación de peso y capacidad del depósito.Utilice la tabla transparente SAPLANE como guía para especificar los tiposde estos parámetros formales.

a) Solución modelo: SAPBC401_AIRS_MAIN_E

b) Véase el extracto del código fuente de la solución modelo.

2. Implemente el método de manera que los valores de los parámetros deexportación puedan determinarse mediante el acceso de registro individual ala tabla interna LIST_OF_PLANETYPES.

Nota: Si la tabla no contiene ningún valor para el tipo avión, deberáignorarse de momento.

Para ser exactos, la unidad de medida correcta también deberíaseleccionarse y exportarse. Sin embargo, por razones de tiempo nohace falta que lo haga en este ejercicio.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 2:Llame al método.

1. Si es posible, llame al método GET_TECHNICAL_ATTRIBUTES desde elprograma principal.

a) Si se trata de un método privado, no podrá llamarlo desde el programaprincipal. Esto sólo es posible para métodos públicos.

2. Llame el método GET_TECHNICAL_ATTRIBUTES desde el métodoDISPLAY_ATTRIBUTES para obtener datos técnicos adicionales.Introduzca estos datos adicionales en el método de llamada.

a) Véase el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 91

Page 106: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

3. Observe la ejecución del programa en el ABAP Debugger.

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional acerca de ABAP Debugger en la biblioteca SAP.

4. ¿Qué soluciones alternativas podrían utilizarse para resolver las tareas?

Respuesta:

� No utilice el parámetro de importación PLANETYPE.

El método puede definirse como un método de instancia sin unparámetro de importación. Entonces este método accederá al atributode clase LIST_OF_PLANETYPES con ME->PLANETYPE.

� No utilice el método para nada

En el método display_attributes, podrá acceder al atributo de claseLIST_OF_PLANETYPES directamente con ME->PLANETYPE.

Tarea 3: (opcional)Cree y trate una excepción.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior.

Si la lectura del tipo de avión en el método GET_TECHNICAL_AT-TRIBUTES no se lleva a cabo con éxito (SY-SUBRC <> 0), debería crearsela excepción WRONG_PLANETYPE.

Para ello, utilice el suplemento EXCEPTION en el interface de método.

La excepción debería crearse o desencadenarse mediante el comando RAISE.

Nota: Probablemente conozca aún esta técnica clásica de tratamientode excepciones de usar módulos de funciones.

Más adelante en este curso, sustituiremos esta técnica clásica másantigua por una técnica moderna de tratamiento de excepcionesutilizando clases de excepción.

a) Solución modelo: SAPBC401_AIRS_MAIN_F

2. Si llama el método privado GET_TECHNICAL_ATTRIBUTES en elmétodo de llamada DISPLAY_ATTRIBUTES, esta excepción deberádeclararse mediante el suplemento EXCEPTIONS.

Si se produce una excepción en GET_TECHNICAL_ATTRIBUTES,podrá verificarlo utilizando el SY-SUBRC en el método de llamada (véaseconcepto conocido con módulos de funciones).

Continúa en la página siguiente

92 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 107: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

En este ejercicio, el uso de un tipo de avión incorrecto con SY-SUBRC <> 0,simplemente debería documentarse con una sentencia WRITE.

a) Consulte la solución modelo.

ResultadoCódigo fuente:

SAPBC401_AIRS_F

*&---------------------------------------------------------------------*

*& Include SAPBC401_AIRS_F *

*&---------------------------------------------------------------------*

*------------------------------------------------------------------*

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

CLASS lcl_airplane DEFINITION.

PUBLIC SECTION.

"--------------------------------

CONSTANTS: pos_1 TYPE i VALUE 30.

METHODS: constructor IMPORTING

im_name TYPE string

im_planetype TYPE saplane-planetype,

display_attributes.

CLASS-METHODS: display_n_o_airplanes.

CLASS-METHODS: class_constructor.

PRIVATE SECTION.

"----------------------------------

CLASS-METHODS: get_technical_attributes

IMPORTING im_type TYPE saplane-planetype

EXPORTING ex_weight TYPE s_plan_wei

ex_tankcap TYPE s_capacity

EXCEPTIONS wrong_planetype.

DATA: name TYPE string,

planetype TYPE saplane-planetype.

CLASS-DATA: list_of_planetypes TYPE ty_planetypes.

CLASS-DATA: n_o_airplanes TYPE i.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 93

Page 108: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

ENDCLASS. "lcl_airplane DEFINITION

*------------------------------------------------------------------*

* CLASS lcl_airplane IMPLEMENTATION *

*------------------------------------------------------------------*

CLASS lcl_airplane IMPLEMENTATION.

METHOD class_constructor.

SELECT * FROM saplane INTO TABLE list_of_planetypes.

ENDMETHOD. "class_constructor

METHOD constructor.

name = im_name.

planetype = im_planetype.

n_o_airplanes = n_o_airplanes + 1.

ENDMETHOD. "constructor

METHOD display_attributes.

DATA: weight TYPE saplane-weight,

cap TYPE saplane-tankcap.

get_technical_attributes(

EXPORTING im_type = planetype

IMPORTING ex_weight = weight

ex_tankcap = cap

EXCEPTIONS wrong_planetype = 4 ).

WRITE: / icon_ws_plane AS ICON,

/ ’Name of airplane’(001), AT pos_1 name,

/ ’Type of airplane:’(002), AT pos_1 planetype.

IF sy-subrc <> 0.

WRITE: / icon_failure AS ICON, ’WRONG_PLANETYPE’.

ELSE .

WRITE: / ’weight of airplane’(003),

AT pos_1 weight LEFT-JUSTIFIED,

/ ’tank capacity of airplane ’(004),

AT pos_1 cap LEFT-JUSTIFIED.

ENDIF.

ENDMETHOD. "display_attributes

Continúa en la página siguiente

94 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 109: TAW12_01

TAW12_1 Lección: Elementos sintácticos fundamentales orientados a objetos

METHOD display_n_o_airplanes.

WRITE: /, / ’Number of airplanes: ’(ca1),

AT pos_1 n_o_airplanes LEFT-JUSTIFIED, /.

ENDMETHOD. "display_n_o_airplanes

METHOD get_technical_attributes.

DATA: wa TYPE saplane.

READ TABLE list_of_planetypes INTO wa

WITH TABLE KEY planetype = im_type

TRANSPORTING weight tankcap.

IF sy-subrc = 0.

ex_weight = wa-weight.

ex_tankcap = wa-tankcap.

ELSE.

RAISE wrong_planetype.

ENDIF.

ENDMETHOD. "get_technical_attributes

ENDCLASS. "lcl_airplane IMPLEMENTATION

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 95

Page 110: TAW12_01

Capítulo 1: Introducción a la programación orientada a objetos TAW12_1

Resumen de la lección

Ahora podrá:� Definir clases� Generar y borrar objetos� Tener acceso a atributos� Llamar métodos

Más informaciónEncontrará más información acerca de este tema en la biblioteca SAP y en ladocumentación de palabras clave ABAP para las sentencias individuales.

96 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 111: TAW12_01

TAW12_1 Resumen del capítulo

Resumen del capítuloAhora podrá:� Explicar las diferencias entre modelos de programación procedimental y

orientados a objetos� Enumerar las ventajas del modelo de programación orientado a objetos� Nombrar los tipos de diagrama más importantes en UML� Crear diagramas de clases simples� Crear diagramas de objetos simples� Describir diagramas de secuencias� Definir clases� Generar y borrar objetos� Tener acceso a atributos� Llamar métodos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 97

Page 112: TAW12_01

Resumen del capítulo TAW12_1

98 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 113: TAW12_01

TAW12_1 Examine sus conocimientos

93Examine sus conocimientos

1. El modelo de programación orientado a objetos fue desarrolladoconsiderablemente más tarde que el de proceso. Ofrece más opciones parasolucionar problemas que no podían solucionarse antes con lenguajes deprogramación únicamente de proceso.

Diga si estas afirmaciones son correctas o falsas.□ Correcto□ Falso

2. ¿Qué significa instanciación múltiple?

3. ¿Qué significa encapsulación?

4. En los objetos ABAP, ¿qué se entiende por el término clase?

5. ¿Qué diferencia existe entre los componentes estáticos de una clase y suscomponentes de instancia?

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 99

Page 114: TAW12_01

Examine sus conocimientos TAW12_1

6. En los objetos ABAP, ¿qué se entiende por el término constructor?

7. Está definiendo una clase. ¿Debe definir siempre también un constructor?

100 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 115: TAW12_01

TAW12_1 Examine sus conocimientos

95Respuestas

1. El modelo de programación orientado a objetos fue desarrolladoconsiderablemente más tarde que el de proceso. Ofrece más opciones parasolucionar problemas que no podían solucionarse antes con lenguajes deprogramación únicamente de proceso.

Respuesta: Falso

Consultar la sección relevante de la unidad.

2. ¿Qué significa instanciación múltiple?

Respuesta: La capacidad de crear y gestionar cualquier número de instanciasen tiempo de ejecución para cada contexto de programa

Consultar la sección relevante de la unidad.

3. ¿Qué significa encapsulación?

Respuesta: El registro de datos y funciones en unidades reutilizables desdelas que los usuarios sólo pueden solicitar ciertas funciones y no puedenacceder a los datos directamente.

Consultar la sección relevante de la unidad.

4. En los objetos ABAP, ¿qué se entiende por el término clase?

Respuesta: Una clase es la descripción técnica de objetos idénticos. Puedecontener definiciones de atributo y método, y generalmente también puedeincluir las implementaciones de métodos.

Véase la sección relevante de la unidad

5. ¿Qué diferencia existe entre los componentes estáticos de una clase y suscomponentes de instancia?

Respuesta: Debe acceder a los componentes estáticos mediante la clase. Loscomponentes estáticos para cada programa y clase existen sólo una vez en lamemoria. Un objeto debe estar instanciado para tener acceso a ellos.Debe acceder a los componentes de instancia a través de los objetos de esteclase. En la memoria puede haber un número indeterminado de componentesde instancia por programa y clase.

Véase la sección relevante de la unidad.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 101

Page 116: TAW12_01

Examine sus conocimientos TAW12_1

6. En los objetos ABAP, ¿qué se entiende por el término constructor?

Respuesta: Un constructor de clase es un método especial y siempre sellama CONSTRUCTOR. Normalmente sólo se llama por parte del sistemade tiempo de ejecución cuando se crea un objeto de esta clase medianteCREATE OBJECT. Por ello, se le llama más concretamente constructorde instancia.

Véase la sección relevante de la unidad.

7. Está definiendo una clase. ¿Debe definir siempre también un constructor?

Respuesta: No.

Véase la sección relevante de la unidad.

102 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 117: TAW12_01

Capítulo 297 Conceptos orientados a objetos y

técnicas de programación

The idea behind Compass courses is that the individual lessons are not restrictedto a certain context. In this case, this means that participants should be ableto understand the lesson on interfaces without having covered the lesson oninheritance. To facilitate this, some information is repeated throughout the units,meaning that the second lesson can often be compressed into a few sentences.Except for the different syntax, interfaces are identical to abstract superclasses thathave exclusively public abstract methods.

Since the lessons are not dependent on a certain context, the essential content anddemonstrations have to be repeated. However, we suggest that you refer to regularinheritance for interfaces as often as possible throughout the whole course.

This serves to clarify the connection rather than to save time. This should make iteasier for participants to understand the concepts in question.

This lesson contains a lot of new material for participants, so you may see the firstsigns of irritation or waning interest. In such cases, point out that this unit dealswith general concepts of object-orientation. The knowledge gained can be veryuseful in other object-oriented languages as well.

Work with participants to deduce the purpose of every single concept anddetermine where they would use them. Occasionally, comparisons with theprocedural programming model can also help to create a clearer understanding.

The exercises are there to show that the material really is fairly simple. Onceparticipants realize that they do understand the course content, you might observethat motivation has increased � especially from those participants who wereanxious about the course.

Resumen del capítuloEsta unidad se centra en las técnicas de programación básicas comunes paratodos los lenguajes orientados a objetos. Por lo que se refiere a estos conceptos,la única diferencia entre los objetos ABAP y otros lenguajes como Java o C++es la sintaxis.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 103

Page 118: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Cada concepto existe por una razón específica. Es importante que los entiendatodos sin excepción, para poder utilizarlos de manera eficaz más adelante. Sólopodrá aprovechar las ventajas de la programación orientada a objetos si utilizatodos los conceptos de la forma adecuada.

Objetivos del capítuloAl finalizar este capítulo podrá:

� Definir relaciones de herencia entre clases� Redefinir métodos� Crear asignaciones up cast (widening cast)� Crear asignaciones down cast (narrowing cast)� Explicar el concepto de polimorfismo en relación con la herencia� Utilizar asignaciones cast con herencia para realizar llamadas genéricas� Definir e implementar interfaces� Implementar métodos de interface� Utilizar referencias de interface para realizar asignaciones up cast� Utilizar referencias de interface para realizar asignaciones down cast� Explicar el término polimorfismo en relación con interfaces� Utilizar asignaciones cast con interfaces para realizar llamadas genéricas� Definir y desencadenar eventos� Tratar eventos� Registrar y deregistrar el tratamiento de eventos� Explicar las diferencias clave entre llamadas de método explícitas y llamadas

de método controladas por evento

Contenido del capítuloLección: Herencia y casting ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105

Ejercicio 7: Jerarquías de clases.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127Ejercicio 8: Polimorfismo ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137Ejercicio 9: Agregación y llamadas genéricas .. . . . . . . . . . . . . . . . . . . . . . . . .141

Lección: Interfaces y casting .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149Ejercicio 10: Definición e implementación de interfaces .. . . . . . . . . . . . .167Ejercicio 11: Uso de interfaces ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185

Lección: Eventos.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192Ejercicio 12: Eventos en clases superiores ... . . . . . . . . . . . . . . . . . . . . . . . . . .201Ejercicio 13: Eventos en interfaces (opcional).. . . . . . . . . . . . . . . . . . . . . . . . .213

104 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 119: TAW12_01

TAW12_1 Lección: Herencia y casting

Lección:99

Herencia y castingDuración de la lección: 160 Minutos

Resumen de la lecciónEn esta unidad aprenderá a crear jerarquías de clases mediante objetos ABAP.El primer paso será programar los tipos de relación relevantes concebidosen el proceso de modelación. A continuación, aprenderá a identificar variasposibilidades de programación interesantes que ofrece la herencia.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Definir relaciones de herencia entre clases� Redefinir métodos� Crear asignaciones up cast (widening cast)� Crear asignaciones down cast (narrowing cast)� Explicar el concepto de polimorfismo en relación con la herencia� Utilizar asignaciones cast con herencia para realizar llamadas genéricas

The last part of this lesson is definitely the most important: Inheritance mustalways be used correctly. Inheritance relationships should not be defined betweensemantically unrelated classes simply to achieve technical advantages (suchas centralized maintenance, polymorphism, extensibility). Instead, inheritancemust always derive from a generalization/specialization relationship that wasrecognized as early as the modeling phase. This will allow you to benefit from theenhanced programming options.

As in the last lesson, the theory presented should be also be applied in a demoprogram. We also recommend that you start using the term signature at this pointor earlier in the course to refer to the parameters of a method. The term interfaceis used to mean several different things. Avoid using it as of the following lessonto avoid confusion.

Atención: When this course was revised, the use of the terms up-cast anddown-cast were changed and adapted to the current documentation. (Up-cast = Widening Cast and down-cast = Narrowing Cast)

Notify the participants of this at the end of the unit.

Ejemplo empresarialDesea implementar relaciones de generalización/especialización desde su modeloen objetos ABAP.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 105

Page 120: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Creación de relaciones de generalización/especial-ización mediante herenciaLa especialización (UML) es una relación en la que una clase (la subclase) heredatodas las características principales de otra clase (la clase superior). La subclasetambién puede añadir componentes nuevos (atributos, métodos, etc.) y sustituirlas implementaciones con métodos heredados. En el segundo caso, el nombre demétodo en el diagrama UML se renombra dentro de la subclase.

Gráfico 63: Ejemplo de generalización/especialización

The question of multiple inheritance might arise here: Multiple inheritance is notsupported in Java nor in ABAP Objects, however, it is supported in C++. Withthis, a class can inherit from several superclasses.

La especialización es una relación de implementación que destaca las similitudesde las clases. En el ejemplo anterior, las similitudes de las clases LCL_CAR,LCL_TRUCK y LCL_BUS se extraen a una clase superior, LCL_VEHICLE. Porlo tanto, los componentes que tienen en común se definen y se implementan sóloen la clase superior. También existen en todas las subclases.

La especialización se describe a menudo como una relación �es un�. En esteejemplo, se diría: �Un camión es un vehículo (específico).�

El punto de vista opuesto es la generalización.

106 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 121: TAW12_01

TAW12_1 Lección: Herencia y casting

Gráfico 64: Características de la generalización/especialización

La generalización/especialización, usada correctamente, ofrece una estructuraconsiderablemente mejor para el software, ya que los elementos utilizadoscon frecuencia sólo tienen que almacenarse una vez en una ubicación central(en la clase superior), y después están disponibles automáticamente para todaslas subclases. Los cambios realizados en una etapa posterior tienen un efectoinmediato en las subclases. Por lo tanto, no se debe alterar la semántica almodificar una clase superior.

Se requieren unos conocimientos precisos de la implementación de la clase superiorpara decidir si los componentes heredados de la clase superior son suficientes parala subclase o si deben ser ampliados. La generalización/especialización ofrece,por tanto, enlaces muy fuertes entre la clase superior y la subclase.

Al desarrollar subclases adicionales, a menuda también se debe adaptar la clasesuperior. Por lo tanto, la creación de una subclase conduce a veces a necesidadesadicionales para la clase superior, por ejemplo, cuando una subclase necesitaciertos componentes protegidos o cuando los detalles de una implementación declase superior son necesarios para cambiar las implementaciones de método ensubclases. El programador de una clase (superior) generalmente no puede prevertodo lo que las subclases necesitarán más tarde de la clase superior.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 107

Page 122: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 65: Herencia � Sintaxis

En objetos ABAP, una relación de herencia se define para una subclase utilizandoel suplemento INHERITING FROM, seguido de la clase superior que seencuentra directamente por encima de la subclase. Las jerarquías de herencia decomplejidad variada se producen cuando la clase superior hereda de otra clasesuperior por encima de ella. Por el contrario, no existe la herencia múltiple enobjetos ABAP. Es decir, sólo puede especificarse una clase superior directamentepor encima de una clase. Sin embargo, es posible utilizar interfaces en objetosABAP para simular la herencia múltiple.

La herencia debería utilizarse para implementar relaciones de generalización yespecialización. Una clase superior es una generalización de sus subclases. Lassubclases son, a su vez, diferentes especializaciones de su clase superior. Portanto, sólo se permiten suplementos o cambios en objetos ABAP, lo que significaque nunca se puede eliminar nada de una clase superior en una subclase.

La herencia es una relación unilateral. En otras palabras, las subclases reconocensus clases superiores directas, pero las clases (superiores) no reconocensus subclases. En este ejemplo, la subclase también contiene el métodoESTIMATE_FUEL. La subclase también define el método GET_CARGO.

108 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 123: TAW12_01

TAW12_1 Lección: Herencia y casting

Gráfico 66: Redefinición de métodos

La redefinición aparece cuando la implementación de un método de instanciaheredado se modifica para la subclase sin cambiar la firma. Al mismo tiempo, lasección de visibilidad de la clase superior debe mantenerse igual. (Por ello, laredefinición no es posible dentro de la PRIVATE SECTION.)

Si se utiliza el suplemento REDEFINITION, se deberá especificar una (nueva)parte de implementación para el método heredado. Dado que cabe la posibilidadde que la firma no haya cambiado, no es necesario definir de nuevo los parámetrosy excepciones de método.

Dentro de la parte de implementación de método redefinida, se puede utilizarel prefijo predefinido

super->... para acceder a los componentes en la clasesuperior que se encuentran directamente por encima del lugar en el que se estátrabajando. A menudo se deberá recurrir a ello cuando se desea redefinir unmétodo para que llame al método original de la clase superior.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 109

Page 124: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 67: Mantenimiento de la semántica durante la redefinición

En este ejemplo, ambos métodos redefinidos calculan el código de retorno dedistintas maneras. Lo importante es que la semántica del método se mantenga.

Gráfico 68: Definición del constructor en subclases

En la mayoría de los casos, una redefinición como se describe para los métodosde arriba no resulta útil en el caso del constructor. O bien el constructor de laclase superior puede utilizarse sin necesidad de cambiarlo, o bien la subclase seha ampliado y ahora se requieren otros parámetros en la firma del constructor.

110 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 125: TAW12_01

TAW12_1 Lección: Herencia y casting

En objetos ABAP, el constructor sólo puede �sobrescribirse� como parte de laherencia. Puede sobrescribirse en el sentido de que tanto la firma como la partede implementación pueden ajustarse en la subclase.

Consejo: En este contexto, el concepto de sobrecarga es relevante. Conla sobrecarga, un método tiene varias definiciones con distintas firmasy sus también distintas implementaciones. Esto no está soportado enobjetos ABAP.

El constructor de la clase superior directa debe ser llamado dentro del constructorde la subclase. Esto es así debido a la relación de especialización: si un constructorha sido definido en la clase superior, contendrá implementaciones que siemprese ejecutarán cuando se cree un objeto en esta clase superior o en sus subclases.Sin embargo, el sistema de tiempo de ejecución sólo lo podrá garantizar si elconstructor de la subclase no ha sido modificado. En la mayoría de los casos,el suministro de atributos privados consistentes desde la clase superior es otroprerequisito para llamar al constructor de la clase superior.

Al contrario que los constructores de instancias, el constructor estático de la clasesuperior es llamado automáticamente. Esto significa que el sistema de tiempo deejecución garantiza automáticamente que los constructores estáticos de todas susclases superiores ya se hayan ejecutado antes de que el constructor estático seejecute en una clase particular.

Gráfico 69: Reglas para llamar al constructor

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 111

Page 126: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Si una subclase no ha modificado su constructor de instancia, el constructor semantendrá sin modificaciones y la clase superior lo adoptará. Por lo tanto, laimplementación se ejecuta desde la clase superior.

Gráfico 70: Herencia y visibilidad

La herencia proporciona una ampliación del concepto de visibilidad: existencomponentes protegidos (PROTECTED SECTION). La visibilidad de estoscomponentes está entre la pública y la privada. Los componentes protegidos sonvisibles para todas las subclases y para la clase en sí misma.

Al definir clases locales en objetos ABAP, se deberá seguir la secuencia sintácticade PUBLIC SECTION, PROTECTED SECTION, PRIVATE SECTION.

112 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 127: TAW12_01

TAW12_1 Lección: Herencia y casting

Gráfico 71: Sección protegida frente a sección privada

El hecho de que todos los componentes de una clase superior estén disponiblespara la subclase no está relacionado con la visibilidad del componente. Unasubclase también recibe los componentes privados de su clase superior. Sinembargo, uno no puede dirigirse a ellos en la sintaxis de la subclase. Uno sólopuede dirigirse de manera indirecta a los componentes privados de las clasessuperiores mediante métodos públicos o protegidos desde la clase superior, que , asu vez, puede acceder a los atributos privados. Estas restricciones son necesariaspara garantizar que la actualización centralizada es posible.

En este ejemplo, es posible acceder al atributo protegido TANK en la clasesuperior LCL_VEHICLE directamente desde su subclase LCL_BUS. Por el otrolado, la única manera de acceder a los atributos MAKE y MODEL desde lassubclases de LCL_VEHICLE es utilizando métodos públicos.

Mediante la sección de visibilidad privada, es posible modificar clases superioressin necesidad de conocer las subclases. Siempre que los cambios realizados noafecten a la semántica, no será necesario adaptar las subclases. Esto es debido aque éstas sólo acceden indirectamente a los componentes privados de la clasesuperior.

Sólo existe un componente estático por contexto de programa. Resumiendo:

Componentes estáticos y herencia

� Una clase que define un atributo estático público o protegido comparte esteatributo con todas sus subclases.

� Los métodos estáticos no pueden redefinirse

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 113

Page 128: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Your demonstration program should now resemble the executable programSAPBC401_VEHD_MAIN_F.

Once again, remind participants of the benefit of these steps: Centralizedmaintenance of all general components of all vehicles!

At this point, we recommend having the participants do the first exercise of thislesson.

Up cast (widening cast)Las variables del tipo �referencia a clase superior� también pueden hacerreferencia a instancias de subclase en tiempo de ejecución.

114 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 129: TAW12_01

TAW12_1 Lección: Herencia y casting

Some relationships cannot be portrayed well in static diagrams. At this point, werecommend that you draw the following diagram by hand and hide the slides:

1. Draw the reference variable R_TRUCK (as an example) on the left.2. Write CREATE OBJECT r_truck ... above the reference variable.3. Draw the object display of a truck on the right and connect it to the reference

variable.4. Within this object, draw an area with a few inherited components.5. Draw another reference variable R_VEHICLE some distance below the

first one.6. Write R_VEHICLE = R_TRUCK above the second reference variable and

ask the participants to tell you the contents of the second reference variable.7. Now, it depends what you want to show with the diagram: From a technical

point of view, only an address is copied, so you can draw an arrow fromR_VEHICLE to the object.

You must ask which components are addressed with R_VEHICLE.

In contrast, in the following graphic we want to indicate the syntacticrestriction of the second reference variable. (The only reason why theinherited components can be accessed using the second variable is becausethe static type is critical for the syntax check.)

Gráfico 72: Up cast (widening cast) con referencias de objeto

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 115

Page 130: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Si se asigna una referencia de subclase a una referencia de clase superior, segarantizará que todos los componentes a los que se puede acceder sintácticamentedespués de la asignación cast están disponibles en la actualidad en la instancia. Lasubclase siempre contiene al menos los mismos componentes que la clase superior.Después de todo, el nombre y la firma de métodos redefinidos son idénticos.

Por lo tanto, el usuario sólo puede dirigirse a estos métodos y atributos desde lainstancia de subclase a la que pueden desde la instancia de clase superior.

Consejo: Con los métodos redefinidos, se debe tener en cuenta que laimplementación de la subclase se ejecuta mediante el tipo estático declase superior de referencia.

En este ejemplo, tras la asignación, los métodos GET_MAKE, GET_COUNT,DISPLAY_ATTRIBUTES, SET_ATTRIBUTES y ESTIMATE_FUEL de lainstancia LCL_TRUCK sólo pueden ser accedidos mediante la referenciaR_VEHICLE.

Si hay restricciones de visibilidad, no se modificarán. No es posible accedera los componentes específicos desde la clase LCL_TRUCK de la instancia(GET_CARGO en el ejemplo de arriba) mediante la referencia R_VEHICLE. Portanto, se suele restringir (o no se modifica) la vista o el posible acceso a métodos.Hay un cambio desde una vista de varios componentes a una vista de pocoscomponentes. Dado que la variable destino puede aceptar más tipos dinámicosen comparación con la variable fuente, esta asignación también se denominawidening cast

Gráfico 73: Tipos estáticos y dinámicos de referencias

116 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 131: TAW12_01

TAW12_1 Lección: Herencia y casting

Una variable de referencia siempre tiene dos tipos en tiempo de ejecución: estáticoy dinámico.

En el ejemplo, LCL_VEHICLE es el tipo estático de la variable R_VEHICLE.En función de la asignación cast, el tipo dinámico es LCL_BUS o LCL_TRUCK.En el ABAP Debugger, el tipo dinámico se especifica en la forma de la siguienterepresentación de objetos.

object_id<\PROGRAM=program_name\CLASS=dynamic_type>

Nota: Las asignaciones entre variables de referencia son posibles siempreque el tipo estático de las variables destino sea más general o equivalenteal tipo dinámico de las variables fuente.

Your demonstration program should now contain something that looks like theexecutable program SAPBC401_VEHICLE_MAIN_G. You should run yourprogram in debugging mode.

Nota: At this point, the main program is still the client of the vehicleclasses. This will change soon.

Remind participants of the benefits of narrowing cast assignments: It makes iteasy to extend the vehicle management with new specific vehicles.

At this point, we recommend having the participants do the second exercise ofthis lesson. Strictly speaking, the exercise assumes some knowledge that will notbe taught until the next paragraph, however this is unlikely to cause problemsas many participants have probably already programmed in the manner that isrequired here. For these participants, this exercise is obsolete in any case.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 117

Page 132: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 74: Acceso genérico después de asignaciones up cast

Un uso típico de asignaciones up cast es la preparación para el acceso genérico:Un usuario que no tiene ningún interés en los puntos concretos de las instancias delas subclases, y que simplemente quiere dirigirse a los componentes compartidos,puede utilizar una referencia de clase superior para este acceso.

En el ejemplo que se muestra aquí, una agencia de viajes (LCL_RENTAL) necesitagestionar todo tipo de vehículos en una lista. Esto nos conduce a la pregunta dequé tipo debería asignarse a la tabla interna para las referencias a instancias deavión. También se debe tener en cuenta que la compañía de vehículos de alquilerdebe poder calcular sólo la cantidad necesaria de combustible para todos susvehículos. De manera correspondiente, el método ESTIMATE_FUEL se define enla clase superior LCL_VEHICLE y se redefine en todas las subclases.

Gráfico 75: Tipo de línea de la tabla interna en el ejemplo de aplicación

118 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 133: TAW12_01

TAW12_1 Lección: Herencia y casting

Cuando los objetos de distintas clases (LCL_BUS, LCL_TRUCK y LCL_CARen el ejemplo superior) se especifican como referencias de clase superior de tipo(LCL_VEHICLE en el ejemplo superior), se pueden almacenar en una tablainterna. Así, se podrá acceder a los componentes compartidos de los objetos desubclase de forma uniforme. Para este ejemplo, el método ADD_VEHICLE espor tanto necesario. Éste copia las referencias a los tipos de vehículo en la tablainterna. Su parámetro de importación ya está tipificado como la referencia a laclase superior.

Gráfico 76: Up cast y acceso genérico en el ejemplo de aplicación

En este ejemplo, la asignación up cast sucede cuando la referencia del vehículose transfiere al parámetro formal del método ADD_VEHICLE. Genéricamentese accede al componente compartido dentro del loop de la tabla interna quecontiene todas las referencias de vehículo: El método ESTIMATE_FUEL ha sidoheredado de la clase superior LCL_VEHICLE y cabe la posibilidad de que sehaya redefinido.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 119

Page 134: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 77: Polimorfismo: Acceso genérico mediante la referencia de clasesuperior

La implementación que se ejecuta cuando se llama ahora ESTIMATE_FUELdepende de a qué objeto hace referencia en la actualidad la referencia se clasesuperior R_VEHICLE . Se utiliza el tipo dinámico y no el tipo estático de lavariable de referencia para buscar la implementación de un método. Por ello,cuando se llama r_vehicle->estimate_fuel, la implementación no seejecuta desde LCL_VEHICLE (tipo estático de R_VEHICLE), dado que elmétodo ha sido redefinido en todas las clases de vehículo.

Cuando una instancia recibe un mensaje para que ejecute un método concreto, seejecuta el método que implementó la clase de esta instancia. Si la clase no se haredefinido en el método, se ejecuta la implementación desde la clase superior.

Cuando los objetos de diferentes clases reaccionan de manera distinta a las mismasllamadas del método, hablamos de polimorfismo. La posibilidad de polimorfismoes uno de los puntos fuertes principales de la herencia: Un cliente puede tratardiferentes clases de manera uniforme, independientemente de su implementación.El sistema de tiempo de ejecución busca la implementación correcta de un métodocon la ayuda del cliente.

El polimorfismo puede utilizarse para escribir programas altamente genéricos, esdecir, que no necesitan cambiarse de manera significativa si se añaden casos deuso. Por ejemplo, de esta manera resulta muy fácil añadir motocicletas a esteejemplo: Sólo es necesario definir una nueva subclase de LCL_VEHICLE, quese podría denominar LCL_MOTORBIKE. También se debe redefinir el métodoheredado ESTIMATE_FUEL. Sin necesidad de realizar más cambios, el sistemade gestión de vehículos podrá trabajar también con motocicletas y calcular losniveles de combustible necesarios para ellas.

120 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 135: TAW12_01

TAW12_1 Lección: Herencia y casting

Gráfico 78: Llamadas genéricas en el modelo de programaciónprocedimental

Mediante el uso de módulos de funciones dinámicos, es posible programar demanera genérica en objetos ABAP, incluso sin un modelo de programaciónorientado a objetos. En comparación con el polimorfismo a través de la herencia,esto significa que el código fuente es menos autoexplicativo y más susceptiblea errores. Por ejemplo, la verificación de sintaxis sólo puede comprobar que elmodelo de función se llama correctamente, pero no si la tabla interna contiene unnombre de módulo de funciones válido para cada vehículo.

Your demonstration program should now look somewhat like the executableprogram SAPBC401_VEHICLE_MAIN_H.

At this point, we recommend having the participants do the third exercise of thislesson.

Down cast (narrowing cast)Las variables del tipo �referencia a clase superior� también pueden hacer referenciaa instancias de subclase en tiempo de ejecución. Ahora es posible que desee copiaresta referencia a una variable adecuada del tipo �referencia a subclase�.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 121

Page 136: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

At this point, we recommend that you add to your up-cast diagram and hide theslides:

1. Draw another reference variable called R_TRUCK2 under R_VEHICLE.2. Write R_TRUCK2 ?= R_VEHICLE above the third reference variable and

discuss with the participants the need to use �?�. Then ask the participantswhat the content of the third reference variable is.

3. Draw an arrow from R_TRUCK2 to the object.

You must ask which components can be addressed with R_TRUCK2.

Gráfico 79: Down cast (narrowing cast) con referencias de objeto

Si se desea asignar una referencia de clase superior a una referencia de subclase,se deberá utilizar el operador de asignación down cast

MOVE ... ?TO ... o su forma corta?=

. Sino, se obtendrá un mensaje indicando que no es seguro quetodos los componentes a los que se puede acceder sintácticamente después de laasignación cast estén disponibles en la actualidad en la instancia. Como regla, laclase de subclase contiene más componentes que la clase superior.

Después de asignar este tipo de referencia (de vuelta) a una referencia de subclasede la clase de implementación, los clientes ya no estarán limitados a componentesheredados: en el ejemplo expuesto aquí, puede accederse (de nuevo) a todos loscomponentes de la instancia LCL_TRUCK después de la asignación mediante lareferencia R_TRUCK2.

122 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 137: TAW12_01

TAW12_1 Lección: Herencia y casting

Así, la vista suele estar ampliada (o, al menos, no está modificada). Este tipo deasignación de variables de referencia es conocido como down cast. Existe uncambio de una vista de algunos componentes a una vista de más componentes.Dado que la variable destino puede aceptar menos tipos dinámicos después de laasignación, esta asignación también se denomina narrowing cast

Gráfico 80: Acceso específico después de asignaciones down cast

Un uso típico de las asignaciones down cast es cuando es necesario dirigirse acomponentes específicos de instancias y sus referencias se mantienen en variablesque se introducen en la clase superior.. Un usuario que tiene interés en los puntosconcretos de las instancias de una subclase no puede utilizar la referencia declase superior para este acceso porque sólo permite el acceso a los componentescompartidos.

En este ejemplo, una compañía de vehículos de alquiler (LCL_RENTAL) deseadeterminar la capacidad máxima de sus camiones, pero almacena todos los tiposde referencias de vehículo en una tabla interna tipificada como LCL_VEHICLE.Por lo tanto, ¿qué pasa si no hay ninguna referencia de camión en la referencia declase superior R_VEHICLE en tiempo de ejecución pero el operador de asignacióndown cast intenta copiar la referencia a la referencia ahora no válida R_TRUCK?

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 123

Page 138: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 81: Down cast y tratamiento de excepciones en el ejemplo deaplicación

Al contrario que la asignación up cast, es posible que el tipo estático de lavariable destino (R_TRUCK) no sea ni más general ni igual que el tipo dinámicode la variable fuente (R_VEHICLE), es decir, cuando R_VEHICLE contienereferencias de bus o de coche deportivo. Ésta es la razón por la que, con esta clasede cast, el sistema de tiempo de ejecución verifica, antes de la asignación, si elcontenido actual de la variable fuente se corresponde con los requisitos de tipo dela variable destino. Si no es así, se lanzará una excepción que puede tratarse, y elvalor original de la variable destino seguirá siendo el mismo.

Esta excepción de la clase de error CX_SY_MOVE_CAST_ERROR puedeidentificarse mediante TRY-ENDTRY y la sentencia CATCH. Otra manera deprevenir este error de tiempo de ejecución sería utilizar clases de identificaciónde tipo de tiempo de ejecución (RTTI). Pueden utilizarse para determinar el tipodinámico en el tiempo de ejecución y para fijar una condición para el cast.

We recommend you do a separate demonstration to show thenecessity of identifying the exception. You can use the programSAPBC401_VEHICLE_MAIN_I as the copy template for this.

Nota: You must refer to the specific lesson about the exception concept.You do not have enough time to discuss this topic now!

124 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 139: TAW12_01

TAW12_1 Lección: Herencia y casting

You can insert the optional exercise on the down-cast at this point. However, youmust provide a precise description of the tasks involved.

Atención: Please note the change in the use of the terms Narrowing Castand Widening Cast In older versions of the course, the terms were usedin the exact opposite way!

Although fewer classes can be addressed using the target reference after a downcast, more attributes or methods are available or can be seen using the targetreference. For this reason, both terms are actually always correct: widening castand narrowing cast. It depends on the point of view!

Entrada de jerarquías de clasesEsta sección final no examina si la herencia debería utilizarse como una técnicade programación entre un número de alternativas. Desde la fase de modelación,debería ser capaz de ver si existe una relación de generalización/especializaciónentre ciertas clases. Si existe, se puede utilizar la herencia para representarlaen objetos ABAP.

Gráfico 82: Entrada de jerarquías de clases

Si éste es el caso, debe ceñirse a los conceptos relevantes de herencia. Por ejemplo,la semántica debe mantenerse al redefinir métodos. Además, los componentesheredados deben utilizarse según la manera prevista en la clase superior.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 125

Page 140: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 83: Ejemplos: Mal uso de la herencia

Si no entiende correctamente la formulación �es un (específico)�, correrá elriesgo de identificar los lugares erróneos donde utilizar la herencia. A veces, lanecesidad de otro atributo para una clase se responde de manera incorrecta conuna especialización.

Ejemplo: Una clase superior llamada Coche contiene las subclases Coche rojo,Coche azul, etc. La sentencia �Un coche rojo es un coche específico� sólo escorrecta a primera vista. Sin embargo, no hay coches sin color. Como mucho,hay algunos coches que no se han pintado. Por ello, todos los coches necesitanel atributo Color, asumiendo que es relevante para la aplicación. Por lo tanto,el atributo ya debería haberse definido en la clase superior, o ya no existe unaautorización para subclases de este tipo. También habría contradicciones con larealidad si se intenta implementar un método para pintar los coches.

Nota: Estos atributos también se definen a menudo como variables dereferencia a una clase superior de clases de rol. Hay una descripción declase para cada rol. Para modificar el rol de una instancia, se deberánintercambiar las referencias a las instancias de descripción de rolcorrespondientes. La bibliografía específica también se refiere a ellocomo �patrón de diseño de rol�.

En algunos casos, se identifican relaciones de especialización que no permitenque se conserve la semántica.

Ejemplo: La clase Cuadrado hereda de la clase Rectángulo. Si se intentan definirmétodos para el rectángulo que modifiquen el ancho y la altura por separado,estos métodos no tendrán sentido cuando se apliquen al cuadrado. Incluso silos métodos se redefinieron para que la longitud de los lados fuera uniforme,la semántica sería diferente.

Por las mismas razones, tampoco es posible usar la herencia simple del textofuente, es decir, la herencia sólo se utiliza porque existen algunas funcionesrequeridas en una clase (superior).

126 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 141: TAW12_01

TAW12_1 Lección: Herencia y casting

119 Ejercicio 7: Jerarquías de clasesDuración del ejercicio: 60 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Definir subclases� Redefinir métodos de clase superior en subclases� Utilizar de manera efectiva secciones de visibilidad

Ejemplo empresarialSu programa de gestión de aviones debe redefinirse más detalladamente.Relacione aviones específicos con su clase general de avión.

Tarea 1:En la clase LCL_AIRPLANE, defina la subclase local LCL_PASSEN-GER_PLANE para aviones de pasajeros.

1. Complete el programa ZBC401_##_MAIN (donde ## es el número de grupode dos cifras) o copie el programa SAPBC401_CASS_MAIN_E.

Si es aplicable, introduzca el código fuente para su nueva clase en elprograma de Include.

2. La clase debe tener un atributo de instancia privado, MAX_SEATS, con elmismo tipo que el campo de tabla SFLIGHT-SEATSMAX.

3. Defina e implemente un constructor de instancia que asigne valores a todoslos atributos de instancia de la clase.

4. Redefina DISPLAY_ATTRIBUTES de manera que se visualicen todos losatributos de instancia mediante la sentencia WRITE.

Tarea 2:En la clase LCL_AIRPLANE, defina la subclase local LCL_CARGO_PLANEpara aviones de carga.

1. La clase debe tener un atributo de instancia privado, MAX_CARGO, con elmismo tipo que el campo de tabla SCPLANE-CARGOMAX.

2. Defina e implemente un constructor de instancia que asigne valores a todoslos atributos de instancia de la clase.

3. Redefina DISPLAY_ATTRIBUTES de manera que se visualicen todos losatributos de instancia mediante la sentencia WRITE.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 127

Page 142: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

4. Defina el método funcional GET_CARGO para devolver el valor de carga alprograma de llamada. Utilice el parámetro de fórmula RE_CARGO.

Tarea 3:Cree instancias de sus nuevas clases y visualice sus atributos.

1. En el programa principal, defina una variable de referencia tipificadacorrectamente para cada una de sus clases nuevas.

2. Llame el método estático DISPLAY_N_O_AIRPLANES (antes de instanciarcualquier objeto).

3. Utilice las dos referencias para crear una instancia de cada una de lassubclases LCL_PASSENGER_PLANE y LCL_CARGO_PLANE. Decidacómo rellenar los atributos.

4. Llame el método DISPLAY_ATTRIBUTES para ambas instancias.

5. Llame el método estático DISPLAY_ATTRIBUTES una segunda vez.

Tarea 4:Analice su programa.

1. Observe el flujo de programa en el ABAP Debugger, prestando una especialatención a la llamada del método DISPLAY_ATTRIBUTES.

2. ¿Podría llamarse el método GET_TECHNICAL_ATTRIBUTESdirectamente desde el método redefinido DISPLAY_ATTRIBUTES delas subclases?

128 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 143: TAW12_01

TAW12_1 Lección: Herencia y casting

Solución 7: Jerarquías de clasesTarea 1:En la clase LCL_AIRPLANE, defina la subclase local LCL_PASSEN-GER_PLANE para aviones de pasajeros.

1. Complete el programa ZBC401_##_MAIN (donde ## es el número de grupode dos cifras) o copie el programa SAPBC401_CASS_MAIN_E.

Si es aplicable, introduzca el código fuente para su nueva clase en elprograma de Include.

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

b) Solución modelo: SAPBC401_INHS_MAIN_A

2. La clase debe tener un atributo de instancia privado, MAX_SEATS, con elmismo tipo que el campo de tabla SFLIGHT-SEATSMAX.

a) Véase la solución modelo.

3. Defina e implemente un constructor de instancia que asigne valores a todoslos atributos de instancia de la clase.

a) Véase la solución modelo.

4. Redefina DISPLAY_ATTRIBUTES de manera que se visualicen todos losatributos de instancia mediante la sentencia WRITE.

a) Véase la solución modelo.

Tarea 2:En la clase LCL_AIRPLANE, defina la subclase local LCL_CARGO_PLANEpara aviones de carga.

1. La clase debe tener un atributo de instancia privado, MAX_CARGO, con elmismo tipo que el campo de tabla SCPLANE-CARGOMAX.

a) Véase la solución modelo.

2. Defina e implemente un constructor de instancia que asigne valores a todoslos atributos de instancia de la clase.

a) Véase la solución modelo.

3. Redefina DISPLAY_ATTRIBUTES de manera que se visualicen todos losatributos de instancia mediante la sentencia WRITE.

a) Véase la solución modelo.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 129

Page 144: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

4. Defina el método funcional GET_CARGO para devolver el valor de carga alprograma de llamada. Utilice el parámetro de fórmula RE_CARGO.

a) Véase la solución modelo.

Tarea 3:Cree instancias de sus nuevas clases y visualice sus atributos.

1. En el programa principal, defina una variable de referencia tipificadacorrectamente para cada una de sus clases nuevas.

a) Véase la solución modelo.

2. Llame el método estático DISPLAY_N_O_AIRPLANES (antes de instanciarcualquier objeto).

a) Véase la solución modelo.

3. Utilice las dos referencias para crear una instancia de cada una de lassubclases LCL_PASSENGER_PLANE y LCL_CARGO_PLANE. Decidacómo rellenar los atributos.

a) Véase la solución modelo.

4. Llame el método DISPLAY_ATTRIBUTES para ambas instancias.

a) Véase la solución modelo.

5. Llame el método estático DISPLAY_ATTRIBUTES una segunda vez.

a) Véase la solución modelo.

Tarea 4:Analice su programa.

1. Observe el flujo de programa en el ABAP Debugger, prestando una especialatención a la llamada del método DISPLAY_ATTRIBUTES.

a) Lleve a cabo este paso de la manera habitual.

2. ¿Podría llamarse el método GET_TECHNICAL_ATTRIBUTESdirectamente desde el método redefinido DISPLAY_ATTRIBUTES delas subclases?

Respuesta: No, porque el componente de la clase superior es privado.

ResultadoSolución modelo:

Continúa en la página siguiente

130 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 145: TAW12_01

TAW12_1 Lección: Herencia y casting

SAPBC401_INHS_MAIN_A

REPORT sapbc401_inhs_main_a.

TYPE-POOLS icon.

INCLUDE sapbc401_inhs_a.

DATA: r_plane TYPE REF TO lcl_airplane.

r_cargo TYPE REF TO lcl_cargo_plane,

r_passenger TYPE REF TO lcl_passenger_plane,

plane_list TYPE TABLE OF REF TO lcl_airplane.

START-OF-SELECTION.

*##############################

lcl_airplane=>display_n_o_airplanes( ).

CREATE OBJECT r_passenger EXPORTING

im_name = ’LH BERLIN’

im_planetype = ’747-400’

im_seats = 345.

CREATE OBJECT r_cargo EXPORTING

im_name = ’US Hercules’

im_planetype = ’747-500’

im_cargo = 533.

r_cargo->display_attributes( ).

r_passenger->display_attributes( ).

lcl_airplane=>display_n_o_airplanes( ).

SAPBC401_INHS_A

*&---------------------------------------------------------------------*

*& Include SAPBC401_INHS_A *

*&---------------------------------------------------------------------*

*------------------------------------------------------------------*

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 131

Page 146: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

CLASS lcl_airplane DEFINITION.

PUBLIC SECTION.

"--------------------------------

CONSTANTS: pos_1 TYPE i VALUE 30.

METHODS: constructor IMPORTING

im_name TYPE string

im_planetype TYPE saplane-planetype,

display_attributes.

CLASS-METHODS: display_n_o_airplanes.

PRIVATE SECTION.

"----------------------------------

METHODS: get_technical_attributes

IMPORTING im_type TYPE saplane-planetype

EXPORTING ex_weight TYPE s_plan_wei

ex_tankcap TYPE s_capacity

DATA: name TYPE string,

planetype TYPE saplane-planetype.

CLASS-DATA: n_o_airplanes TYPE i.

ENDCLASS. "lcl_airplane DEFINITION

*------------------------------------------------------------------*

* CLASS lcl_airplane IMPLEMENTATION *

*------------------------------------------------------------------*

CLASS lcl_airplane IMPLEMENTATION.

METHOD constructor.

name = im_name.

planetype = im_planetype.

n_o_airplanes = n_o_airplanes + 1.

ENDMETHOD. "constructor

METHOD display_attributes.

DATA: weight TYPE saplane-weight,

cap TYPE saplane-tankcap.

WRITE: / icon_ws_plane AS ICON,

/ ’Name of airplane’(001), AT pos_1 name,

Continúa en la página siguiente

132 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 147: TAW12_01

TAW12_1 Lección: Herencia y casting

/ ’Airplane type: ’(002), AT pos_1 planetype.

get_technical_attributes( EXPORTING im_type = planetype

IMPORTING ex_weight = weight

ex_tankcap = cap ).

WRITE: / ’Weight:’(003), weight,

’Tank capacity:’(004), cap.

ENDMETHOD. "display_attributes

METHOD display_n_o_airplanes.

WRITE: /, / ’Number of airplanes: ’(ca1),

AT pos_1 n_o_airplanes LEFT-JUSTIFIED, /.

ENDMETHOD. "display_n_o_airplanes

METHOD get_technical_attributes.

SELECT SINGLE weight tankcap FROM saplane

INTO (ex_weight, ex_tankcap)

WHERE planetype = im_type.

IF sy-subrc <> 0.

ex_weight = 100000.

ex_tankcap = 10000.

ENDIF.

ENDMETHOD. "get_technical_attributes

ENDCLASS. "lcl_airplane IMPLEMENTATION

*---------------------------------------------------------------------*

* CLASS lcl_cargo_plane DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_cargo_plane DEFINITION INHERITING FROM lcl_airplane.

PUBLIC SECTION.

"----------------------

METHODS: constructor IMPORTING im_name TYPE string

im_planetype TYPE saplane-planetype

im_cargo TYPE scplane-cargomax.

METHODS: display_attributes REDEFINITION.

METHODS: get_cargo RETURNING VALUE(re_cargo) TYPE scplane-cargomax.

PRIVATE SECTION.

"----------------------

DATA: max_cargo TYPE scplane-cargomax.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 133

Page 148: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

ENDCLASS. "lcl_cargo_plane DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_cargo_plane IMPLEMENTATION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_cargo_plane IMPLEMENTATION.

METHOD constructor.

CALL METHOD super->constructor( im_name = im_name

im_planetype = im_planetype ).

max_cargo = im_cargo.

ENDMETHOD. "constructor

METHOD display_attributes.

super->display_attributes( ).

WRITE: / ’Max Cargo = ’, max_cargo.

ULINE.

ENDMETHOD. "display_attributes

METHOD get_cargo.

re_cargo = max_cargo.

ENDMETHOD. "get_cargo

ENDCLASS. "lcl_cargo_plane IMPLEMENTATION

*---------------------------------------------------------------------*

* CLASS lcl_passenger_plane DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_passenger_plane DEFINITION INHERITING FROM lcl_airplane..

PUBLIC SECTION.

METHODS: constructor IMPORTING im_name TYPE string

im_planetype TYPE saplane-planetype

im_seats TYPE sflight-seatsmax.

METHODS: display_attributes REDEFINITION.

PRIVATE SECTION.

DATA: max_seats TYPE sflight-seatsmax.

ENDCLASS. "lcl_passenger_plane DEFINITION

Continúa en la página siguiente

134 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 149: TAW12_01

TAW12_1 Lección: Herencia y casting

*---------------------------------------------------------------------*

* CLASS lcl_passenger_plane IMPLEMENTATION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_passenger_plane IMPLEMENTATION.

METHOD constructor.

CALL METHOD super->constructor( EXPORTING im_name = im_name

im_planetype = im_planetype ).

max_seats = im_seats.

ENDMETHOD. "constructor

METHOD display_attributes.

super->display_attributes( ).

WRITE: / ’Max Seats = ’, max_seats.

ULINE.

ENDMETHOD. "display_attributes

ENDCLASS. "lcl_passenger_plane IMPLEMENTATION

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 135

Page 150: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

136 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 151: TAW12_01

TAW12_1 Lección: Herencia y casting

129 Ejercicio 8: PolimorfismoDuración del ejercicio: 20 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Asignaciones de casting de programa� Utilizar relaciones de herencia para llamadas de método polimórficas

Ejemplo empresarialSu programa de gestión de aviones debería visualizar los atributos de los objetosde avión de manera genérica, es decir, debería estar abierto a futuras ampliacionescon clases de avión adicionales.

Tarea 1:Grabe las referencias de avión en memoria intermedia en un tipo adecuado detabla interna.

1. Complete el programa ZBC401_##_MAIN o copie la solución de muestradel ejercicio anterior. (## es el número de grupo de dos cifras).

2. En el programa principal, defina una tabla interna para grabar en memoriaintermedia referencias de avión, si es que aún no tiene una. El tipo de líneade la tabla interna debería ser REF TO LCL_AIRPLANE.

Tarea 2:Visualice los atributos de todos los tipos de avión que se han creado hasta ahora.

1. Inserte las referencias a los aviones de pasajeros y de carga en la tabla interna.

2. Programe un loop a través de los contenidos de la tabla interna. Llame elmétodo DISPLAY_ATTRIBUTES cada vez que se ejecute el loop.

Tarea 3:Analice el programa.

1. Siga el flujo de programa en el ABAP Debugger, prestando una especialatención a la llamada del método DISPLAY_ATTRIBUTES.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 137

Page 152: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

2. ¿Qué pasaría si el método DISPLAY_ATTRIBUTES no hubiera sidoredefinido en las subclases?

138 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 153: TAW12_01

TAW12_1 Lección: Herencia y casting

Solución 8: PolimorfismoTarea 1:Grabe las referencias de avión en memoria intermedia en un tipo adecuado detabla interna.

1. Complete el programa ZBC401_##_MAIN o copie la solución de muestradel ejercicio anterior. (## es el número de grupo de dos cifras).

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

b) Solución modelo: SAPBC401_CASS_MAIN_A

2. En el programa principal, defina una tabla interna para grabar en memoriaintermedia referencias de avión, si es que aún no tiene una. El tipo de líneade la tabla interna debería ser REF TO LCL_AIRPLANE.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 2:Visualice los atributos de todos los tipos de avión que se han creado hasta ahora.

1. Inserte las referencias a los aviones de pasajeros y de carga en la tabla interna.

a) Véase el extracto del código fuente de la solución modelo.

2. Programe un loop a través de los contenidos de la tabla interna. Llame elmétodo DISPLAY_ATTRIBUTES cada vez que se ejecute el loop.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 3:Analice el programa.

1. Siga el flujo de programa en el ABAP Debugger, prestando una especialatención a la llamada del método DISPLAY_ATTRIBUTES.

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

2. ¿Qué pasaría si el método DISPLAY_ATTRIBUTES no hubiera sidoredefinido en las subclases?

Respuesta: La implementación se ejecutaría desde la clase superior. Suprograma no tendría polimorfismo.

ResultadoCódigo fuente:

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 139

Page 154: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

SAPBC401_CASS_MAIN_A

REPORT sapbc401_cass_main_a.

TYPE-POOLS icon.

INCLUDE sapbc401_inhs_a.

DATA: r_plane TYPE REF TO lcl_airplane,

r_cargo TYPE REF TO lcl_cargo_plane,

r_passenger TYPE REF TO lcl_passenger_plane,

plane_list TYPE TABLE OF REF TO lcl_airplane.

START-OF-SELECTION.

*##############################

lcl_airplane=>display_n_o_airplanes( ).

CREATE OBJECT r_passenger EXPORTING

im_name = ’LH BERLIN’

im_planetype = ’747-400’

im_seats = 345.

APPEND r_passenger TO plane_list.

CREATE OBJECT r_cargo EXPORTING

im_name = ’US HErcules’

im_planetype = ’747-500’

im_cargo = 533.

APPEND r_cargo TO plane_list.

LOOP AT plane_list INTO r_plane.

r_plane->display_attributes( ).

ENDLOOP.

lcl_airplane=>display_n_o_airplanes( ).

140 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 155: TAW12_01

TAW12_1 Lección: Herencia y casting

133 Ejercicio 9: Agregación y llamadasgenéricasDuración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Implementar relaciones de agregación entre clases� Asignaciones de casting de programa� Utilizar relaciones de herencia para llamadas de método polimórficas

Ejemplo empresarialAhora, la gestión de instancias de avión ya no debería realizarse en el programaprincipal. En lugar de eso, debería encapsularse en una nueva clase paracompañías aéreas.

Tarea 1:Defina una clase local para compañías aéreas.

1. Desde el programa de Include SAPBC401_CAST_B, copie las partes deltexto fuente para la clase local LCL_CARRIER en su programa de IncludeZBC401_##_AIRPLANE, de manera que pueda añadirlas allí. (## es elnúmero de grupo de dos cifras). )

2. Amplíe la firma y la implementación del método ADD_AIRPLANE demanera que las referencias de avión puedan añadirse en la lista previamentedefinida AIRPLANE_LIST.

3. Amplíe la implementación del método DISPLAY_AIRPLANES de maneraque los atributos de todos los aviones de la compañía aérea puedan añadirseen la lista. Cada vez que se añade un avión, debería llamarse su métodoDISPLAY_ATTRIBUTES.

4. Amplíe la implementación del método DISPLAY_ATTRIBUTES de maneraque todos los atributos de la compañía aérea puedan visualizarse y, porconsiguiente, también puedan visualizarse los contenidos de la lista deaviones.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 141

Page 156: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Tarea 2:En el programa principal, cree una instancia de línea aérea. Transfiérale algunasreferencias de avión y visualice los atributos.

1. Elimine todas las sentencias del programa principal que definen la tablainterna global de referencias de avión y sus inserciones.

2. En el programa principal, defina una variable de referencia tipificadacorrectamente para su nueva clase de compañía aérea.

3. Mediante la referencia, genere una instancia de la clase LCL_CARRIER.Decida cómo rellenar los atributos.

4. Llame el método ADD_AIRPLANE para transferir las instancias de aviónque se han creado hasta ahora para la compañía aérea. También puede creary transferir aviones adicionales.

5. Visualice los atributos de la compañía aérea llamando su métodoDISPLAY_ATTRIBUTES.

Tarea 3:Ejercicio opcional: Determinación del valor de carga máxima.

1. Defina e implemente el método funcional GET_HIGHEST_CARGO en laclase LCL_CARRIER para calcular el valor de carga máxima (capacidadde carga) de todos los aviones de carga. Utilice la técnica down cast paraidentificar todos los aviones relevantes para esta tarea.

2. Con fines de test, este nuevo método puede llamarse dentro deDISPLAY_ATTRIBUTES de la clase LCL_CARRIER.

142 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 157: TAW12_01

TAW12_1 Lección: Herencia y casting

Solución 9: Agregación y llamadasgenéricasTarea 1:Defina una clase local para compañías aéreas.

1. Desde el programa de Include SAPBC401_CAST_B, copie las partes deltexto fuente para la clase local LCL_CARRIER en su programa de IncludeZBC401_##_AIRPLANE, de manera que pueda añadirlas allí. (## es elnúmero de grupo de dos cifras). )

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

b) Solución modelo: SAPBC401_CASS_MAIN_B

2. Amplíe la firma y la implementación del método ADD_AIRPLANE demanera que las referencias de avión puedan añadirse en la lista previamentedefinida AIRPLANE_LIST.

a) Véase el extracto del código fuente de la solución modelo.

3. Amplíe la implementación del método DISPLAY_AIRPLANES de maneraque los atributos de todos los aviones de la compañía aérea puedan añadirseen la lista. Cada vez que se añade un avión, debería llamarse su métodoDISPLAY_ATTRIBUTES.

a) Véase el extracto del código fuente de la solución modelo.

4. Amplíe la implementación del método DISPLAY_ATTRIBUTES de maneraque todos los atributos de la compañía aérea puedan visualizarse y, porconsiguiente, también puedan visualizarse los contenidos de la lista deaviones.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 2:En el programa principal, cree una instancia de línea aérea. Transfiérale algunasreferencias de avión y visualice los atributos.

1. Elimine todas las sentencias del programa principal que definen la tablainterna global de referencias de avión y sus inserciones.

a) Véase el extracto del código fuente de la solución modelo.

2. En el programa principal, defina una variable de referencia tipificadacorrectamente para su nueva clase de compañía aérea.

a) Véase el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 143

Page 158: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

3. Mediante la referencia, genere una instancia de la clase LCL_CARRIER.Decida cómo rellenar los atributos.

a) Véase el extracto del código fuente de la solución modelo.

4. Llame el método ADD_AIRPLANE para transferir las instancias de aviónque se han creado hasta ahora para la compañía aérea. También puede creary transferir aviones adicionales.

a) Véase el extracto del código fuente de la solución modelo.

5. Visualice los atributos de la compañía aérea llamando su métodoDISPLAY_ATTRIBUTES.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 3:Ejercicio opcional: Determinación del valor de carga máxima.

1. Defina e implemente el método funcional GET_HIGHEST_CARGO en laclase LCL_CARRIER para calcular el valor de carga máxima (capacidadde carga) de todos los aviones de carga. Utilice la técnica down cast paraidentificar todos los aviones relevantes para esta tarea.

a) Véase la solución modelo.

2. Con fines de test, este nuevo método puede llamarse dentro deDISPLAY_ATTRIBUTES de la clase LCL_CARRIER.

a) Véase la solución modelo.

ResultadoExtracto del código fuente:

SAPBC401_CASS_MAIN_C

REPORT sapbc401_cass_main_c.

TYPE-POOLS icon.

INCLUDE sapbc401_cass_c.

DATA: r_plane TYPE REF TO lcl_airplane,

r_cargo TYPE REF TO lcl_cargo_plane,

r_passenger TYPE REF TO lcl_passenger_plane,

r_carrier TYPE REF TO lcl_carrier.

Continúa en la página siguiente

144 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 159: TAW12_01

TAW12_1 Lección: Herencia y casting

START-OF-SELECTION.

*##############################

***** Create Carrier ********************************************

CREATE OBJECT r_carrier EXPORTING im_name = ’Smile&Fly Travel’.

***** Passenger Plane ********************************************

CREATE OBJECT r_passenger EXPORTING

im_name = ’LH BERLIN’

im_planetype = ’747-400’

im_seats = 345.

***** cargo Plane ************************************************

CREATE OBJECT r_cargo EXPORTING

im_name = ’US HErcules’

im_planetype = ’747-500’

im_cargo = 533.

***** insert planes into itab if client ***************************

r_carrier->add_airplane( r_passenger ).

r_carrier->add_airplane( r_cargo ).

***** show all airplanes inside carrier ***************************

r_carrier->display_attributes( ).

SAPBC401_CASS_C

*&---------------------------------------------------------------------*

*& Include SAPBC401_CASS_C *

*&---------------------------------------------------------------------*

*------------------------------------------------------------------*

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_carrier DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_carrier DEFINITION.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 145

Page 160: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

PUBLIC SECTION.

"----------------------------------------

METHODS: constructor IMPORTING im_name TYPE string,

get_name RETURNING value(ex_name) TYPE string,

add_airplane IMPORTING

im_plane TYPE REF TO lcl_airplane,

display_airplanes,

display_attributes,

get_highest_cargo RETURNING value(re_cargo)

TYPE s_plan_car.

PRIVATE SECTION.

"-----------------------------------

DATA: name TYPE string,

airplane_list TYPE TABLE OF REF TO lcl_airplane.

ENDCLASS. "lcl_carrier DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_carrier IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_carrier IMPLEMENTATION.

METHOD add_airplane.

APPEND im_plane TO airplane_list.

ENDMETHOD. "add_airplane

METHOD display_attributes.

DATA: highest_cargo TYPE s_plan_car.

WRITE: icon_flight AS ICON, name . ULINE. ULINE.

display_airplanes( ).

highest_cargo = ME->get_highest_cargo( ).

WRITE: / ’ Highest Cargo = ’, highest_cargo.

ENDMETHOD. "display_attributes

METHOD display_airplanes.

DATA: r_plane TYPE REF TO lcl_airplane.

LOOP AT airplane_list INTO r_plane.

r_plane->display_attributes( ).

ENDLOOP.

ENDMETHOD. "display_airplanes

METHOD constructor.

name = im_name.

Continúa en la página siguiente

146 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 161: TAW12_01

TAW12_1 Lección: Herencia y casting

ENDMETHOD. "constructor

METHOD get_name.

ex_name = name.

ENDMETHOD. "get_name

METHOD get_highest_cargo.

DATA: r_cargo TYPE REF TO lcl_cargo_plane.

DATA: r_plane TYPE REF TO lcl_airplane.

DATA: cargo TYPE s_plan_car.

DATA: r_exc TYPE REF TO cx_root.

LOOP AT airplane_list INTO r_plane.

TRY.

"**** her comes the optimistic coding *******

r_cargo ?= r_plane.

cargo = r_cargo->get_cargo( ).

IF re_cargo < cargo.

re_cargo = cargo.

ENDIF.

CATCH cx_sy_move_cast_error INTO r_exc. "*** no cargoplane

ENDTRY.

ENDLOOP.

ENDMETHOD.

ENDCLASS. "lcl_carrier IMPLEMENTATION

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 147

Page 162: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Resumen de la lección

Ahora podrá:� Definir relaciones de herencia entre clases� Redefinir métodos� Crear asignaciones up cast (widening cast)� Crear asignaciones down cast (narrowing cast)� Explicar el concepto de polimorfismo en relación con la herencia� Utilizar asignaciones cast con herencia para realizar llamadas genéricas

Más informaciónEncontrará más información acerca de este tema en la biblioteca SAP y en ladocumentación de palabras clave ABAP para las sentencias individuales.

148 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 163: TAW12_01

TAW12_1 Lección: Interfaces y casting

Lección:141

Interfaces y castingDuración de la lección: 120 Minutos

Resumen de la lecciónLa única diferencia real entre interfaces y herencia es el papel que juegan. Portanto, las ventajas de programación son las mismas que las de la herencia. Porello, en esta unidad nos concentraremos en este primer punto.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Definir e implementar interfaces� Implementar métodos de interface� Utilizar referencias de interface para realizar asignaciones up cast� Utilizar referencias de interface para realizar asignaciones down cast� Explicar el término polimorfismo en relación con interfaces� Utilizar asignaciones cast con interfaces para realizar llamadas genéricas

Although there are no significant technical differences between regular inheritanceand the implementation of interfaces, this topic is still covered in this separatelesson. That means you can use this lesson without having previously explainedinheritance.

The first section is the most important because it deals precisely with thesedifferences.

We have created the last section for the sake of completeness. In other words, itserves to build on the analogy with regular inheritance rather than presentingsignificant new programming techniques.

In this lesson, you must make a clear distinction between the terms signature andinterface. Otherwise, you will confuse the participants.

Ejemplo empresarialDesea implementar relaciones de cliente/servidor en combinación con el accesogenérico desde su modelo en objetos ABAP.

Áreas de uso para interfacesLos interfaces difieren de la herencia habitual en su área de uso. Sin embargo, entérminos de programación casi no existen diferencias.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 149

Page 164: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Desde un punto de vista técnico, los interfaces son simplemente clases superioresque no pueden ser instanciadas, no tienen ninguna parte de implementación, y sólotienen componentes públicos. Sin embargo, veremos que se puede simular laherencia múltiple utilizando interfaces.

En objetos ABAP, los interfaces se utilizan básicamente para definir interfacesuniformes (protocolos) para servicios. De esta manera, varias clases puedenofrecer (es decir, implementar) estos servicios de diferentes maneras, manteniendola misma semántica. Los interfaces, por lo tanto, no contienen implementaciones.

En objetos ABAP, los mismos componentes pueden definirse generalmente eninterfaces y en clases. Para reconocer las diferencias semánticas de la herencianormal, puede concentrarse en los casos de uso típicos siguientes:

Gráfico 84: Definición central de componentes compartidos

Por ejemplo, desea permitir que la opción tenga múltiples clases que implementenun servicio de diferentes maneras, pero utilizando los mismos nombres de métodoy con una firma uniforme. Con la herencia normal, un método de este tipo sedefine en la clase superior compartida. Sin embargo, si no se puede modelaruna clase superior de manera adecuada para la herencia, se deberá definir uninterface y después definir este método en este lugar. Por lo tanto, este caso sepuede comparar con una relación de generalización con una clase superior.

150 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 165: TAW12_01

TAW12_1 Lección: Interfaces y casting

Gráfico 85: El cliente define el protocolo

En comparación con la herencia normal, la distribución de roles es a vecesdiferente: el usuario generalmente define los interfaces. En ellos, el usuariodescribe (tanto técnica como semánticamente) los servicios que desea que ofrezcael proveedor. Cada clase puede decidir ahora por sí misma si sirve al interface, esdecir, si ofrece los servicios definidos allí. Por lo tanto, este caso es similar a unarelación de especialización con una subclase.

Como con la herencia normal, el acceso a estos servicios acostumbra a sergenérico, es decir, utiliza una referencia tipificada en el interface. Como con laherencia normal, se puede realizar por tanto polimorfismo con interfaces.

Gráfico 86: Interfaces en notación UML

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 151

Page 166: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

En UML, los interfaces se representan de la misma manera que las clases. Noobstante, además de su nombre tienen el estereotipo "interface". El uso de uninterface se representa con una línea punteada con una flecha de dos puntas desdeel usuario hasta el interface; el estereotipo "usos" es opcional. El hecho de queuna clase implemente un interface se representa con una flecha punteada de laclase al interface.

La similitud con la representación de la relación de generalización/especializaciónestá justificada, teniendo en cuenta lo que acabamos de describir.

Creación de relaciones de generalización/especial-ización utilizando interfacesEn objetos ABAP, los mismos componentes pueden definirse en un interface comoen las clases. Sin embargo, los interfaces no conocen los niveles de visibilidad delos componentes, es decir que todos los componentes de un interface son públicos.

Nota: Contemple las áreas de uso de interfaces como el interfaceuniforme para ofrecer servicios.

Gráfico 87: Definición e implementación de un interface

We recommend that you do a separate demonstration to show thedefinition and implementation of an interface. You can use programSAPBC401_VEHICLE_MAIN_J as the copy template for this.

The slide above was included because the participants are likely to have problemswith interfaces. This slide shows the perfect recipe for defining and implementinginterfaces. Explain to the participants that the interface is defined in the first step,

152 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 167: TAW12_01

TAW12_1 Lección: Interfaces y casting

made known in the classes in the second step, and, in the third step, the interfacemethods are implemented in the classes. Following this procedure (in the exercisesalso) makes things much easier. You should discuss the procedure several times.

Point out that the interface will only be used at a later stage.

Do the first exercise and explain that the relatively large scope of the preparatoryprogramming (which brings together the two submodels) is required in order tohave a clear starting point. In the second part of the exercise, the participantsimplement the procedure shown on the slide discussed above.

The merging of the two submodels can also be put to a positive use: It is likelythat most participants will not have previously experienced how easy it can be tojoin totally independent applications using object-oriented programming.

The background here is the semantic context in terms of the interface to be defined.

Las clases implementan interfaces de la manera siguiente:

� El nombre del interface se enumera en la definición de la clase con lasentencia INTERFACES. Éste debe estar en la PUBLIC SECTION, es decir,los interfaces sólo pueden implementarse públicamente.

� Los métodos de interface deben estar implementados en la parte deimplementación de la clase.

� Los componentes definidos en el interface pueden llamarse en la parte deimplementación de la clase.

Los componentes de interface se distinguen del resto de componentes en laclase de implementación, al prefijar el nombre de interface seguido de un guiónondulado (~) (el operador de resolución de interface).

interface_name~component_name

Para simplificar el acceso a los componentes de interface, se pueden utilizarnombres alias. Éstos sólo pueden aparecer en la parte de definición de una clase oen la definición de interface. Su uso está sujeto a la restricción de visibilidad dela clase de definición.

Un alias para un método de interface

ALIASES a_1 FOR lif_1~method_1.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 153

Page 168: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

El método de interface lif_1~method_1 puede llamarse entonces con la formacorta ref->a_1

.

Gráfico 88: Cómo dirigirse a componentes de interface mediante referenciasde objetos

Sólo puede accederse a los componentes de interface mediante una referencia deobjeto cuya clase implemente el interface. Sintácticamente, esto se realiza conel operador de resolución de interface ~, exactamente como con el acceso a loscomponentes de interface en la parte de implementación de la clase.

De manera alternativa, se pueden utilizar los nombres de alias definidos en la clasede implementación para los componentes de interface. Incluso si los componentescompartidos de las clases de implementación se transfieren posteriormente alinterface, no será necesario adaptar el acceso a estos componentes.. Sin embargo,el código fuente sería entonces menos autoexplicativo, ya que a partir de la sintaxisse podría deducir que los componentes se definieron en la clase.

Point out that the access to interface components using object references shownhere is rarely used. At this point, the completeness of the explanation is whatmatters. The next section shows you actually work with interfaces.

154 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 169: TAW12_01

TAW12_1 Lección: Interfaces y casting

Polimorfismo con interfacesDado que los interfaces no pueden ser instanciados, una referencia de interfacesólo puede referirse a instancias de clases que han implementado el interface. Porello, si se desea utilizar el polimorfismo con interfaces, se deberá utilizar el up castpara copiar una referencia en la variable de referencia tipificada con el interface deayuda (como con la herencia normal).

Some relationships cannot be portrayed well in static diagrams. At this point, werecommend that you draw the following diagram by hand and hide the slides:

1. Draw the reference variable R_RENTAL (as an example) on the left side.2. Write CREATE OBJECT r_rental ... above the reference variable.3. Draw the object display of a car rental company on the right side and connect

it to the reference variable.4. Within this object, draw an area with a few implemented interface

components.5. Draw another reference variable R_PARTNER at some distance below the

first one.6. Write R_PARTNER = R_RENTAL above the second reference variable and

ask the participants to specify the content of the second reference variable.7. Now, it depends what you want to show with the diagram: From a technical

point of view, only an address is copied so you can draw an arrow fromR_PARTNER to the object.

You must ask which components are addressed with R_PARTNER.

In contrast, in the following graphic we want to indicate the syntacticrestriction of the second reference variable. (Using the second variable, youcan therefore only access the implementing interface components becausethe static type is critical for the syntax check.)

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 155

Page 170: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 89: Up cast con referencias de interface

Si la clase ha implementado el interface, es seguro que todos los componentes alos que se puede acceder sintácticamente tras la asignación cast están disponiblesactualmente en la instancia. En consecuencia, un usuario puede dirigirse a lainstancia de la clase de implementación utilizando el interface. De esta manera, elprefijo del nombre de interface y el operador de resolución de interface se omiten.Sin embargo, el usuario está restringido al uso de componentes del interface.

En el ejemplo que se muestra aquí, los métodos DISPLAY_PARTNER yCHECK_AVAILABILITY del interface LLIF_PARTNER sólo pueden accedersedespués de asignar la variable de referencia R_PARTNER. No es posible accedera los componentes específicos de la instancia desde la clase LCL_RENTAL(GET_NAME en el ejemplo anterior) mediante la variable de referenciaR_PARTNER.

Así, la vista acostumbra a estar limitada (o, al menos, sin modificar). Esta es larazón por la que describimos este tipo de asignación de variables de referenciacomo up cast. Hay un cambio de una vista de varios componentes a una vista depocos componentes. La referencia destino puede aceptar, por supuesto, más tiposdinámicos después de la asignación que antes. Por ello, el términoWidening casttambién es adecuado.

You could mention at this point that the following command could be used:CREATE OBJECT r_partner TYPE lcl_rental EXPORTING in_name = �TravelAgency�. You can therefore generate an object of a class that implements theinterface using an interface reference.

156 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 171: TAW12_01

TAW12_1 Lección: Interfaces y casting

Gráfico 90: Tipo de línea de la tabla interna en el ejemplo de aplicación

Un área de uso típica de asignaciones up cast es la preparación para el accesogenérico: Un usuario que no tiene ningún interés en los puntos concretos de lasinstancias de las clases que implementan el interface, y que simplemente quieredirigirse a los componentes definidos en el interface, podría utilizar una referenciade interface para este acceso.

En el ejemplo que se muestra aquí, una agencia de viajes(LCL_TRAVEL_AGENCY) necesita gestionar todo tipo de interlocu-tores comerciales en una lista. El tipo de línea de la tabla interna debe tipificarse,por lo tanto, como la referencia al interface LIF_PARTNER.

La agencia de viajes sólo quiere solicitar los servicios para visualizar sus atributosy para verificar la disponibilidad. Los métodos relevantes DISPLAY_PARTNERy CHECK_AVAILABILITY se definen en el interface LIF_PARTNER y seimplementan en todas las clases de interlocutor comercial.

Los objetos de diferentes clases (LCL_HOTEL, LCL_RENTAL y LCL_CARRIERen el ejemplo superior) pueden mantenerse en una tabla interna, tipificadoscon referencias de interface (LIF_PARTNER en el ejemplo superior). Loscomponentes definidos en el interface pueden ser accedidos de forma uniforme.

Para este ejemplo, el método ADD_PARTNER es necesario. Éste copia lasreferencias a todos los tipos de interlocutores comerciales en esta tabla interna. Suparámetro de importación ya está tipificado como la referencia al interface.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 157

Page 172: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 91: Polimorfismo � Acceso genérico mediante la referencia deinterface

El polimorfismo también puede realizarse para interfaces: las referencias deinterface pueden utilizarse para llamar métodos, y así pueden ejecutarse diferentesimplementaciones según el objeto de la referencia.

Se utiliza el tipo dinámico y no el tipo estático de la variable de referenciapara buscar la implementación de un método. En el ejemplo superior,r_partner->display_partner( ) utiliza por ello la clase de la instancia a laque se refiere en la actualidad r_partner, para buscar la implementación dedisplay_partner. No utiliza, por ejemplo, el tipo estático para r_partner (que essiempre REF TO lif_partner).

La implementación que se ejecuta ahora cuando se llama DISPLAY_PARTNER,depende del objeto al cual se remite la referencia de interface R_PARTNER en laactualidad. Cuando los objetos de diferentes clases reaccionan de manera distintaa las mismas llamadas del método, hablamos de polimorfismo.

La opción de utilizar el polimorfismo es uno de los puntos fuertes principalesde los interfaces: un cliente puede tratar diferentes clases de manera uniforme,independientemente de su implementación. El sistema de tiempo de ejecuciónbusca la implementación correcta de un método con la ayuda del cliente.

El polimorfismo puede utilizarse para escribir programas altamente genéricos, esdecir, que no necesitan cambiarse de manera significativa si se añaden casos deuso.

En el ejemplo expuesto aquí, resulta muy fácil añadir el suplemento de alquilerde barcas: La clase relevante (por ejemplo, con el nombre LCL_SHIPPING)simplemente debería implementar el interface LIF_PARTNER y, por tanto,

158 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 173: TAW12_01

TAW12_1 Lección: Interfaces y casting

el método DISPLAY_PARTNER definido allí. La gestión de interlocutorescomerciales podría incluir fácilmente navieras y también solicitarles que muestrensus atributos.

Your demonstration program should now resemble the executable programSAPBC401_VEHD_MAIN_K. You should run your program in debugging mode.

At this point, we recommend having the participants do the second exercise ofthis lesson.

Nota: If the participants have already done this type of exercise as part ofinheritance, reduce the next exercise to a simple recapitulation.

In terms of programming, there are no new ideas.

At this point, we recommend that you add to your up-cast diagram and hide theslides:

1. Draw a reference variable R_RENTAL2 below R_PARTNER.2. Write R_RENTAL2 ?= R_PARTNER above the third reference variable

and discuss the necessity of the �?� with the participants. Then ask theparticipants what the content of the third reference variable is.

3. Draw an arrow from R_RENTAL2 to the object.

You must ask which components are addressed with R_RENTAL2.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 159

Page 174: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 92: Asignación down cast y tratamiento de excepciones en elejemplo de aplicación

Si se desea asignar una referencia de interface a una referencia de clase, donde laclase ha implementado el interface, se deberá utilizar el operador de asignacióndown cast

MOVE ... ?TO ... o su forma corta ?=. Sino, elsistema emitirá un mensaje indicando que no es seguro que todos los componentesa los que se puede acceder sintácticamente tras la asignación cast estén disponiblesactualmente en la instancia. Como regla, la clase de implementación contiene máscomponentes que el interface.

Las variables de referencia de interface pueden contener referencias a instanciasde la clase de implementación en tiempo de ejecución. Después de asignar estetipo de referencia (de vuelta) a una referencia de la clase de implementación, losclientes ya no están limitados a componentes de interface: en el ejemplo expuestoaquí, puede accederse a todos los componentes de la instancia LCL_CARRIER(de nuevo) después de la asignación, mediante la referencia R_CARRIER.

Así, la vista suele estar ampliada (o, al menos, no está modificada). Esta es larazón por la que describimos este tipo de asignación de variables de referenciacomo down cast. Existe un cambio de una vista de algunos componentes a unavista de más componentes. Dado que la variable de destino no puede aceptar lamisma cantidad de tipos dinámicos después de esto, la designación narrowingcast también es común.

Un área de uso típica de las asignaciones down cast es cuando debemos dirigirnosa los componentes específicos de instancias cuyas referencias se mantienen envariables tipificadas en el interface. Un usuario que tiene interés en los puntosconcretos de las instancias de clases de implementación, no puede utilizar lareferencia de interface para este acceso, porque sólo permite el acceso a los

160 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 175: TAW12_01

TAW12_1 Lección: Interfaces y casting

componentes de interface. En el ejemplo que se muestra aquí, una agencia deviajes (LCL_TRAVEL_AGENCY) necesita reservar un vuelo pero mantiene todotipo de referencias a interlocutores comerciales en una tabla interna tipificada enel interface LIF_PARTNER.

Por lo tanto, ¿qué sucede si no hay ninguna referencia de compañía aérea en lareferencia de interface R_PARTNER en tiempo de ejecución pero el operador deasignación down cast se utiliza para copiar la referencia a la referencia entoncesno válida R_CARRIER? Al contrario que la asignación up cast, es posible queel tipo estático de la variable de destino (R_CARRIER) no sea ni más general niigual que el tipo dinámico de las variables fuente (R_PARTNER), concretamentesi R_PARTNER contiene referencias de hotel o de vehículos de alquiler.

Esta es la razón por la que, con esta clase de cast, el sistema de tiempo deejecución verifica, antes de la asignación, si el contenido actual de la variablefuente se corresponde con los requisitos de tipo de la variable destino. Si noes así, se lanzará una excepción que puede tratarse, y el valor original de lavariable destino seguirá siendo el mismo. Esta excepción de clase de errorCX_SY_MOVE_CAST_ERROR puede identificarse mediante TRY-ENDTRY yla sentencia CATCH.

Otra manera de prevenir este error de tiempo de ejecución sería utilizar clasesde identificación de tipo de tiempo de ejecución (RTTI). Pueden utilizarse paradeterminar el tipo dinámico en el tiempo de ejecución y para fijar una condiciónpara el cast.

Las asignaciones entre variables de referencia de interface cuyos interfaces detipificación no están relacionados unos con los otros, tampoco pueden verificarseestáticamente y, por ello, deben ejecutarse utilizando down cast. Con estaasignación, el sistema verifica en tiempo de ejecución si la clase de la instanciaa la que se refiere la referencia fuente también soporta el interface con el que lareferencia de destino está tipificada.

We recommend you do a separate demonstration to show the necessity ofidentifying the exception.

Nota: You must refer to the specific lesson about the exception concept.You do not have enough time to discuss this topic now.

Jerarquías de interfacesYa hemos visto varias veces que una implementación de interface se parecemucho a la herencia normal. Por ello debemos preguntarnos qué aspecto tiene lacontraparte de interface de la herencia jerárquica. Queremos explicar las jerarquíasde interface mediante un ejemplo de aplicación.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 161

Page 176: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Compound interfaces are only discussed here as a preview of what is covered laterin the course. Do not spend too much time on this topic at this stage.

Gráfico 93: Jerarquía de interfaces en el ejemplo de aplicación

En este ejemplo, necesitamos saber si sería útil definir otro servicio �ocupación desalas� en el interface LIF_PARTNER. En este caso, las clases LCL_CARRIER yLCL_RENTAL deberían implementar el método adecuado porque han integradoel interface LIF_PARTNER. Sin embargo, la implementación de una ocupación desalas (manteniendo lamisma semántica) no es concebible para compañías aéreaso compañías de vehículos de alquiler.

Sin embargo, dado que existen otros tipos de interlocutor comercial para los quesería útil una implementación (por ejemplo, moteles y hoteles), el método debedefinirse de manera central y no individual para moteles y hoteles. Por otro lado,la opción de ampliar fácilmente el modelo con otros tipos de proveedores dealojamiento (por ejemplo, una casa de huéspedes) debe conservarse.

162 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 177: TAW12_01

TAW12_1 Lección: Interfaces y casting

Gráfico 94: Interface compuesto en notación UML

En objetos ABAP, los interfaces (como clases superiores normales) pueden incluirotros interfaces. Como con la herencia normal, el resultado son jerarquías deinterfaces de cualquier profundidad.

Así, el interface de inclusión puede considerarse una especialización del interfaceincluido. Representa una ampliación del interface incluido.

El interface de inclusión es conocido como un interface compuesto. Un interfaceincluido representa un componente de otro interface y, por tanto, es conocido comoun interface compuesto. Un interface elemental no contiene otros interfaces.

La notación UML corresponde a la implementación de un interface elementalpor parte de una clase.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 163

Page 178: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Gráfico 95: Definición e implementación de interfaces compuestos: Sintaxis

Como con la herencia normal, la clase de implementación sólo necesita enumerarel interface compuesto para integrar todos los componentes. No obstante, loscomponentes de los interfaces de componente mantienen sus nombres originales:

component_interface_name~component_name

Por ello no están prefijados con el nombre del interface compuesto.

Todas las implementaciones de métodos de todos los interfaces de nivel superiordeben realizarse en la primera clase de implementación. Los nombres aliasson adecuados para la sintaxis de forma corta al acceder a los componentes devarios interfaces. Al mismo tiempo, se obtendrá una vista documental central detodos los componentes con la definición de estos nombres alias en la clase deimplementación.

164 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 179: TAW12_01

TAW12_1 Lección: Interfaces y casting

Gráfico 96: Cómo dirigirse a componentes en interfaces compuestos �Sintaxis

Las mismas posibilidades son aplicables al acceso de sus componentes desde uninterface compuesto y a asignaciones cast.

Gráfico 97: Utilización de interfaces

Los interfaces se utilizan para describir protocolos para el uso de componentessin conectar un tipo de implementación. Una capa intermedia se introduce entreel cliente y el servidor para proteger al cliente del servidor explícito, haciendo alcliente independiente.

Los interfaces permiten tratar uniformemente diferentes clases, partiendo de labase de que han implementado sus interfaces. Como con la herencia, también sepuede realizar polimorfismo con variables de referencia de interface.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 165

Page 180: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Como con la herencia normal, la definición de un interface significa unaabstracción de las clases de implementación en un aspecto parcial específico.

La herencia múltiple puede simularse mediante interfaces: si se incluyen variosinterfaces, todos los componentes estarán disponibles para todos estos interfaces.Todos los métodos deberán estar implementados.

166 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 181: TAW12_01

TAW12_1 Lección: Interfaces y casting

157 Ejercicio 10: Definición e implementaciónde interfacesDuración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Definir interfaces� Implementar interfaces

Ejemplo empresarial

Please note that this exercise is the most difficult exercise in the course for thosenot familiar with object-oriented programming. The topic is relatively abstract andhard to grasp for the beginners and weaker participants on the course; it is perhapsthe most important exercise in the course because everything that has been learntso far is consolidated once more in a larger, more extensive programming exercise.

Atención:

� Here is where you should consider your exact teaching method in advance!� It would be best to carry out the individual sub-exercises step by step.� Motivate your participants with questions about the aims and objectives of

the individual steps!

Ahora debe añadir una compañía de vehículos de alquiler a su programa de gestiónde aviones. Las compañías aéreas y las de vehículos de alquiler deben extraerseen interlocutores comerciales; es decir, deben poder ofrecer servicios generalesutilizando un interface abstracto. Estos servicios se utilizarán en ejerciciosposteriores para agencias de viajes.

Tarea 1:Defina un interface con el servicio DISPLAY_PARTNER �Visualización delos datos de interlocutor comercial� para ofrecer más tarde opciones de accesogenéricas a clientes potenciales (en nuestro ejemplo una agencia de viajes). Elinterface se implementará en la clase para compañías aéreas y también en la clasepara compañías de vehículos de alquiler.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior SAPBC401_CASS_MAIN_C (## es el número de grupode dos cifras). )

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 167

Page 182: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

2. Cree el Include ZBC401_##_INTERFACE y defina un interfaceLIF_PARTNERS.

3. El interface debería contener el método de instancia DISPLAY_PARTNER.¡Este método no debe poseer ninguna firma! Más adelante, su tarea serávisualizar atributos de interlocutor comercial.

4. Integre el Include en su programa principal para producir un orden correcto yrazonable de las definiciones de clase restantes. ¡Tenga en cuenta que habráotras clases que utilizarán esta definición de interface más adelante!

Ahora verifique y active su aplicación terminada.

Consejo: La integración del Include con el nuevo interface en estepunto del ejercicio no ampliará la funcionalidad de la aplicación;esto sólo sucederá en los siguientes pasos de la tarea.

Tarea 2:La clase LCL_CARRIER debería poner a disposición el �servicio�DISPLAY_PARTNER desde el interface a clientes potenciales. Además, laimplementación del método de interface DISPLAY_PARTNER es necesario.

1. Ahora presente el interface que acaba de crear en su clase LCL_CARRIER.Para ello, también deberá estar implementado allí. Esto significa queLCL_CARRIER actúa como una �clase de servidor� en este contexto, yofrecerá el servicio DISPLAY_PARTNER a un cliente posterior que todavíadebe ser programado.

Asegúrese de que en este lugar se familiariza con las partes correspondientesdel gráfico UML y, si es necesario, complemente sus propios gráficos UMLen los sitios adecuados. (Debería haber una flecha entre INTERFACEy LCL_CARRIER).

2. Implemente la codificación del método de interface DISPLAY_PARTNERen su clase LCL_CARRIER. Tal como se deduce del nombre de este método,los datos o atributos de este interlocutor comercial deberían mostrarse aquí.Considere posibles soluciones y ejecute la aproximación más adecuada.

Verifique de nuevo la aplicación entera para asegurare de que la sintaxises correcta y active la aplicación.

Consejo: El rendimiento de la aplicación entera aún no cambiará eneste punto; los resultados sólo se verán en las tareas posteriores.

Continúa en la página siguiente

168 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 183: TAW12_01

TAW12_1 Lección: Interfaces y casting

Tarea 3:El interface implementado en la clase LCL_CARRIER debería verificarse ahorallamándolo desde el programa principal.

1. Ahora navegue a su programa principal.

En este lugar, elimine todas las llamadas de DISPLAY_ATTRIBUTES quese utilizaron en los ejercicios anteriores, incluyendo aquéllas utilizadas pararealizar tests.

2. Para verificar el correcto funcionamiento de los servicios, es decir, paraverificar los métodos de interface, llame temporalmente el método deinterface DISPLAY_PARTNER de su clase LCL_CARRIER como siguientepaso provisional.

¿Cómo debería codificarse esta llamada desde el programa principal?

3. ¿Cuál es el propósito y el objetivo de una llamada de este tipo en este puntodel ejercicio, o con otras palabras, qué nos ofrece la opción de esta llamadade método de interface en el programa principal en relación con una llamadade método convencional?

4. Después de realizar un test con éxito, convierta esta llamada de método enun comentario, de manera que pase a ser inefectiva.

Consejo: El uso genérico de los métodos de interface mediante otraclase tiene lugar en los siguientes pasos del ejercicio.

El rendimiento de la aplicación entera aún no cambiará en estepunto; los resultados sólo se verán en las tareas posteriores.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 169

Page 184: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Tarea 4: Integración del modelo de formación

Atención: Take a close look at these steps and consider how you wantto approach them from a didactic point of view. The exercise is onlyconcerned with using SE80 effectively. Amazingly, some participants stillhave problems with this. You should therefore demonstrate these copysteps. You should also point out how to activate a program with severalincludes correctly.

Explain to the participants that by bringing the two part models together,the advantage of using interfaces becomes very clear, and the onlydifficult part of the exercise is the integration of an include. The programbecomes larger overall, but the individual classes are defined in includes.This is something that you should expect every participant to be capableof by this point.

Para estructurar la aplicación de forma sensata, deberán integrarse el modelo de laparte del instructor con la clase LCL_RENTAL y el resto de clases de vehículo(LCL_VEHICLE, LCL_TRUCK y LCL_BUS).

El primer paso consiste en copiar un Include modelo: Copie el IncludeSAPBC401_VEHT_OPT en su nuevo Include propio ZSAPBC401_##_VEHT,e integre este Include en su programa principal. Contiene el modelo parcial enterode las clases LCL_RENTAL, LCL_VEHICLE, LCL_TRUCK y LCL_BUS.

Para LCL_RENTAL implemente el interface LIF_PARTNERS de nuevo (comoantes en su nueva clase LCL_CARRIER).

El segundo paso consiste en generar instancias para las clases del modeloparcial RENTAL, con el objetivo de dar vida a la aplicación. Para facilitarle eltrabajo, existe un programa modelo disponible con la instanciación de estas clases(LCL_TRUCK, LCL_BUS, LCL_RENTAL) (SAPBC401_INTS_MAIN_OPT).Puede copiar las partes correspondientes del programa en su programa principalmediante CTRL+C, CTRL+V.

Aún no es necesario visualizar los objetos en este lugar. Esto se hará más tarde.¡De momento, puede desactivar o borrar todas las llamadas de los métodosDISPLAY en su programa principal!

1. La solución Include se denomina: SAPBC401_VEHS_OPT

2. El programa principal de solución se denomina:SAPBC401_INTS_MAIN_D.

170 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 185: TAW12_01

TAW12_1 Lección: Interfaces y casting

Solución 10: Definición e implementaciónde interfacesTarea 1:Defina un interface con el servicio DISPLAY_PARTNER �Visualización delos datos de interlocutor comercial� para ofrecer más tarde opciones de accesogenéricas a clientes potenciales (en nuestro ejemplo una agencia de viajes). Elinterface se implementará en la clase para compañías aéreas y también en la clasepara compañías de vehículos de alquiler.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior SAPBC401_CASS_MAIN_C (## es el número de grupode dos cifras). )

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional acerca de cómo copiar programas en la biblioteca SAP.

2. Cree el Include ZBC401_##_INTERFACE y defina un interfaceLIF_PARTNERS.

a) Véase el extracto del código fuente de la solución modelo.

b) La solución se denomina: SAPBC401_INTS_INTERFACE

3. El interface debería contener el método de instancia DISPLAY_PARTNER.¡Este método no debe poseer ninguna firma! Más adelante, su tarea serávisualizar atributos de interlocutor comercial.

a) Véase el extracto del código fuente de la solución modelo.

4. Integre el Include en su programa principal para producir un orden correcto yrazonable de las definiciones de clase restantes. ¡Tenga en cuenta que habráotras clases que utilizarán esta definición de interface más adelante!

Ahora verifique y active su aplicación terminada.

Consejo: La integración del Include con el nuevo interface en estepunto del ejercicio no ampliará la funcionalidad de la aplicación;esto sólo sucederá en los siguientes pasos de la tarea.

a) Véase el extracto del código fuente de la solución modelo.

b) Solución de programa principal SAPBC401_INTS_MAIN_A

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 171

Page 186: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Tarea 2:La clase LCL_CARRIER debería poner a disposición el �servicio�DISPLAY_PARTNER desde el interface a clientes potenciales. Además, laimplementación del método de interface DISPLAY_PARTNER es necesario.

1. Ahora presente el interface que acaba de crear en su clase LCL_CARRIER.Para ello, también deberá estar implementado allí. Esto significa queLCL_CARRIER actúa como una �clase de servidor� en este contexto, yofrecerá el servicio DISPLAY_PARTNER a un cliente posterior que todavíadebe ser programado.

Asegúrese de que en este lugar se familiariza con las partes correspondientesdel gráfico UML y, si es necesario, complemente sus propios gráficos UMLen los sitios adecuados. (Debería haber una flecha entre INTERFACEy LCL_CARRIER).

a) Véase el extracto del código fuente de la solución modelo.

2. Implemente la codificación del método de interface DISPLAY_PARTNERen su clase LCL_CARRIER. Tal como se deduce del nombre de este método,los datos o atributos de este interlocutor comercial deberían mostrarse aquí.Considere posibles soluciones y ejecute la aproximación más adecuada.

Verifique de nuevo la aplicación entera para asegurare de que la sintaxises correcta y active la aplicación.

Consejo: El rendimiento de la aplicación entera aún no cambiará eneste punto; los resultados sólo se verán en las tareas posteriores.

a) Véase el extracto del código fuente de la solución modelo.

b) La solución Include se denomina: SAPBC401_INTS_B

c) El programa principal correspondiente se denomina:SAPBC401_INTS_MAIN_B

Tarea 3:El interface implementado en la clase LCL_CARRIER debería verificarse ahorallamándolo desde el programa principal.

1. Ahora navegue a su programa principal.

En este lugar, elimine todas las llamadas de DISPLAY_ATTRIBUTES quese utilizaron en los ejercicios anteriores, incluyendo aquéllas utilizadas pararealizar tests.

a) Lleve a cabo este paso de la manera habitual.

Continúa en la página siguiente

172 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 187: TAW12_01

TAW12_1 Lección: Interfaces y casting

2. Para verificar el correcto funcionamiento de los servicios, es decir, paraverificar los métodos de interface, llame temporalmente el método deinterface DISPLAY_PARTNER de su clase LCL_CARRIER como siguientepaso provisional.

¿Cómo debería codificarse esta llamada desde el programa principal?

a) Véase el extracto del código fuente de la solución modelo.

b) El programa de solución se denomina: SAPBC401_INTS_MAIN_C

3. ¿Cuál es el propósito y el objetivo de una llamada de este tipo en este puntodel ejercicio, o con otras palabras, qué nos ofrece la opción de esta llamadade método de interface en el programa principal en relación con una llamadade método convencional?

a) Si no fuera por la sintaxis detallada y �más larga� de esta llamada, lallamada de método de interface podría sustituirse por una llamada demétodo de instancia normal, por ejemplo DISPLAY_ATTRIBUTES. Eneste punto del ejercicio, esta llamada no parece ser sensible en general.

4. Después de realizar un test con éxito, convierta esta llamada de método enun comentario, de manera que pase a ser inefectiva.

Consejo: El uso genérico de los métodos de interface mediante otraclase tiene lugar en los siguientes pasos del ejercicio.

El rendimiento de la aplicación entera aún no cambiará en estepunto; los resultados sólo se verán en las tareas posteriores.

a) Véase el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 173

Page 188: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Tarea 4: Integración del modelo de formación

Atención: Take a close look at these steps and consider how you wantto approach them from a didactic point of view. The exercise is onlyconcerned with using SE80 effectively. Amazingly, some participants stillhave problems with this. You should therefore demonstrate these copysteps. You should also point out how to activate a program with severalincludes correctly.

Explain to the participants that by bringing the two part models together,the advantage of using interfaces becomes very clear, and the onlydifficult part of the exercise is the integration of an include. The programbecomes larger overall, but the individual classes are defined in includes.This is something that you should expect every participant to be capableof by this point.

Para estructurar la aplicación de forma sensata, deberán integrarse el modelo de laparte del instructor con la clase LCL_RENTAL y el resto de clases de vehículo(LCL_VEHICLE, LCL_TRUCK y LCL_BUS).

El primer paso consiste en copiar un Include modelo: Copie el IncludeSAPBC401_VEHT_OPT en su nuevo Include propio ZSAPBC401_##_VEHT,e integre este Include en su programa principal. Contiene el modelo parcial enterode las clases LCL_RENTAL, LCL_VEHICLE, LCL_TRUCK y LCL_BUS.

Para LCL_RENTAL implemente el interface LIF_PARTNERS de nuevo (comoantes en su nueva clase LCL_CARRIER).

El segundo paso consiste en generar instancias para las clases del modeloparcial RENTAL, con el objetivo de dar vida a la aplicación. Para facilitarle eltrabajo, existe un programa modelo disponible con la instanciación de estas clases(LCL_TRUCK, LCL_BUS, LCL_RENTAL) (SAPBC401_INTS_MAIN_OPT).Puede copiar las partes correspondientes del programa en su programa principalmediante CTRL+C, CTRL+V.

Aún no es necesario visualizar los objetos en este lugar. Esto se hará más tarde.¡De momento, puede desactivar o borrar todas las llamadas de los métodosDISPLAY en su programa principal!

1. La solución Include se denomina: SAPBC401_VEHS_OPT

a)

2. El programa principal de solución se denomina:SAPBC401_INTS_MAIN_D.

a)

Continúa en la página siguiente

174 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 189: TAW12_01

TAW12_1 Lección: Interfaces y casting

ResultadoExtracto de código fuente para las tareas individuales

Tarea 1

Include SAPBC401_INTS_INTERFACE

*&---------------------------------------------------------------------*

*& Include SAPBC401_INTS_INTERFACE *

*&---------------------------------------------------------------------*

*---------------------------------------------------------------------*

* define interface lif_partners in this includefile *

*---------------------------------------------------------------------*

INTERFACE lif_partners.

METHODS display_partner.

ENDINTERFACE.

Programm SAPBC401_INTS_MAIN_A

REPORT sapbc401_ints_main_a.

*** This is the MAIN program ! *********************

TYPE-POOLS icon.

*** include the new includefile with the interface definition !

INCLUDE sapbc401_ints_interface.

INCLUDE sapbc401_ints_a.

DATA: r_plane TYPE REF TO lcl_airplane,

r_cargo TYPE REF TO lcl_cargo_plane,

r_passenger TYPE REF TO lcl_passenger_plane,

r_carrier TYPE REF TO lcl_carrier,

START-OF-SELECTION.

*##############################

* nothing has to be changed here...****

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 175

Page 190: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Tarea 2

Include SAPBC401_INTS_B

*&---------------------------------------------------------------------*

*& Include SAPBC401_INTS_B *

*&---------------------------------------------------------------------*

*...definitions of lcl_airplane and other classes

* now the class LCL_CARRIER has to be extended

* this class implements the interface LIF_PARTNERS !

*–––––----------------------------------------------------------------*

* CLASS lcl_carrier DEFINITION *

*---------------------------------------------------------------------*

CLASS lcl_carrier DEFINITION.

PUBLIC SECTION.

"----------------------------------------

INTERFACES lif_partners.

METHODS: constructor IMPORTING im_name TYPE string,

get_name RETURNING value(ex_name) TYPE string,

add_airplane IMPORTING

im_plane TYPE REF TO lcl_airplane,

display_airplanes,

display_attributes.

PRIVATE SECTION.

"-----------------------------------

DATA: name TYPE string,

airplane_list TYPE TABLE OF REF TO lcl_airplane.

ENDCLASS. "lcl_carrier DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_carrier IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_carrier IMPLEMENTATION.

* implement the interfacemethod !

METHOD lif_partners~display_partner.

display_attributes( ).

ENDMETHOD. "lif_partners~display_partner

*....... nothing has to be changed here...

ENDCLASS. "lcl_carrier IMPLEMENTATION

Continúa en la página siguiente

176 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 191: TAW12_01

TAW12_1 Lección: Interfaces y casting

Tarea 3

Programm SAPBC401_INTS_MAIN_C

REPORT sapbc401_ints_main_c.

* change the main programm to show how the

* interfacemethod DISPLAY_PARTNER can be called !

TYPE-POOLS icon.

INCLUDE sapbc401_ints_interface.

INCLUDE sapbc401_ints_b.

DATA: r_plane TYPE REF TO lcl_airplane,

r_cargo TYPE REF TO lcl_cargo_plane,

r_passenger TYPE REF TO lcl_passenger_plane,

r_carrier TYPE REF TO lcl_carrier,

r_lif TYPE REF TO lif_partners.

START-OF-SELECTION.

*##############################

***** Create CARRIER ********************************************

CREATE OBJECT r_carrier EXPORTING im_name = ’Smile&Fly Travel’.

* ...nothing has to be changed...

*... creating several other classes like LCL_AIRPLANE...

*** call the interface method DISPLAY_PARTNER

*** that is implemented in the class LCL_CARRIER

*** Please think about the purpose of this! Could this be be achieved easier ?

r_carrier->lif_partners~display_partner( ).

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 177

Page 192: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Tarea 4

Include SAPBC401_VEHS_OPT

*&---------------------------------------------------------------------*

*& Include SAPBC401_VEHS_OPT *

*& Solution which contains all classes of submodell RENTAL / VEHICLE *

*& and the interface LIF_PARTNERS is implemented in class LCL_RENTAL *

*& *

*&------------------------------------------------------------–--------*

*---------------------------------------------------------------------*

* CLASS lcl_vehicle DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_vehicle DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: get_average_fuel IMPORTING im_distance TYPE s_distance

im_fuel TYPE s_capacity

RETURNING value(re_avgfuel) TYPE s_consum.

METHODS constructor IMPORTING im_make TYPE string.

METHODS display_attributes.

METHODS set_make IMPORTING im_make TYPE string.

METHODS get_make EXPORTING ex_make TYPE string.

CLASS-METHODS get_count EXPORTING re_count TYPE i.

PRIVATE SECTION.

"-------------------

DATA: make TYPE string.

METHODS init_make.

CLASS-DATA: n_o_vehicles TYPE i.

ENDCLASS. "lcl_vehicle DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_vehicle IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_vehicle IMPLEMENTATION.

METHOD constructor.

make = im_make.

Continúa en la página siguiente

178 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 193: TAW12_01

TAW12_1 Lección: Interfaces y casting

ADD 1 TO n_o_vehicles.

ENDMETHOD.

METHOD get_average_fuel.

re_avgfuel = im_distance / im_fuel.

ENDMETHOD.

METHOD set_make.

IF im_make IS INITIAL.

init_make( ). " me->init_make( ).

ELSE.

make = im_make.

ENDIF.

ENDMETHOD.

METHOD init_make.

make = ’default make’.

ENDMETHOD. "init_make

METHOD get_make.

ex_make = make.

METHOD get_make. "get_make

METHOD display_attributes.

WRITE: make.

ENDMETHOD. "display_attributes

METHOD get_count.

re_count = n_o_vehicles.

ENDMETHOD. "get_count

ENDCLASS. "lcl_vehicle IMPLEMENTATION

*---------------------------------------------------------------------*

* CLASS lcl_truck DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_truck DEFINITION INHERITING FROM lcl_vehicle.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_make TYPE string

im_cargo TYPE s_plan_car.

METHODS display_attributes REDEFINITION.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 179

Page 194: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

METHODS get_cargo RETURNING value(re_cargo) TYPE s_plan_car.

PRIVATE SECTION.

"-------------------

DATA: max_cargo TYPE s_plan_car.

ENDCLASS

*---------------------------------------------------------------------*

* CLASS lcl_truck IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_truck IMPLEMENTATION.

METHOD constructor.

super->constructor( im_make ).

max_cargo = im_cargo.

ENDMETHOD. "constructor

METHOD display_attributes.

WRITE: / icon_ws_truck AS ICON.

super->display_attributes( ).

WRITE: 20 ’ Cargo = ’, max_cargo.

ULINE.

ENDMETHOD. "display_attributes

METHOD get_cargo.

re_cargo = max_cargo.

ENDMETHOD. "get_cargo

ENDCLASS.

*---------------------------------------------------------------------*

* CLASS lcl_bus DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_bus DEFINITION INHERITING FROM lcl_vehicle.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_make TYPE string

im_passengers TYPE i.

METHODS display_attributes REDEFINITION.

Continúa en la página siguiente

180 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 195: TAW12_01

TAW12_1 Lección: Interfaces y casting

PRIVATE SECTION.

"-------------------

DATA: max_passengers TYPE i.

ENDCLASS.

*---------------------------------------------------------------------*

* CLASS lcl_bus IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_bus IMPLEMENTATION.

METHOD constructor.

super->constructor( im_make ).

max_passengers = im_passengers.

ENDMETHOD. "constructor

METHOD display_attributes.

WRITE: / icon_transportation_mode AS ICON.

super->display_attributes( ).

WRITE: 20 ’ Passengers = ’, max_passengers.

ULINE.

ENDMETHOD. "display_attributes

ENDCLASS.

*---------------------------------------------------------------------*

* CLASS lcl_rental DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_rental DEFINITION.

PUBLIC SECTION.

"-------------------

INTERFACES lif_partners.

METHODS: constructor IMPORTING im_name TYPE string.

METHODS add_vehicle IMPORTING im_vehicle

TYPE REF TO lcl_vehicle.

METHODS display_attributes.

PRIVATE SECTION.

"-------------------

DATA: name TYPE string,

vehicle_list TYPE TABLE OF REF TO lcl_vehicle.

ENDCLASS.

*---------------------------------------------------------------------*

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 181

Page 196: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

* CLASS lcl_rental IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_rental IMPLEMENTATION.

METHOD lif_partners~display_partner.

display_attributes( ).

ENDMETHOD.

METHOD constructor.

name = im_name.

ENDMETHOD. "constructor

METHOD add_vehicle.

APPEND im_vehicle TO vehicle_list.

ENDMETHOD. "add_vehicle

METHOD display_attributes.

DATA: r_vehicle TYPE REF TO lcl_vehicle.

WRITE: / icon_transport_proposal AS ICON, name.

WRITE: ’ Here comes the vehicle list: ’. ULINE. ULINE.

LOOP AT vehicle_list INTO r_vehicle.

r_vehicle->display_attributes( ).

ENDLOOP.

ENDMETHOD. "display_attributes

ENDCLASS. "lcl_rental IMPLEMENTATION

Programm SAPBC401_INTS_MAIN_D

REPORT sapbc401_ints_main_d.

* this is the final main-program showing instances of both submodels!

TYPE-POOLS icon.

* include file with the interfacedefinition.

INCLUDE sapbc401_ints_interface

* now the submodel of the trainer is included with rental and all vehicle classes

INCLUDE sapbc401_vehs_opt.

* submodel with carrier and all the airplane classes

INCLUDE sapbc401_ints_b.

DATA: r_plane TYPE REF TO lcl_airplane,

r_cargo TYPE REF TO lcl_cargo_plane,

Continúa en la página siguiente

182 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 197: TAW12_01

TAW12_1 Lección: Interfaces y casting

r_passenger TYPE REF TO lcl_passenger_plane,

r_carrier TYPE REF TO lcl_carrier,

r_rental TYPE REF TO lcl_rental,

r_truck TYPE REF TO lcl_truck,

r_bus TYPE REF TO lcl_bus,

r_lif TYPE REF TO lif_partners.

START-OF-SELECTION.

*##############################

***** Create CARRIER ********************************************

CREATE OBJECT r_carrier EXPORTING im_name = ’Smile&Fly Travel’.

* ...creating instances of airplane classes and add them to LCL_CARRIER

*... this has already been shown in many excercises before

***** Create Rental and other objects of vehicle submodel **********

CREATE OBJECT r_rental EXPORTING im_name = ’Happy Car Rental’.

* create some vehicles and add them to the rentalclass

CREATE OBJECT r_truck EXPORTING im_make = ’MAN’

im_cargo = 45.

r_rental->add_vehicle( r_truck ).

CREATE OBJECT r_bus EXPOTRING im_make = ’VOLVO’

im_max_passengers = 56.

r_rental->add_vehicle( r_bus ).

*** just to show the call of the interfacemethod for testing

*r_carrier->lif_partners~display_partner( ).

*r_rental->lif_partners~display_partner( ).

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 183

Page 198: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

184 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 199: TAW12_01

TAW12_1 Lección: Interfaces y casting

173 Ejercicio 11: Uso de interfacesDuración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Trabajar con interfaces� Utilizar los servicios de los interfaces como cliente

Ejemplo empresarialAhora debe añadir una clase de usuario a su programa: las agencias de viajesnecesitan gestionar varios interlocutores comerciales mediante el interface y teneracceso a los servicios generales de interlocutores comerciales.

Tarea 1:

Encourage the participants to perform this last step: Make it clear that this isabout the USE of the interface. Explain this several times using UML! The serverclasses implement the interface, the client that now follows uses the interface byaccessing the server classes services using interface references. The participantsshould consider carefully what they are doing where, and why!

Defina una clase local para agencias de viajes.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior. (## es el número de grupo de dos cifras). )

2. Si es necesario, añada una clase LCL_TRAVEL_AGENCY que utilice elinterface LIF_PARTNERS a su diagrama UML.

3. Para facilitar la carga de tipificación, puede copiar secciones detexto fuente del modelo SAPBC401_VEHT_B de la clase localLCL_TRAVEL_AGENCY en su programa principal o en uno de susprogramas de Include para complementarlos. Si es necesario, la claseLCL_TRAVEL_AGENCY también puede crearse desde el principio, sinutilizar modelos.

4. Como atributo de clase privado, añada una tabla interna PARTNER_LISTpara la grabación en memoria intermedia de las referencias a los interlocutorescomerciales que han implementado el interface LIF_PARTNERS.

5. Amplíe la firma y la implementación del método ADD_PARTNER demanera que las referencias de interlocutor comercial puedan añadirse a lalista PARTNER_LIST.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 185

Page 200: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

6. Implemente el método DISPLAY_AGENCY_PARTNERS de maneraque los atributos de todos los interlocutores comerciales de la agencia deviajes puedan añadirse a la lista. El método ofrecido de manera centralDISPLAY_PARTNER debe llamarse para cada interlocutor comercial.

Tarea 2:En el programa principal, genere una instancia de agencia de viajes, transfiera lasreferencias a la compañía aérea y a la de vehículos de alquiler a esta instancia,y añada los atributos.

1. En el programa principal, defina una variable de referencia tipificadacorrectamente para su nueva clase de agencia de viajes.

2. Mediante la referencia, genere una instancia de su claseLCL_TRAVEL_AGENCY. Decida cómo rellenar los atributos.

3. Llame el método ADD_PARTNER para transferir las referencias a lasinstancias generadas de compañía aérea y de vehículos de alquiler a laagencia de viajes.

4. Añada los atributos de la agencia de viajes llamando su métodoDISPLAY_AGENCY_PARTNERS.

El método DISPLAY_ATTRIBUTES también podría crearse(opcionalmente) en esta clase, y emitiría los nombres de agencias de viajesy todos los interlocutores comerciales juntos. En este método es necesariollamar el método DISPLAY_AGENCY_PARTNERS tras la salida de losnombres de agencia de viajes.

186 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 201: TAW12_01

TAW12_1 Lección: Interfaces y casting

Solución 11: Uso de interfacesTarea 1:

Encourage the participants to perform this last step: Make it clear that this isabout the USE of the interface. Explain this several times using UML! The serverclasses implement the interface, the client that now follows uses the interface byaccessing the server classes services using interface references. The participantsshould consider carefully what they are doing where, and why!

Defina una clase local para agencias de viajes.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior. (## es el número de grupo de dos cifras). )

a) Lleve a cabo este paso de la manera habitual. Para más información,consulte la biblioteca SAP.

b) Solución modelo: SAPBC401_INTS_MAIN_E

2. Si es necesario, añada una clase LCL_TRAVEL_AGENCY que utilice elinterface LIF_PARTNERS a su diagrama UML.

a) Hable con su instructor si tiene cualquier duda.

3. Para facilitar la carga de tipificación, puede copiar secciones detexto fuente del modelo SAPBC401_VEHT_B de la clase localLCL_TRAVEL_AGENCY en su programa principal o en uno de susprogramas de Include para complementarlos. Si es necesario, la claseLCL_TRAVEL_AGENCY también puede crearse desde el principio, sinutilizar modelos.

a) Lleve a cabo este paso de la manera habitual. Para más información,consulte la biblioteca SAP.

4. Como atributo de clase privado, añada una tabla interna PARTNER_LISTpara la grabación en memoria intermedia de las referencias a los interlocutorescomerciales que han implementado el interface LIF_PARTNERS.

a) Véase el extracto del código fuente de la solución modelo.

5. Amplíe la firma y la implementación del método ADD_PARTNER demanera que las referencias de interlocutor comercial puedan añadirse a lalista PARTNER_LIST.

a) Véase el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 187

Page 202: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

6. Implemente el método DISPLAY_AGENCY_PARTNERS de maneraque los atributos de todos los interlocutores comerciales de la agencia deviajes puedan añadirse a la lista. El método ofrecido de manera centralDISPLAY_PARTNER debe llamarse para cada interlocutor comercial.

a) Véase el extracto del código fuente de la solución modelo.

Tarea 2:En el programa principal, genere una instancia de agencia de viajes, transfiera lasreferencias a la compañía aérea y a la de vehículos de alquiler a esta instancia,y añada los atributos.

1. En el programa principal, defina una variable de referencia tipificadacorrectamente para su nueva clase de agencia de viajes.

a) Véase el extracto del código fuente de la solución modelo.

2. Mediante la referencia, genere una instancia de su claseLCL_TRAVEL_AGENCY. Decida cómo rellenar los atributos.

a) Véase el extracto del código fuente de la solución modelo.

3. Llame el método ADD_PARTNER para transferir las referencias a lasinstancias generadas de compañía aérea y de vehículos de alquiler a laagencia de viajes.

a) Véase el extracto del código fuente de la solución modelo.

4. Añada los atributos de la agencia de viajes llamando su métodoDISPLAY_AGENCY_PARTNERS.

El método DISPLAY_ATTRIBUTES también podría crearse(opcionalmente) en esta clase, y emitiría los nombres de agencias de viajesy todos los interlocutores comerciales juntos. En este método es necesariollamar el método DISPLAY_AGENCY_PARTNERS tras la salida de losnombres de agencia de viajes.

a) Programa principal solución: SAPBC401_INTS_MAIN_E.

b) Include de solución: SAPBC401_INTS_AGENCY.

ResultadoCódigo fuente de la solución modelo:

SAPBC401_INTS_AGENCY

* - this is the includefile with the classdefinition of LCL_TRAVEL_AGENCY -

*---------------------------------------------------------------------*

* CLASS lcl_travel_agency DEFINITION

Continúa en la página siguiente

188 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 203: TAW12_01

TAW12_1 Lección: Interfaces y casting

*---------------------------------------------------------------------*

CLASS lcl_travel_agency DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_name TYPE string.

METHODS add_partner IMPORTING im_partner

TYPE REF TO lif_partners.

METHODS display_agency_partners.

METHODS: display_attributes.

PRIVATE SECTION.

"-------------------

DATA: name TYPE string,

partner_list TYPE TABLE OF REF TO lif_partners.

ENDCLASS. "lcl_travel_agency DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_travel_agency IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_travel_agency IMPLEMENTATION.

METHOD display_attributes.

write: / ’Name of the agency: ’, name. ULINE.

write: / ’Here are the partners of the agency :’.

display_agency_partners( ).

ENDMETHOD.

METHOD display_agency_partners.

DATA: r_partner TYPE REF TO lif_partners.

WRITE: icon_dependents AS ICON, name.

WRITE: ’ Here are the partners of the travel agency: ’. ULINE.

LOOP AT partner_list INTO r_partner.

r_partner->display_partner( ).

ENDLOOP.

ENDMETHOD. "display_agency_partners

METHOD constructor.

name = im_name.

ENDMETHOD. "constructor

METHOD add_partner.

APPEND im_partner TO partner_list.

ENDMETHOD. "add_partner

ENDCLASS. "lcl_travel_agency IMPLEMENTATION

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 189

Page 204: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

SAPBC401_INTS_MAIN_E

* - this is the main program -

REPORT sapbc401_ints_main_e.

TYPE-POOLS icon.

INCLUDE sapbc401_ints_interface.

INCLUDE sapbc401_ints_agency.

INCLUDE sapbc401_vehs_opt.

INCLUDE sapbc401_ints_b.

DATA: r_plane TYPE REF TO lcl_airplane,

r_cargo TYPE REF TO lcl_cargo_plane,

r_passenger TYPE REF TO lcl_passenger_plane,

r_carrier TYPE REF TO lcl_carrier,

r_agency TYPE REF TO lcl_travel_agency,

r_rental TYPE REF TO lcl_rental,

r_truck TYPE REF TO lcl_truck,

r_bus TYPE REF TO lcl_bus.

START-OF-SELECTION.

*##############################

***** Create TRAVEL_AGENCY **************************************

CREATE OBJECT r_agency EXPORTING im_name = ’Fly&Smile Travel’.

***** Create CARRIER ********************************************

CREATE OBJECT r_carrier EXPORTING im_name = ’Smile&Fly Travel’.

..

***** insert business-parnter of agency into partner_list***********

r_agency->add_partner( r_carrier ).

******* create RENTAL *****************************************

CREATE OBJECT r_rental EXPORTING im_name = ’HAPPY CAR RENTAL’.

*** creating all the VEHICLE and AIRPLANE objects is left out here

*** it has been shown several times before

***** insert business-parnter of agency into partner_list***********

r_agency->add_partner( r_rental ).

******* show attributes of agency including all businesspartners ******

r_agency->display_attributes( ).

190 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 205: TAW12_01

TAW12_1 Lección: Interfaces y casting

Resumen de la lección

Ahora podrá:� Definir e implementar interfaces� Implementar métodos de interface� Utilizar referencias de interface para realizar asignaciones up cast� Utilizar referencias de interface para realizar asignaciones down cast� Explicar el término polimorfismo en relación con interfaces� Utilizar asignaciones cast con interfaces para realizar llamadas genéricas

Más informaciónPara más información, consulte la biblioteca SAP.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 191

Page 206: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Lección:180

EventosDuración de la lección: 75 Minutos

Resumen de la lecciónEsta unidad ofrece una introducción general al concepto de los eventos dentro dela orientación a objetos, seguida de una explicación de todos los aspectos de lamodelación y todos los elementos sintácticos relacionados. La sección con eltitulo "Inscripción" contiene probablemente la información más importante paraentender este tema.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Definir y desencadenar eventos� Tratar eventos� Registrar y deregistrar el tratamiento de eventos� Explicar las diferencias clave entre llamadas de método explícitas y llamadas

de método controladas por evento

Nota: This application example used here does not specify that the eventsare defined in superclasses or interfaces.

Therefore, before you look at the first graphic about the event concept, you couldalso start the course by turning the approach around and having the participantsdiscuss which class should do the defining and triggering and which should do thehandling. Assuming that the participants have understood the inheritance concept,they should be able to come up with the solution themselves. The same applies tothe optional exercise in which participants define the event in the interface.

Ejemplo empresarialDesea implementar un comportamiento controlado por evento desde su modeloen objetos ABAP.

Llamadas de método controladas por eventoAdemás de atributos y métodos, las clases (y sus instancias) pueden contenerun tercer tipo de componente: eventos. Los eventos de instancia pueden serdesencadenados por parte de las instancias de la clase, mientras que los eventosde instancia estáticos pueden ser desencadenados por parte de la clase misma.

Los eventos también se pueden definir como componentes de interface.

192 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 207: TAW12_01

TAW12_1 Lección: Eventos

Gráfico 98: Llamadas de método controladas por evento

Si se dan las circunstancias adecuadas, los métodos de programa de control puedenreaccionar ahora ante el desencadenamiento de este evento. Esto significa que elsistema de tiempo de ejecución puede llamar estos métodos de programa decontrol después de que el evento haya sido desencadenado. En otras palabras, elmétodo de programa de control no suele ser llamado directamente por el cliente.

Esto provoca un concepto de modelación completamente diferente: mientras estádesarrollando la clase que desencadena el evento, no necesita saber nada acerca dela clase que lo está tratando. La clase de desencadenamiento envía un mensajeespecífico a todas las clases (y, si es necesario, a sus instancias) del programa enejecución. En el momento del desarrollo, no está en absoluto claro qué tipo deprogramas de control habrá y cuántos de estos van a utilizarse.

Debido a la definición del método de programa de control, el rango de posiblesresultados puede limitarse; pero sólo después de que se haya desencadenado elevento, se podrá determinar el resultado que se obtendrá.

Un evento puede tener parámetros de exportación, lo que significa que, al contrarioque una llamada de método explícita, el programa de llamada determina elprotocolo en este caso.

En este ejemplo de aplicación, después de haberse creado una instancia en laclase de �vehículo�, ésta desencadena el evento �vehículo creado.� Este evento esrecibido por diferentes instancias y se procesa de manera distinta por cada una. Lacompañía de vehículos de alquiler piensa en adquirir un vehículo, mientras que elregistro de matriculación registra el coche, etc.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 193

Page 208: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Atención: No confunda este concepto de eventos en la programaciónorientada a objetos con los eventos en el sistema de tiempo de ejecuciónABAP (LOAD-OF-PROGRAM, START-OF-SELECTION, etc.).Tampoco lo confunda con el procesamiento de fondo ni con el control deworkflow.

Gráfico 99: Tratamiento de eventos en un diagrama de clases UML

En los diagramas de clases UML, una flecha punteada con el estereotipo«handlesEventOf» apunta desde la clase de tratamiento a la clase dedesencadenamiento. La definición de evento y la firma sólo aparecenimplícitamente en la clase de tratamiento dentro del método de programa decontrol. Los métodos de programa de control están separados de los otros métodosmediante el estereotipo «eventHandler».

Desencadenamiento y tratamiento de eventosA continuación se resumen todos los pasos de programación necesarios para elcontrol por eventos. Se explicarán de manera más detallada posteriormente.

194 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 209: TAW12_01

TAW12_1 Lección: Eventos

Gráfico 100: Desencadenamiento y tratamiento de eventos - Resumen

Tenga en cuenta que, dependiendo del status de su aplicación, es posible queno necesite programar todos los pasos. La separación de causa y efecto en suprogramación debería reflejarse en la manera en que construye aplicacionescomplejas. A menudo, el evento ya está desencadenado y todo lo que tiene quehacer es crear otro programa de control de eventos.

Gráfico 101: Definición y desencadenamiento de eventos - Sintaxis

Dentro de una clase, los eventos de instancia se definen utilizando la sentenciaEVENTS, mientras que los eventos estáticos se definen utilizando la sentenciaCLASS-EVENTS.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 195

Page 210: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Los eventos sólo pueden tener parámetros de exportación, que deben transmitirsepor valor como copia.

Una clase o instancia puede desencadenar un evento en tiempo de ejecuciónmediante la sentencia RAISE EVENT. Tanto los eventos de instancia como loseventos estáticos pueden desencadenarse en métodos de instancia. Sólo loseventos estáticos pueden desencadenarse en métodos estáticos.

Cuando se desencadena un evento, los métodos de programa de control que seregistran para este evento se llaman en secuencia. Por supuesto, éstos puedendesencadenar más eventos propios.

Gráfico 102: Eventos de tratamiento - Sintaxis

Los eventos de instancia o los métodos estáticos pueden definirse dentro de unaclase como eventos de tratamiento. Para ello, debe especificar el evento (FOREVENT) y la clase o el interface en el que se definió el evento (OF).

Si el evento contiene parámetros de exportación y desea poder dirigirse aellos sintácticamente, debe haber especificado los parámetros de exportacióninmediatamente después de IMPORTING en la definición del método. La firmadel método de programa de control puede consistir sólo en los parámetros deexportación del evento asociado. Los parámetros se introducen por el método deprograma de control durante la definición del evento. (El objeto que desencadenael evento determina el protocolo.)

Además de los parámetros de exportación definidos explícitamente, el parámetrode importación predefinido SENDER siempre puede enumerarse. Al utilizar esteparámetro, puede situar una referencia al objeto de desencadenamiento de eventoen el método de programa de control.

196 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 211: TAW12_01

TAW12_1 Lección: Eventos

Por lo tanto, los métodos de programa de control se llaman normalmente por partede eventos desencadenados (RAISE EVENT): Sin embargo, también puedenllamarse explícitamente (CALL METHOD).

Registro de eventosLa definición del método de programa de control sólo especifica cómo y paraqué evento de qué clase reacciona el método. En tiempo de ejecución, debedeterminarse qué posibles reacciones tendrán lugar realmente y cuándo seproducirá cada una de ellas.

Al desencadenar eventos de instancia, también se debe especificar qué eventodesencadenará la reacción. Si hay métodos de instancia fijados para que llevena cabo la reacción, también se deberá(n) especificar la(s) instancia(s) queefectuará(n) la reacción

The most common mistake in relation to event control is forgetting the registration.Be sure to explain why the registration is so important.

One way to illustrate this would be to execute your demonstration program withoutthe registration, so that you can show that the registration is a necessary step.

Gráfico 103: Registro de tratamiento de eventos

Estas especificaciones se conocen de manera colectiva como inscripción. Lainscripción siempre se lleva a cabo mediante el desencadenador. Cuandoel evento se desencadena, el tiempo de ejecución utiliza las inscripciones deldesencadenador para determinar qué métodos de programa de control deben serllamados.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 197

Page 212: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

En este ejemplo, se definen los métodos de programa de control para el evento dela clase de vehículo, la clase de vehículo de alquiler y la clase de matriculación devehículo. Sin embargo, sólo es posible predeterminar qué instancias de vehículosde alquiler y qué instancias de matriculación de vehículo reaccionarán ante quéinstancia de vehículo, y cuándo lo harán.

Las inscripciones también pueden ser anuladas.

Gráfico 104: Inscripción del tratamiento de eventos - Sintaxis

Los eventos se registran mediante la sentencia SET HANDLER. La inscripciónsólo está activa durante el tiempo de ejecución del programa.

Con los eventos de instancia, FOR es seguido por la referencia al objeto quedesencadena el evento. De manera alternativa, también se puede utilizar elsuplemento ALL INSTANCES. De esta manera, también es posible registrarobjetos que aún no han sido creados.

El suplementoACTIVATION ’X’ es opcional durante la inscripción.

Para deshacer la inscripción, utiliceACTIVATION ’ ’.

Es posible registrar varios métodos con una sentencia SET-HANDLER:

SET HANDLER ref_handler_1->on_eventname_1 ... ref_handler_n->on_eventname_n

198 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 213: TAW12_01

TAW12_1 Lección: Eventos

Si se han registrado varios métodos en un evento,, la secuencia en la que losmétodos de programa de control se llaman no está definida, es decir, no existeninguna secuencia garantizada en la que se llamen los métodos de programa decontrol.

Si se registra un nuevo programa de control de eventos dentro de un método deprograma de control de eventos para un evento que se acaba de desencadenar, esteprograma de control se añadirá al final de la secuencia y también se ejecutarácuando llegue su turno. Si se deregistra un programa de control de eventosexistente en un método de programa de control de eventos, este programa decontrol se borrará de la secuencia de método de programa de control de eventos.

Gráfico 105: Inscripción/Cancelación de la inscripción: Tablas de programade control

Todo objeto o clase que tiene eventos definidos tiene una tabla interna: la tablade programa de control. Todos los métodos de programa de control que estánregistrados en los eventos se enumeran dentro de esta tabla. Para métodos deinstancia, la tabla de programa de control también contiene referencias a losobjetos registrados.

Los objetos que se registran para el tratamiento de eventos no son eliminados porel recolector de basura si no se conservan referencias hacia ellos.

Your demonstration program should now resemble the executable programSAPBC401_VEHICLE_MAIN_L. You should run your program in debuggingmode.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 199

Page 214: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Secciones de visibilidad en tratamiento de eventosLos eventos también están sujetos al concepto de visibilidad, y pueden ser, por lotanto, públicos, protegidos o privados. Los métodos de programa de control deeventos también tienen atributos de visibilidad.

� La visibilidad de un evento determina el lugar en el que el evento puedeser tratado:

PUBLICTodos

PROTECTEDSólo puede tratarse por parte de usuarios de dentro de esta clase o desus subclases

PRIVATESólo puede tratarse dentro de su clase

� La visibilidad de un método de programa de control controla el lugar enel que puede realizarse la inscripción del método, es decir, las ubicacionesdonde la sentencia SET HANDLER puede ser programada.

PUBLICEn cualquier lugar del programa

PROTECTEDPuede tratarse por parte de usuarios de dentro de esta clase o de sussubclases

PRIVATESólo puede tratarse dentro de su clase

Los métodos de programa de control de eventos sólo pueden tener la mismavisibilidad o una visibilidad más restringida que los eventos a los que hacenreferencia.

Our experience shows that some participants are worried when they finish thislesson, as they feel that event control makes it difficult to follow the programflow by looking at the source code. If these concerns are voiced, repeat thecharacteristics of the event concept and its advantages from the beginning of thelesson. Then point out the significance of modeling and the diagrams.

200 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 215: TAW12_01

TAW12_1 Lección: Eventos

189 Ejercicio 12: Eventos en clases superioresDuración del ejercicio: 40 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Definir y desencadenar eventos� Tratar eventos� Registrar tratamiento de eventos

Ejemplo empresarialLas referencias de aviones y vehículos deben incluirse en las listas de la compañíaaérea y de la compañía de vehículos de alquiler. Este proceso debe estar controladopor eventos.

Tarea 1:Defina un evento para la creación de un avión. Desencadénelo y trátelo de maneraque la referencia al avión se introduzca en la lista de aviones de la compañía aérea.

1. Complete el programa ZBC401_##_MAIN o copie el programaSAPBC401_INTS_MAIN_E (donde ## es su número de grupo de dos cifras).

2. Elimine las llamadas del método ADD_AIRPLANE de su programaprincipal.

Nota: La entrada de una referencia de avión en la lista de compañíasaéreas debe estar controlada por evento.

3. Identifique la clase adecuada para desencadenar el evento y las clases quedeberían utilizarse para tratar el evento. Utilice su diagrama UML si esnecesario.

Si corresponde, ilustre las relaciones en su diagrama UML.

4. Defina el evento público AIRPLANE_CREATED y desencadénelo en laclase LCL_AIRPLANE mediante un método adecuado.

5. Cambie el método ADD_AIRPLANE de la clase LCL_CARRIER por unmétodo de programa de control para el evento que acaba de definir. Deberámodificar tanto la firma como la implementación.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 201

Page 216: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

6. Registre el nuevo método de programa de control, de manera que lacompañía aérea introduzca cada avión que haya sido creado después deél mismo en la lista.

Nota: A pesar de que este modelo no es realista, lo utilizaremosde momento. Más adelante podrá crearse una regla distinta paraintroducir el avión.

7. Observe la ejecución del programa en el ABAP Debugger.

8. ¿Dónde podría ejecutarse la sentencia SET-HANDLER en el ejemploexpuesto? ¿También podría hacerse desde el programa principal? ¿Cuáltendría que ser la sintaxis en este caso?

Tarea 2:Defina un evento para la creación de un vehículo. Desencadénelo y trátelo demanera que la referencia al vehículo se introduzca en la lista de vehículos dela compañía de vehículos de alquiler.

1. Elimine las llamadas del método ADD_VEHICLE de su programa principal.

2. Defina el evento VEHICLE_CREATED y proceda de la misma maneraque en el ejercicio anterior.

202 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 217: TAW12_01

TAW12_1 Lección: Eventos

Solución 12: Eventos en clases superioresTarea 1:Defina un evento para la creación de un avión. Desencadénelo y trátelo de maneraque la referencia al avión se introduzca en la lista de aviones de la compañía aérea.

1. Complete el programa ZBC401_##_MAIN o copie el programaSAPBC401_INTS_MAIN_E (donde ## es su número de grupo de dos cifras).

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

b) Solución modelo: SAPBC401_EVES_MAIN_A

2. Elimine las llamadas del método ADD_AIRPLANE de su programaprincipal.

Nota: La entrada de una referencia de avión en la lista de compañíasaéreas debe estar controlada por evento.

a) Hable con su instructor si tiene cualquier duda.

3. Identifique la clase adecuada para desencadenar el evento y las clases quedeberían utilizarse para tratar el evento. Utilice su diagrama UML si esnecesario.

Si corresponde, ilustre las relaciones en su diagrama UML.

a) Hable con su instructor si tiene cualquier duda.

4. Defina el evento público AIRPLANE_CREATED y desencadénelo en laclase LCL_AIRPLANE mediante un método adecuado.

a) Véase el extracto del código fuente de la solución modelo.

5. Cambie el método ADD_AIRPLANE de la clase LCL_CARRIER por unmétodo de programa de control para el evento que acaba de definir. Deberámodificar tanto la firma como la implementación.

a) Véase el extracto del código fuente de la solución modelo.

6. Registre el nuevo método de programa de control, de manera que lacompañía aérea introduzca cada avión que haya sido creado después deél mismo en la lista.

Nota: A pesar de que este modelo no es realista, lo utilizaremosde momento. Más adelante podrá crearse una regla distinta paraintroducir el avión.

a) Véase el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 203

Page 218: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

7. Observe la ejecución del programa en el ABAP Debugger.

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

8. ¿Dónde podría ejecutarse la sentencia SET-HANDLER en el ejemploexpuesto? ¿También podría hacerse desde el programa principal? ¿Cuáltendría que ser la sintaxis en este caso?

a) SET HANDLER r_vehicle->add_vehicle FOR ALL INSTANCES

Tarea 2:Defina un evento para la creación de un vehículo. Desencadénelo y trátelo demanera que la referencia al vehículo se introduzca en la lista de vehículos dela compañía de vehículos de alquiler.

1. Elimine las llamadas del método ADD_VEHICLE de su programa principal.

a) Véase el extracto del código fuente de la solución modelo.

2. Defina el evento VEHICLE_CREATED y proceda de la misma maneraque en el ejercicio anterior.

a) Hable con su instructor si tiene cualquier duda.

b) Véase el extracto del código fuente de la solución modelo.

.

ResultadoExtracto del código fuente:

SAPBC401_EVES_MAIN_A

REPORT sapbc401_eves_main_a.

TYPE-POOLS icon.

INCLUDE sapbc401_ints_interface.

INCLUDE sapbc401_vehs_opt_event.

INCLUDE sapbc401_eves_a.

INCLUDE sapbc401_ints_agency.

DATA: r_vehicle TYPE REF TO lcl_vehicle,

r_truck TYPE REF TO lcl_truck,

r_bus TYPE REF TO lcl_bus,

r_passenger TYPE REF TO lcl_passenger_plane,

r_cargo TYPE REF TO lcl_cargo_plane,

Continúa en la página siguiente

204 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 219: TAW12_01

TAW12_1 Lección: Eventos

r_carrier TYPE REF TO lcl_carrier,

r_rental TYPE REF TO lcl_rental,

r_agency TYPE REF TO lcl_travel_agency.

START-OF-SELECTION.

*########################

***** Create TRAVEL_AGENCY **************************************

CREATE OBJECT r_agency EXPORTING im_name = ’Fly&Smile Travel’.

***** Create CARRIER ********************************************

CREATE OBJECT r_carrier EXPORTING im_name = ’Smile&Fly Travel’.

***** Passenger Plane ********************************************

* in the constructor of lcl_airplane an event is raised now !

* the passengerairplane is added automatically to lcl_carrier !

CREATE OBJECT r_passenger EXPORTING

im_name = ’LH BERLIN’

im_planetype = ’747-400’

im_seats = 345.

***** cargo Plane ************************************************

* in the constructor of lcl_airplane an event is raised now !

* the cargoairplane is added automatically to lcl_carrier !

CREATE OBJECT r_cargo EXPORTING

im_name = ’US Hercules’

im_planetype = ’747-500’

im_cargo = 533.

***** insert business-parnter of agency into partner_list***********

r_agency->add_partner( r_carrier ).

******* create RENTAL *****************************************

CREATE OBJECT r_rental EXPORTING im_name = ’HAPPY CAR RENTAL’.

******* create truck *****************************************

CREATE OBJECT r_truck EXPORTING im_make = ’MAN’

im_cargo = 45.

******* create truck *****************************************

CREATE OBJECT r_bus EXPORTING im_make = ’Mercedes’

im_passengers = 80.

******* create truck *****************************************

CREATE OBJECT r_truck EXPORTING im_make = ’VOLVO’

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 205

Page 220: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

im_cargo = 48.

***** insert business-parnter of agency into partner_list***********

r_agency->add_partner( r_rental ).

******* show attributes of all partners of travel_agency ******

r_agency->display_agency_partners( ).

SAPBC401_VEHS_OPT_EVENT

*---------------------------------------------------------------------*

* all classes of vehicle-submodel

* the class lcl_vehicle raises event vehicle_created

* *---------------------------------------------------------------------*

*---------------------------------------------------------------------*

* CLASS lcl_vehicle DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_vehicle DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: get_average_fuel IMPORTING im_distance TYPE s_distance

im_fuel TYPE s_capacity

RETURNING value(re_avgfuel) TYPE s_consum.

METHODS constructor IMPORTING im_make TYPE string.

METHODS display_attributes.

METHODS set_make IMPORTING im_make TYPE string.

METHODS get_make EXPORTING ex_make TYPE string.

CLASS-METHODS get_count EXPORTING re_count TYPE i.

EVENTS: vehicle_created.

PRIVATE SECTION.

"-------------------

DATA: make TYPE string.

METHODS init_make.

CLASS-DATA: n_o_vehicles TYPE i.

ENDCLASS. "lcl_vehicle DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_vehicle IMPLEMENTATION

*---------------------------------------------------------------------*

Continúa en la página siguiente

206 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 221: TAW12_01

TAW12_1 Lección: Eventos

CLASS lcl_vehicle IMPLEMENTATION.

METHOD get_average_fuel.

re_avgfuel = im_distance / im_fuel.

ENDMETHOD. "get_average_fuel

METHOD constructor.

make = im_make.

ADD 1 TO n_o_vehicles.

RAISE EVENT vehicle_created.

ENDMETHOD. "constructor

METHOD set_make.

IF im_make IS INITIAL.

init_make( ). " me->init_make( ). also possible

ELSE.

make = im_make.

ENDIF.

ENDMETHOD. "set_make

METHOD init_make.

make = ’default make’.

ENDMETHOD. "init_make

METHOD get_make.

ex_make = make.

ENDMETHOD. "get_make

METHOD display_attributes.

WRITE: make.

ENDMETHOD. "display_attributes

METHOD get_count.

re_count = n_o_vehicles.

ENDMETHOD. "get_count

ENDCLASS. "lcl_vehicle IMPLEMENTATION

*---------------------------------------------------------------------*

* CLASS lcl_truck DEFINITION

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_bus DEFINITION

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 207

Page 222: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_rental DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_rental DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_name TYPE string.

METHODS add_vehicle FOR EVENT vehicle_created OF lcl_vehicle

IMPORTING sender.

METHODS display_attributes.

INTERFACES: lif_partners.

PRIVATE SECTION.

"-------------------

DATA: name TYPE string,

vehicle_list TYPE TABLE OF REF TO lcl_vehicle.

ENDCLASS. "lcl_rental DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_rental IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_rental IMPLEMENTATION.

METHOD lif_partners~display_partner.

display_attributes( ).

ENDMETHOD. "lif_partners~display_partner

METHOD constructor.

name = im_name.

SET HANDLER add_vehicle FOR ALL INSTANCES.

ENDMETHOD. "constructor

METHOD add_vehicle.

APPEND sender TO vehicle_list.

ENDMETHOD. "add_vehicle

METHOD display_attributes.

DATA: r_vehicle TYPE REF TO lcl_vehicle.

WRITE: / icon_transport_proposal AS ICON, name.

WRITE: ’ Here comes the vehicle list: ’. ULINE. ULINE.

LOOP AT vehicle_list INTO r_vehicle.

r_vehicle->display_attributes( ).

Continúa en la página siguiente

208 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 223: TAW12_01

TAW12_1 Lección: Eventos

ENDLOOP.

ENDMETHOD. "display_attributes

ENDCLASS. "lcl_rental IMPLEMENTATION

*---------------------------------------------------------------------*

* CLASS lcl_travel_agency DEFINITION

*---------------------------------------------------------------------*

...

SAPBC401_EVES_A

*&---------------------------------------------------------------------*

*& Include SAPBC401_EVES_A *

*&---------------------------------------------------------------------*

*------------------------------------------------------------------*

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

CLASS lcl_airplane DEFINITION.

PUBLIC SECTION.

"---------------------------------------------

CONSTANTS: pos_1 TYPE i VALUE 30.

METHODS: constructor IMPORTING

im_name TYPE string

im_planetype TYPE saplane-planetype,

display_attributes.

CLASS-METHODS: class_constructor.

CLASS-METHODS: display_n_o_airplanes.

EVENTS airplane_created.

PRIVATE SECTION.

"----------------------------------------------

CLASS-METHODS: get_technical_attributes

IMPORTING im_type TYPE saplane-planetype

EXPORTING ex_weight TYPE s_plan_wei

ex_tankcap TYPE s_capacity.

DATA: name TYPE string,

planetype TYPE saplane-planetype.

CLASS-DATA: n_o_airplanes TYPE i.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 209

Page 224: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

CLASS-DATA: list_of_planetypes TYPE z_00_planetype.

ENDCLASS. "lcl_airplane DEFINITION

*------------------------------------------------------------------*

* CLASS lcl_airplane IMPLEMENTATION *

*------------------------------------------------------------------*

CLASS lcl_airplane IMPLEMENTATION.

METHOD class_constructor.

SELECT * FROM saplane INTO TABLE list_of_planetypes.

ENDMETHOD. "constructor

METHOD constructor.

name = im_name.

planetype = im_planetype.

n_o_airplanes = n_o_airplanes + 1.

RAISE EVENT airplane_created.

ENDMETHOD. "constructor

METHOD display_attributes.

DATA: weight TYPE saplane-weight,

cap TYPE saplane-tankcap.

WRITE: / icon_ws_plane AS ICON,

/ ’Name of Airplane:’(001), AT pos_1 name,

/ ’Type of airplane: ’(002), AT pos_1 planetype.

get_technical_attributes( EXPORTING im_type = planetype

IMPORTING ex_weight = weight

ex_tankcap = cap ).

WRITE: / ’Weight:’(003), weight,

’Tankkap:’(004), cap.

ENDMETHOD. "display_attributes

METHOD display_n_o_airplanes.

WRITE: /, / ’Number of airplanes: ’(ca1),

AT pos_1 n_o_airplanes LEFT-JUSTIFIED, /.

ENDMETHOD. "display_n_o_airplanes

METHOD get_technical_attributes.

DATA: wa TYPE saplane.

READ TABLE list_of_planetypes INTO wa

WITH TABLE KEY planetype = im_type

TRANSPORTING weight tankcap.

ex_weight = wa-weight.

Continúa en la página siguiente

210 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 225: TAW12_01

TAW12_1 Lección: Eventos

ex_tankcap = wa-tankcap.

ENDMETHOD. "get_technical_attributes

ENDCLASS. "lcl_airplane IMPLEMENTATION

*---------------------------------------------------------------------*

* CLASS lcl_cargo_plane DEFINITION

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_passenger_plane DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_carrier DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_carrier DEFINITION.

PUBLIC SECTION.

"----------------------------------------

INTERFACES lif_partners.

METHODS: constructor IMPORTING im_name TYPE string,

get_name RETURNING value(ex_name) TYPE string,

add_airplane FOR EVENT airplane_created OF lcl_airplane

IMPORTING sender,

display_airplanes,

display_attributes.

PRIVATE SECTION.

"-----------------------------------

DATA: name TYPE string,

airplane_list TYPE TABLE OF REF TO lcl_airplane.

ENDCLASS. "lcl_carrier DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_carrier IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_carrier IMPLEMENTATION.

METHOD lif_partners~display_partner.

display_airplanes( ).

ENDMETHOD. "lif_partners~display_partner

METHOD add_airplane.

APPEND sender TO airplane_list.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 211

Page 226: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

ENDMETHOD. "add_airplane

METHOD display_attributes.

WRITE: icon_flight AS ICON, name . ULINE. ULINE.

display_airplanes( ).

ENDMETHOD. "display_attributes

METHOD display_airplanes.

DATA: r_plane TYPE REF TO lcl_airplane.

LOOP AT airplane_list INTO r_plane.

r_plane->display_attributes( ).

ENDLOOP.

ENDMETHOD. "display_airplanes

METHOD constructor.

SET HANDLER add_airplane FOR ALL INSTANCES.

name = im_name.

ENDMETHOD. "constructor

METHOD get_name.

ex_name = name.

ENDMETHOD. "get_name

ENDCLASS. "lcl_carrier IMPLEMENTATION

SAPBC401_INTS_INTERFACE

*&---------------------------------------------------------------------*

*& Include SAPBC401_INTS_INTERFACE *

*&---------------------------------------------------------------------*

* This INTERFACE will be used to access services of classes

* LCL_CARRIER, LCL_RENTAL, LCL_HOTEL, ...

* The client to use these services will be class LCL_TRAVEL_AGENCY

*

INTERFACE lif_partners.

METHODS: display_partner.

ENDINTERFACE. "lif_partners

212 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 227: TAW12_01

TAW12_1 Lección: Eventos

201 Ejercicio 13: Eventos en interfaces(opcional)Duración del ejercicio: 30 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Definir eventos en interfaces� Desencadenar eventos de interface en clases de implementación� Tratar eventos de interface� Registrar tratamiento de eventos

Ejemplo empresarialDeben introducirse las referencias de compañía aérea y de vehículos de alquiler enla lista de la agencia de viajes. Este proceso debe estar controlado por eventos.Asegúrese de crear su programa de manera que pueda ampliarse fácilmentepara gestionar interlocutores comerciales adicionales de la agencia de viajes enel futuro.

Tarea:Defina un evento para la creación de un interlocutor comercial. Desencadénelo ytrátelo de manera que la referencia al interlocutor comercial se introduzca en lalista de interlocutores de la agencia de viajes.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior (donde ## es su número de grupo de dos cifras). )

2. Elimine las llamadas del método ADD_PARTNER de su programa principal.

Nota: La entrada de una referencia de interlocutor comercial en lalista de la agencia de viajes debe estar controlada por evento.

3. Si es necesario, examine su diagrama UML. ¿Qué clase o interface deberíadefinir el evento? ¿Qué clase o interface debería desencadenarlo? ¿Qué claseo interface debería tratarlo?

Si corresponde, ilustre las relaciones en su diagrama UML.

4. Defina el evento PARTNER_CREATED y desencadénelo mediante unmétodo adecuado en la clase que ha seleccionado.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 213

Page 228: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

5. Cambie el método ADD_PARTNER de la clase LCL_TRAVEL_AGENCYpor un método de programa de control para el evento que acaba de definir.Deberá modificar tanto la firma como la implementación.

6. Registre el nuevo método de programa de control, de manera que la agenciade viajes introduzca cada interlocutor comercial que haya sido creadodespués de él mismo en la lista.

Nota: A pesar de que este modelo no es realista, lo utilizaremosde momento. Más adelante podrá crearse una regla distinta paraintroducir el interlocutor comercial.

7. Observe la ejecución del programa en el ABAP Debugger.

214 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 229: TAW12_01

TAW12_1 Lección: Eventos

Solución 13: Eventos en interfaces(opcional)Tarea:Defina un evento para la creación de un interlocutor comercial. Desencadénelo ytrátelo de manera que la referencia al interlocutor comercial se introduzca en lalista de interlocutores de la agencia de viajes.

1. Complete el programa ZBC401_##_MAIN o copie la solución modelo delejercicio anterior (donde ## es su número de grupo de dos cifras). )

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

b) Solución modelo: SAPBC401_EVES_MAIN_B

2. Elimine las llamadas del método ADD_PARTNER de su programa principal.

Nota: La entrada de una referencia de interlocutor comercial en lalista de la agencia de viajes debe estar controlada por evento.

a) Véase el extracto del código fuente de la solución modelo

3. Si es necesario, examine su diagrama UML. ¿Qué clase o interface deberíadefinir el evento? ¿Qué clase o interface debería desencadenarlo? ¿Qué claseo interface debería tratarlo?

Si corresponde, ilustre las relaciones en su diagrama UML.

a) Hable con su instructor si tiene cualquier duda.

4. Defina el evento PARTNER_CREATED y desencadénelo mediante unmétodo adecuado en la clase que ha seleccionado.

a) Véase el extracto del código fuente de la solución modelo.

5. Cambie el método ADD_PARTNER de la clase LCL_TRAVEL_AGENCYpor un método de programa de control para el evento que acaba de definir.Deberá modificar tanto la firma como la implementación.

a) Véase el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 215

Page 230: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

6. Registre el nuevo método de programa de control, de manera que la agenciade viajes introduzca cada interlocutor comercial que haya sido creadodespués de él mismo en la lista.

Nota: A pesar de que este modelo no es realista, lo utilizaremosde momento. Más adelante podrá crearse una regla distinta paraintroducir el interlocutor comercial.

a) Véase el extracto del código fuente de la solución modelo.

7. Observe la ejecución del programa en el ABAP Debugger.

a) Lleve a cabo este paso de la manera habitual. Encontrará informaciónadicional en la biblioteca SAP.

ResultadoExtracto del código fuente:

SAPBC401_EVES_MAIN_B

REPORT sapbc401_eves_main_b.

*&---------------------------------------------------------------------*

*& Implement events in lcl_vehicle and lcl_airplane *

*& Implement events in lcl_carrier and lcl_rental *

*& No "add" methods are needed anymore in the main program ! *

*& Vehicles and Airplanes are added automatically *

*&---------------------------------------------------------------------*

TYPE-POOLS icon.

INCLUDE sapbc401_ints_interface_event.

INCLUDE sapbc401_vehs_event.

INCLUDE sapbc401_eves_b.

INCLUDE sapbc401_ints_agency_handler.

DATA: r_vehicle TYPE REF TO lcl_vehicle,

r_truck TYPE REF TO lcl_truck,

r_bus TYPE REF TO lcl_bus,

r_passenger TYPE REF TO lcl_passenger_plane,

r_cargo TYPE REF TO lcl_cargo_plane,

r_carrier TYPE REF TO lcl_carrier,

r_rental TYPE REF TO lcl_rental,

r_agency TYPE REF TO lcl_travel_agency.

START-OF-SELECTION.

*########################

Continúa en la página siguiente

216 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 231: TAW12_01

TAW12_1 Lección: Eventos

******* create travel_agency *****************************************

CREATE OBJECT r_agency EXPORTING im_name = ’Fly&Smile Travel’.

******* create rental *****************************************

CREATE OBJECT r_rental EXPORTING im_name = ’HAPPY CAR RENTAL’.

******* create truck *****************************************

CREATE OBJECT r_truck EXPORTING im_make = ’MAN’

im_cargo = 45.

******* create truck *****************************************

CREATE OBJECT r_bus EXPORTING im_make = ’Mercedes’

im_passengers = 80.

******* create truck *****************************************

CREATE OBJECT r_truck EXPORTING im_make = ’VOLVO’

im_cargo = 48.

***** Create CARRIER ********************************************

CREATE OBJECT r_carrier EXPORTING im_name = ’Smile&Fly Travel’.

***** Passenger Plane ********************************************

CREATE OBJECT r_passenger EXPORTING

im_name = ’LH BERLIN’

im_planetype = ’747-400’

im_seats = 345.

***** cargo Plane ************************************************

CREATE OBJECT r_cargo EXPORTING

im_name = ’US Hercules’

im_planetype = ’747-500’

im_cargo = 533.

******* show attributes of all partners of travel_agency ******

r_agency->display_agency_partners( ).

SAPBC401_INTS_INTERFACE_EVENT

*&---------------------------------------------------------------------*

*& Include SAPBC401_INTS_INTERFACE_EVENT *

*&---------------------------------------------------------------------*

*---------------------------------------------------------------------*

* an event is defined inside he interface

*---------------------------------------------------------------------*

INTERFACE lif_partners.

METHODS display_partner.

*** the event partner_created can be raised by classes that implement the interface!

*** this also shows the solution of the optional events excercise

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 217

Page 232: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

*** if you solved this additional optional excercise you do not need to

*** call the add_partner methods anymore - congratulation!

EVENTS: partner_created.

ENDINTERFACE. "lif_partners

SAPBC401_VEHS_EVENT

*&---------------------------------------------------------------------*

*& Include SAPBC401_VEHS_EVENT *

*&---------------------------------------------------------------------*

* the definition of LCL_VEHICLE, LCL_TRUCK, LCL_BUS is left out here

* this has been shown several times before

*---------------------------------------------------------------------*

* CLASS lcl_rental DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_rental DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_name TYPE string.

METHODS add_vehicle for event vehicle_created of lcl_vehicle

importing sender.

METHODS display_attributes.

INTERFACES: lif_partners.

PRIVATE SECTION.

"-------------------

DATA: name TYPE string,

vehicle_list TYPE TABLE OF REF TO lcl_vehicle.

ENDCLASS. "lcl_rental DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_rental IMPLEMENTATION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_rental IMPLEMENTATION.

METHOD lif_partners~display_partner.

display_attributes( ).

ENDMETHOD. "lif_partners~display_partner

METHOD constructor.

Continúa en la página siguiente

218 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 233: TAW12_01

TAW12_1 Lección: Eventos

name = im_name.

SET HANDLER add_vehicle FOR ALL INSTANCES.

RAISE EVENT lif_partners~partner_created.

ENDMETHOD. "constructor

METHOD add_vehicle.

APPEND sender TO vehicle_list.

ENDMETHOD. "add_vehicle

METHOD display_attributes.

DATA: r_vehicle TYPE REF TO lcl_vehicle.

skip 2.

WRITE: / icon_transport_proposal AS ICON, name.

WRITE: ’ Here comes the vehicle list: ’. ULINE. ULINE.

LOOP AT vehicle_list INTO r_vehicle.

r_vehicle->display_attributes( ).

ENDLOOP.

ENDMETHOD. "display_attributes

ENDCLASS. "lcl_rental IMPLEMENTATION

SAPBC401_EVES_B

*&---------------------------------------------------------------------*

*& Include SAPBC401_EVES_B *

*&---------------------------------------------------------------------*

*---------------------------------------------------------------------*

* CLASS lcl_carrier DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_carrier DEFINITION.

PUBLIC SECTION.

"----------------------------------------

INTERFACES lif_partners.

METHODS: constructor IMPORTING im_name TYPE string,

get_name RETURNING value(ex_name) TYPE string,

add_airplane FOR EVENT airplane_created OF lcl_airplane

IMPORTING sender,

display_airplanes,

display_attributes.

PRIVATE SECTION.

"-----------------------------------

DATA: name TYPE string,

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 219

Page 234: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

airplane_list TYPE TABLE OF REF TO lcl_airplane.

ENDCLASS. "lcl_carrier DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_carrier IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_carrier IMPLEMENTATION.

METHOD lif_partners~display_partner.

display_attributes( ).

ENDMETHOD. "lif_partners~display_partner

METHOD add_airplane.

APPEND sender TO airplane_list.

ENDMETHOD. "add_airplane

METHOD display_attributes.

SKIP 2.

WRITE: icon_flight AS ICON, name . ULINE. ULINE.

display_airplanes( ).

ENDMETHOD. "display_attributes

METHOD display_airplanes.

DATA: r_plane TYPE REF TO lcl_airplane.

LOOP AT airplane_list INTO r_plane.

r_plane->display_attributes( ).

ENDLOOP.

ENDMETHOD. "display_airplanes

METHOD constructor.

name = im_name.

SET HANDLER add_airplane FOR ALL INSTANCES.

RAISE EVENT lif_partners~partner_created.

ENDMETHOD. "constructor

METHOD get_name.

ex_name = name.

ENDMETHOD. "get_name

ENDCLASS. "lcl_carrier IMPLEMENTATION

SAPBC401_INTS_AGENCY_HANDLER

*&---------------------------------------------------------------------*

Continúa en la página siguiente

220 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 235: TAW12_01

TAW12_1 Lección: Eventos

*& Include SAPBC401_INTS_AGENCY_HANDLER *

*&---------------------------------------------------------------------*

*---------------------------------------------------------------------*

* CLASS lcl_travel_agency DEFINITION

*---------------------------------------------------------------------*

CLASS lcl_travel_agency DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_name TYPE string.

METHODS add_partner FOR EVENT partner_created OF lif_partners

IMPORTING sender.

METHODS display_agency_partners.

PRIVATE SECTION.

"-------------------

DATA: name TYPE string,

partner_list TYPE TABLE OF REF TO lif_partners.

ENDCLASS. "lcl_travel_agency DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_travel_agency IMPLEMENTATION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_travel_agency IMPLEMENTATION.

METHOD display_agency_partners.

DATA: r_partner TYPE REF TO lif_partners.

WRITE: icon_dependents AS ICON, name.

WRITE: ’ Here are the partners of the travel agency: ’.ULINE.ULINE.

LOOP AT partner_list INTO r_partner.

r_partner->display_partner( ).

ENDLOOP.

ENDMETHOD. "display_agency_partners

METHOD constructor.

name = im_name.

SET HANDLER add_partner FOR ALL INSTANCES.

ENDMETHOD. "constructor

METHOD add_partner.

APPEND sender TO partner_list.

ENDMETHOD. "add_partner

ENDCLASS. "lcl_travel_agency IMPLEMENTATION

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 221

Page 236: TAW12_01

Capítulo 2: Conceptos orientados a objetos y técnicas de programación TAW12_1

Resumen de la lección

Ahora podrá:� Definir y desencadenar eventos� Tratar eventos� Registrar y deregistrar el tratamiento de eventos� Explicar las diferencias clave entre llamadas de método explícitas y llamadas

de método controladas por evento

Más informaciónPara más información, véase la biblioteca SAP.

222 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 237: TAW12_01

TAW12_1 Resumen del capítulo

Resumen del capítuloAhora podrá:� Definir relaciones de herencia entre clases� Redefinir métodos� Crear asignaciones up cast (widening cast)� Crear asignaciones down cast (narrowing cast)� Explicar el concepto de polimorfismo en relación con la herencia� Utilizar asignaciones cast con herencia para realizar llamadas genéricas� Definir e implementar interfaces� Implementar métodos de interface� Utilizar referencias de interface para realizar asignaciones up cast� Utilizar referencias de interface para realizar asignaciones down cast� Explicar el término polimorfismo en relación con interfaces� Utilizar asignaciones cast con interfaces para realizar llamadas genéricas� Definir y desencadenar eventos� Tratar eventos� Registrar y deregistrar el tratamiento de eventos� Explicar las diferencias clave entre llamadas de método explícitas y llamadas

de método controladas por evento

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 223

Page 238: TAW12_01

Resumen del capítulo TAW12_1

224 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 239: TAW12_01

TAW12_1 Examine sus conocimientos

213Examine sus conocimientos

1. ¿Cuál es la sintaxis ABAP necesaria para que una subclase local heredede una clase superior?

2. ¿Cuál es la sintaxis ABAP necesaria para redefinir un método heredado enuna clase local?

3. Supongamos que está copiando una referencia de subclase en una variable dereferencia introducida en la clase superior (up cast). ¿A qué componentespuede acceder con esta variable de referencia?Seleccione la(s) respuesta(s) correcta(s).□ A A componentes redefinidos de la clase superior□ B A componentes nuevamente definidos de la subclase□ C A componentes heredados de la clase superior□ D A componentes redefinidos de la subclase

4. Supongamos que una variable de referencia introducida en una clase superiorcontiene una referencia de subclase, y la copia en una variable de referenciaintroducida en la clase (down cast). ¿A cuáles de los siguientes componentespuede tener acceso con esta variable de referencia?Seleccione la(s) respuesta(s) correcta(s).□ A A componentes redefinidos de la clase superior□ B A componentes nuevamente definidos de la subclase□ C A componentes heredados de la clase superior□ D A componentes redefinidos de la subclase

5. ¿Con qué propósito se utiliza la herencia?

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 225

Page 240: TAW12_01

Examine sus conocimientos TAW12_1

6. ¿Un interface tiene una parte de implementación?

7. Supongamos que copia una referencia de instancia de una clase queimplementa un interface en una variable de referencia que está tipificada enel interface (up cast). ¿A qué componentes puede acceder con esta variablede referencia?Seleccione la(s) respuesta(s) correcta(s).□ A A los componentes del interface□ B A los componentes de la clase que no están definidos en el

interface□ C A todos los componentes de la clase□ D A los componentes del interface para los que se han definido

nombres alias

8. Supongamos que una variable de referencia tipificada en un interfacecontiene una referencia de instancia de una clase que implementa esteinterface y que la copia en una variable de referencia que se tipifica en laclase (down cast). ¿A cuáles de los siguientes componentes se puede accedercon esta variable de referencia?Seleccione la(s) respuesta(s) correcta(s).□ A A los componentes del interface□ B A los componentes de la clase que no están definidos en el

interface□ C A todos los componentes de la clase□ D A los componentes del interface para los que se han definido

nombres alias

9. ¿Cuál es la sentencia para definir eventos?

226 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 241: TAW12_01

TAW12_1 Examine sus conocimientos

10. ¿Cuál es la sentencia para desencadenar eventos?

11. ¿Con qué sentencia definiría un método de programa de control M_H parael evento E de la clase C?

12. ¿Con qué sentencia registraría el método de programa de control M_H dela instancia que reacciona REF_H con la instancia de desencadenamientoREF_R?

13. ¿Pueden definirse eventos en interfaces?

14. ¿Pueden desencadenarse eventos en interfaces?

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 227

Page 242: TAW12_01

Examine sus conocimientos TAW12_1

216Respuestas

1. ¿Cuál es la sintaxis ABAP necesaria para que una subclase local heredede una clase superior?

Respuesta: el suplemento INHERITING FROM en la sentenciaCLASS-DEFINITION.

2. ¿Cuál es la sintaxis ABAP necesaria para redefinir un método heredado enuna clase local?

Respuesta: el suplemento REDEFINITION en la sentencia METHODS.

3. Supongamos que está copiando una referencia de subclase en una variable dereferencia introducida en la clase superior (up cast). ¿A qué componentespuede acceder con esta variable de referencia?

Respuesta: A, C

4. Supongamos que una variable de referencia introducida en una clase superiorcontiene una referencia de subclase, y la copia en una variable de referenciaintroducida en la clase (down cast). ¿A cuáles de los siguientes componentespuede tener acceso con esta variable de referencia?

Respuesta: A, B, C

5. ¿Con qué propósito se utiliza la herencia?

Respuesta: Por herencia se entiende la manera cómo las relaciones degeneralización/especialización entre clases se implementan en un programa.

6. ¿Un interface tiene una parte de implementación?

Respuesta: No

Véase la sección relevante de la unidad.

228 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 243: TAW12_01

TAW12_1 Examine sus conocimientos

7. Supongamos que copia una referencia de instancia de una clase queimplementa un interface en una variable de referencia que está tipificada enel interface (up cast). ¿A qué componentes puede acceder con esta variablede referencia?

Respuesta: A

Véase la sección relevante de la unidad.

8. Supongamos que una variable de referencia tipificada en un interfacecontiene una referencia de instancia de una clase que implementa esteinterface y que la copia en una variable de referencia que se tipifica en laclase (down cast). ¿A cuáles de los siguientes componentes se puede accedercon esta variable de referencia?

Respuesta: A, B, C, D

Véase la sección relevante de la unidad.

9. ¿Cuál es la sentencia para definir eventos?

Respuesta: EVENTOS

Véase la sección relevante de la unidad.

10. ¿Cuál es la sentencia para desencadenar eventos?

Respuesta: RAISE EVENT

Véase la sección relevante de la unidad.

11. ¿Con qué sentencia definiría un método de programa de control M_H parael evento E de la clase C?

Respuesta:METHODS m_h FOR EVENT e OF c ... .

Véase la sección relevante de la unidad.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 229

Page 244: TAW12_01

Examine sus conocimientos TAW12_1

12. ¿Con qué sentencia registraría el método de programa de control M_H dela instancia que reacciona REF_H con la instancia de desencadenamientoREF_R?

Respuesta:SET HANDLER ref_h->m_h FOR ref_r.

Véase la sección relevante de la unidad.

13. ¿Pueden definirse eventos en interfaces?

Respuesta: Sí

14. ¿Pueden desencadenarse eventos en interfaces?

Respuesta: No

Véase la sección relevante de la unidad.

230 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 245: TAW12_01

Capítulo 3219 Objetos de Repository orientados a

objetos

This unit represents something of a break in the course flow. Use it to youradvantage. Participants should be freshly motivated by being familiarized withthe new tools and being able to employ their recently acquired knowledge andthe resulting change in method.

Atención: With regards to content, the second lesson would be bettersuited to the previous unit. However, we deliberately chose this alternativesequence so that the singleton demonstration, for example, can be donedirectly in the Class Builder. The optional exercises also assume that theparticipants are able to use the Class Builder.

Do not neglect the third lesson. Even if not all useful components of theTransaction Services are available as yet, the persistence mapping possibilitiesseem to be too limited, or the participants do not think it is relevant, the ABAPWorkbench is still a powerful tool.

Resumen del capítuloLa primera unidad le ofrece una introducción al generador de clases, unaherramienta del Workbench ABAP que no ha utilizado antes. Se centrará enaprender cómo aplicar las técnicas que ha aprendido para clases e interfaseslocales a las clases e interfases globales. Un punto indispensable de esta unidad esla descripción de la manera en que la programación ABAP orientada a objetospuede utilizarse de distintas formas, tal como se muestra en el ejemplo de controlGrid SAP y add-ins empresariales.

Añadiremos unos cuantos detalles más (que se obviaron antes a propósito) para sucomprensión de los conceptos de programación orientados a objetos. Éstos sonválidos tanto para las clases locales como para las globales.

La tercera unidad comprende las posibilidades de generación de clases globalesmuy específicas. A su vez, esta herramienta de generación utiliza el generadorde clases.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 231

Page 246: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Objetivos del capítuloAl finalizar este capítulo podrá:

� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases� Crear interfases mediante el generador de clases� Referenciar clases e interfases globales en otros objetos de Repository� Definir clases abstractas� Definir métodos abstractos� Definir clases finales� Definir métodos finales� Limitar la visibilidad del constructor� Definir relaciones de amistad entre clases� Explicar el �patrón singleton�

Contenido del capítuloLección: Clases e interfases globales... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Procedimiento: Importación de clases e interfases locales.. . . . . . . . . .242Procedimiento: Cómo desplazar la definición de método de una claseglobal a una interfase implementada .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250Demostración: Moving a Method Definition to an Interface.. . . . . . . . . .250Demostración: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251Ejercicio 14: Clases globales .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253Ejercicio 15: Interfases globales.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257Ejercicio 16: Asistente de refactoring (opcional) .. . . . . . . . . . . . . . . . . . . . . .267

Lección: Técnicas de programación especiales orientadas a objetos.. .272Ejercicio 17: Clases singleton (opcional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279Ejercicio 18: Relaciones de amistad (opcional) . . . . . . . . . . . . . . . . . . . . . . . .283

232 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 247: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Lección:221

Clases e interfases globalesDuración de la lección: 180 Minutos

Resumen de la lecciónEsta unidad le ofrece una introducción a una nueva herramienta en el WorkbenchABAP: El generador de clases, que se incluyó en SAP R/3 4.6A al mismo tiempoque los objetos ABAP. Examinaremos sus funciones principales y su integraciónen la Workbench ABAP y, en particular, el Object Navigator.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases� Crear interfases mediante el generador de clases� Referenciar clases e interfases globales en otros objetos de Repository

The participants will not learn any new programming skills in this lesson. Thislesson only serves to introduce new types of Repository objects and the associatedtools.

Once again, you should highlight the strengths of the ABAP Workbench SAPdevelopment environment, particularly in comparison to working with otherprogramming languages. For example, a context-sensitive editor does notnecessarily offer a high-performance, cross-platform, upwardly compatible,actively integrated, and business-oriented application language.

Ejemplo empresarialDesea desarrollar sus clases e interfases como objetos de Repository integradosde manera activa.

Creación de clases e interfases globalesAl igual que las subrutinas, las clases o las interfases locales sólo pueden utilizarsedentro del programa en el que están definidas e implementadas. La sentenciaCLASS es una sentencia declarativa local del programa. De la misma manera quela sentencia TYPES define tipos de datos locales, la sentencia CLASS definetipos de objeto locales.

En ambos casos es irrelevante si el texto fuente se almacena por separado enprogramas de Include.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 233

Page 248: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Por otro lado, las clases globales o las interfases globales son objetos de Repositoryindividuales con todos los atributos normales (integración activa, creación deversiones, sistema de transporte, etc.). La convención de área de nombres (Y*, Z*o un área de nombres de cliente especial) es la misma que la utilizada para el áreade nombres de otros objetos de Repository.

Por ello, está disponible una herramienta especial de actualización en elWorkbench ABAP a partir de SAP R/3 4.6A: el generador de clases.

Be sure to explain the correct use of the Class Builder slowly and in detail.In addition to the presentation, you should show all of the steps in a separatedemonstration class. For instance, you could create the class of airplanes globallyas a demo and then have the participants build houses and hotels in the exercise.They will take to this quite enthusiastically. A further idea: do not perform theinheritance, redefinition and overloading of the constructor yourself, but rather letthe participants discover this themselves in the Class Builder. This was a hugemotivation the first time the course was taught.

The hard copies of the screens used on the slides come from release 6.10/6.20.If you encourage the participants to use the Class Builder, the icon display willbe of no consequence. The knowledge acquired over the last few days will nowbe converted in a global tool, SE24.

Nota: En la siguiente unidad se utilizarán numerosos duplicados depantalla e ilustraciones de pantalla. Tenga en cuenta que el aspecto dealgunos de los iconos o menús depende del release.

En caso de dudas, se recomienda utilizar la quick info (un texto explicativo queaparece cuando se sitúa el cursor encima de un icono y se deja allí durante unosinstantes).

234 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 249: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Gráfico 106: Creación de clases globales en el Object Navigator

Al igual que con otros objetos de Repository, el área de navegación separada delObject Navigator lo convierte en la herramienta ideal para todos los objetosde Repository. También soporta el generador de clases. Al igual que con otrosobjetos de Repository, la manera más fácil de crear una nueva clase global esutilizar el menú contextual en el área de navegación: primero seleccione el nodode paquete o seleccione el propio nodo de clase dentro de un paquete.

Una ventana de diálogo le solicitará que cree otros atributos para la nueva clase:no modifique los atributos por defecto en este lugar. Obtendrá información acercade las diferentes parametrizaciones y de sus efectos más adelante.

Haga lo mismo al crear clases globales.

La clase global o la interfase global se visualizarán en la tabla del generador declases del área de edición del Object Navigator.

Tal como se ha mencionado, algunos iconos o menús podrían ser distintos según elrelease. Cuando se aprende a trabajar en el generador de clases, es recomendableutilizar la quick info.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 235

Page 250: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Gráfico 107: Definición de atributos

Seleccione la etiqueta Atributos para abrir la lista de todas las definiciones deatributo de la clase. En este lugar puede definir nuevos atributos.

Puede utilizar la Ayuda para entradas al definir los atributos de tipo. Utilicedescripciones cortas y con sentido.

Gráfico 108: Definición de métodos

236 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 251: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Seleccione la etiqueta Métodos para abrir la lista de todas las definiciones demétodo de la clase. Puede definir nuevos métodos en ese lugar. Puede utilizar laAyuda para entradas al definir los atributos. Utilice descripciones cortas y consentido.

Existen ventanas de editor separadas para la firma e implementación.

Atención: Finding the signature of methods is often overlooked, or evenforgotten, in the exercises. Demonstrate this several times.

Seleccione el botón Constructor para definir un constructor de instancia. Elnombre de constructor se selecciona automáticamente, y las posibilidades deselección en la ventana del editor para la firma están restringidas adecuadamente.

Consejo: Los métodos se pueden transportar por separado.

Gráfico 109: Definición de firmas de método

En la lista de métodos, seleccione un método y seleccione el botón Parámetropara ir a la actualización de firma. Puede definir nuevos parámetros formalesen este lugar.

Puede utilizar la Ayuda para entradas al definir los atributos. Utilice descripcionescortas y con sentido.

El desplazamiento entre firmas es posible mediante los botones Método anterior oMétodo siguiente. Seleccione el botónMétodos para volver a la lista de métodos.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 237

Page 252: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Gráfico 110: Implementación de métodos

En la lista de métodos, seleccione un método (doble clic) o, si un método ya estáseleccionado, seleccione el botón Código fuente para ir a la actualización del textofuente. Puede implementar las modificaciones en este lugar.

Consejo: Puede visualizar la firma de método seleccionando el botónrelevante.

Gráfico 111: Visualización de la definición de método

238 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 253: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Seleccione Pasar a→ Definición de método si desea modificar los atributos de sumétodo durante la implementación. En este lugar puede definir, por ejemplo, unmétodo de programa de control. Para hacerlo, utilice la etiqueta �Propiedades� enla ventana de diálogo.

Gráfico 112: Definición de componentes mediante el área de navegación

También puede definir atributos, métodos o eventos en el menú contextual delárea de navegación del Object Navigator. Las propiedades se actualizarán en unaventana de diálogo, y no en la tabla que hemos visto antes.

Consejo: Imprima partes seleccionadas del texto fuente mediante Clase→ Imprimir o Método→ Imprimir.

Remind participants of the importance of documentation. They should documentevery class individually as well as the class as a whole.

Las interfases globales se crean de una manera similar a como lo hacen las clasesglobales. Proceda de la manera habitual, utilizando el botón derecho del ratón enel Object Navigator. La convención para fijar nombres es: �IF_� para interfases deSAP y �ZIF_ o YIF_� para interfases definidas por el usuario.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 239

Page 254: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Gráfico 113: Definición de interfases globales

Gráfico 114: Inclusión de interfases globales

Si desea incluir una interfase global en su clase global, deberá introducir elnombre de la interfase en la etiqueta Interfases. Una vez hecho esto, apareceránautomáticamente todos los componentes de la interfase bajo las fichas relevantes,según la convención para fijar nombres y el operador de resolución de interfase.En el ejemplo, la interfase global ZIF_00_PARTNER se incorpora mediante elmétodo DISPLAY_PARTNER. Puede implementar el método haciendo dobleclic en el nombre del método.

240 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 255: TAW12_01

TAW12_1 Lección: Clases e interfases globales

We suggest that you include the interface in your demonstration class later, afterthe first exercise is complete. The focus is on working with the Class Builder, andnot on integrating the class with implemented interface methods in the application;this should happen right at the end. You will have to hold back some of theparticipants here.

Gráfico 115: El entorno de test del generador de clases

Puede realizar tests de clases globales activas:

Los modelos de clase se asignan temporalmente. Las estáticas se asignaninmediatamente, mientras que los componentes de instancia se asignan cuando seselecciona el botón Instancia.

El sistema lista únicamente los componentes públicos. Es posible realizar testsde los métodos mediante el icono Ejecutar método.

Se pueden realizar tests del desencadenamiento de eventos en una clase de lamanera siguiente:

1. Seleccione un evento.2. Seleccione programa de control. Esto registra un método estándar para el

evento.3. Llame un método en el que se haya implementado el desencadenador de

eventos.

El evento desencadenado y todos los parámetros actuales exportados sevisualizarán en una lista.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 241

Page 256: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

229Importación de clases e interfases localesUtilizaciónEl procedimiento es una manera fácil de realizar copias globales de clases einterfases locales.

Consejo: Esta función no puede utilizarse desde elOBJECT-NAVIGATOR.

Procedimiento1. En el SAP Easy Access Menu seleccione Herramientas→ Workbench ABAP

→ Desarrollo→ Generador de clases o llame la transacción SE24.

2. Desde la pantalla inicial de SE24, seleccione Tipo de objeto→ Importar→Clases de programa local.

3. Introduzca el nombre del programa principal y, si las clases y las interfaseslocales fueron definidas dentro de programas de Include, seleccioneExpandir Includes.

4. Seleccione Visualizar clases/interfases.

5. Introduzca nombres para las clases e interfases globales que desee crear.Tenga en cuenta el área de nombres de cliente, si corresponde.

6. Seleccione las clases e interfases globales que desee crear y accione elbotón Importar.

Gráfico 116: Importación de una clase de programa local

242 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 257: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Otras funciones del generador de clasesLas relaciones de herencia entre clases globales se ordenan en la tabla Propiedades.

Gráfico 117: Definición de una relación de herencia

Es posible especificar una clase superior después de seleccionar Clase superior.En este ejemplo, la subclase ZCL_CARGO_PLANE_00 heredará de la clasesuperior ZCL_AIRPLANE_00.

Gráfico 118: Cómo redefinir un método heredado

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 243

Page 258: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Para redefinir un método heredado, seleccione el método relevante en la lista yseleccione el botón Redefinir. Como alternativa, puede utilizar el menú contextualen el área de navegación.

Nota: Tenga en cuenta que el aspecto de algunos de los iconos o menúsdepende del release. El icono para redefinir métodos es un ejemplo de esto.

Consejo: Creación del constructor en la subclase:para definir elconstructor en la subclase, haga clic en el botón CONSTRUCTOR de labarra de herramientas de la aplicación. El sistema le propondrá en ese casotransferir la firma del constructor de clase superior. Esto es útil cuando sedesea crear el constructor de subclase. Es posible que aquí se deban añadiralgunos parámetros. Asimismo, ya encontrará la llamada del constructorde clase superior en la implementación del constructor de subclase.

Gráfico 119: Definición de un tipo local

Puede definir tipos locales en clases globales. Esto incluye clases locales enparticular.

Técnicamente, no está definiendo una clase dentro de una clase, sino una clase quees local en el objeto de Repository de la clase global.

Todos los componentes de la clase global tienen acceso a estos tipos locales, peroestán encapsulados si se intenta acceder a ellos desde el exterior.

Esto también es válido para interfases locales en clases globales.

Para tratar las partes de implementación de estas clases locales, seleccione elbotón Impl. (para Implementaciones de clase local).

244 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 259: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Gráfico 120: Visualización estructurada de componentes heredados

Para mejorar la comprensión de los componentes de herencia e interfase, esposible fijar el indicador Agrupar por clases e interfases en las Parametrizacionesespecíficas de usuario del generador de clases. El sistema visualizará entonces loscomponentes de la clase global en un grupo.

Gráfico 121: Clasificación de la visualización de componentes de clasesglobales

También es posible clasificar todos los componentes según cinco criterios en tresniveles. Para ello, visualice la ventana de diálogo adecuada seleccionando elbotón Clasificar.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 245

Page 260: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Adición de clases globales mediante el editor ABAPComo otros objetos de Repository, las clases y las interfases globales se añadenal área de navegación del OBJECT-NAVIGATOR.

Be sure to demonstrate the following editing possibilities, ideally using the globaldemonstration class that you just created.

Show both possibilities: Drag and drop and the Pattern button.

Gráfico 122: Separación de áreas de navegación y tratamiento del ObjectNavigator.

De esta manera, las ventajas expuestas anteriormente también son válidas paratrabajar con clases e interfases globales.

246 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 261: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Gráfico 123: Instanciación de objeto mediante la función de arrastrar y soltar

En el área de navegación, seleccione un nombre de clase y arrástrelo al área detratamiento manteniendo pulsado el botón izquierdo del ratón. De este modo secrea un sentencia CREATE OBJECT. A continuación deberá añadir la variable dereferencia y los parámetros actuales, si conviene, a la sentencia.

De manera alternativa, también puede pulsar el botón Patrón. La sentenciaCREATE-OBJECT se encuentra en ABAP Objects Pattern. Puede generar lasentencia mediante la Ayuda para entradas.

Gráfico 124: Llamadas de método mediante la función de arrastrar y soltar.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 247

Page 262: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

En el área de navegación, seleccione un nombre de método y arrástrelo al área detratamiento manteniendo pulsado el botón izquierdo del ratón. De este modo secrea un sentencia CREATE METHOD. A continuación deberá añadir la variablede referencia y los parámetros actuales, si conviene, a la sentencia.

De manera alternativa, también puede pulsar el botón Patrón. La sentenciaCALL-METHOD se encuentra en ABAP Objects Pattern. Puede generar lasentencia mediante la Ayuda para entradas.

Nota: A partir de SAP NW AS 7.0, puede pasar al estilo de escriturafuncional moderno al generar llamadas de método. Siga la vía de accesoUtilidades -> Parametrizaciones -> Patrón y seleccione la casilla deselección �Estilo de escritura funcional para método de llamada�.

Optionally, you can prepare the participants for the next exercise by including theglobal interface in the global class and adapting the demonstration program to usethe global interface. This step may not be necessary for more able groups ofparticipants.

Make sure you take advantage of the positive motivational effect at the endof the exercise: Again, this should show the participants how easy it is toextend object-oriented software applications if they have been modeled well andconsistently.

El asistente de refactoringEn un caso ideal, todas las clases, interfases y asociaciones entre ellasse modelarían por completo mediante diagramas UML antes de que losprogramadores empezaran a implementarlas. Sin embargo, en algunos casos,el modelo se debe adaptar durante la fase de implementación. El Asistente derefactoring ofrece un abanico de opciones útiles para que el usuario puedamodificar los objetos de Repository creados anteriormente. Por ejemplo, puedeutilizar el Asistente de refactoring para desplazar los componentes de una clasedentro de la jerarquía de herencia. Para obtener una lista completa de las funcionesde esta herramienta, véase la biblioteca SAP.

Trabajar con la herramienta es sencillo, ya se basa en diálogos de arrastrar y soltar.

248 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 263: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Gráfico 125: Cómo trabajar con el asistente de refactoring

Consejo: El botón Info de herramienta abre el artículo de la bibliotecaSAP acerca del asistente de refactoring. Aquí encontrará también lasdescripciones del resto de opciones que ofrece la herramienta.

Generalmente, el usuario no ajusta la implementación de métodos, ya que nopuede saber hasta qué punto tendrá que modificar las referencias de objetosdespués de realizar estos cambios.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 249

Page 264: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

237Cómo desplazar la definición de método de una claseglobal a una interfase implementada

1. Cambie al modo de tratamiento de una clase global que implementa unainterfase global.

2. Seleccione Herramientas→ Asistente de refactoring.

3. En la estructura de árbol que aparece, abra la carpeta para el método quedesee desplazar y para el destino: en este caso, la interfase implementada.

4. Desplace el método a la interfase.

5. Grabe su trabajo.

6. Es posible que también necesite adaptar sentencias que llaman el métodoen el código fuente.

7. Active tanto la clase como la interfase.

Demostración: Moving a Method Definition to anInterface

Objetivo

This section demonstrates the correct use of the Refactoring Assistant. This is alsoa good time to point out how easy it is to connect to the SAP Library.

Datos del sistemaSistema: Will be assignedMandante: Will be assignedID de usuario: Will be assignedClave de acceso: Will be assignedParametrizaciones del sistema: No special settings required if you are using astandard SAP Web AS 6.20 training system1. Either copy the global class CL_BC401_BOOT_CALL_METHOD and

global interface IF_BC401_BOOT_EMPTY, or create your own equivalentobjects.

2. Analyze and activate the copy of the interface (which is currently empty).

Adapt the copy of the class: Change the interfaces list to include the nameof the copy of the interface.

Analyze, activate, and test the copy of the class.

3. Open the Refactoring Assistant and refer to the SAP Library.

Move the SEND_MESSAGE method from the class to the interface usingdrag and drop.

250 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 265: TAW12_01

TAW12_1 Lección: Clases e interfases globales

4. Save your work and point out the message texts.

5. Look at the interface: The method definition has been inserted.

6. Activate the interface.

7. Look at the class: The method definition has been adapted.

Atención: Adapt the SEND_MESSAGE method in the CALLERmethod.

8. Activate and test the class.

9. Sample objects in package BC401:

� Global class CL_BC401_BOOD_CALL_METHOD� Global interface IF_BC401_BOOD_EMPTY

Consejo: Alternatively, as a more simple solution you could also createthe ZCL_##_HOUSE class and then create the ZCL_##_HOTEL class asa subclass. The hotel could then be integrated into the application.

Demostración:

Objetivo

Datos del sistemaSistema: Will be assignedMandante: Will be assignedID de usuario: Will be assignedClave de acceso: Will be assignedParametrizaciones del sistema:1.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 251

Page 266: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

252 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 267: TAW12_01

TAW12_1 Lección: Clases e interfases globales

239 Ejercicio 14: Clases globalesDuración del ejercicio: 40 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases

Ejemplo empresarialCree una clase global para representar hoteles.

Tarea 1:Cree una clase global para hoteles.

1. Cree la clase global ZCL_##_HOTEL. (## es el número de grupo de doscifras). )

2. Defina los siguientes atributos en la clase:

NOMBRE del tipoSTRING

como un atributo deinstancia privado

MAX_BEDS del tipo I como un atributo deinstancia privado

N_O_HOTELS del tipo I como un atributo estáticoprivado

Actualice los textos breves.

3. Defina los siguientes métodos en la clase:

CONSTRUCTOR Constructor de instancia paraparametrizar los atributos privadoscon los parámetros de importaciónIM_NAME y IM_BEDS

DISPLAY_ATTRIBUTES Método de instancia para visualizaratributos en una lista ABAP

DISPLAY_N_O_HOTELS Método estático para visualizar elnúmero de instancias de hotel creadas enuna lista ABAP

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 253

Page 268: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Actualice los textos breves.

Tarea 2:Verifique su trabajo.

1. Active su clase.

2. Verifique la clase en el entorno de test del generador de clases.

254 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 269: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Solución 14: Clases globalesTarea 1:Cree una clase global para hoteles.

1. Cree la clase global ZCL_##_HOTEL. (## es el número de grupo de doscifras). )

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Solución modelo: CL_HOTEL

Atención: Si copia esta solución modelo, deberá eliminarla relación de herencia con la clase global CL_HOUSE y lainterfase global IF_PARTNERS.

2. Defina los siguientes atributos en la clase:

NOMBRE del tipoSTRING

como un atributo deinstancia privado

MAX_BEDS del tipo I como un atributo deinstancia privado

N_O_HOTELS del tipo I como un atributo estáticoprivado

Actualice los textos breves.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

3. Defina los siguientes métodos en la clase:

CONSTRUCTOR Constructor de instancia paraparametrizar los atributos privadoscon los parámetros de importaciónIM_NAME y IM_BEDS

DISPLAY_ATTRIBUTES Método de instancia para visualizaratributos en una lista ABAP

DISPLAY_N_O_HOTELS Método estático para visualizar elnúmero de instancias de hotel creadas enuna lista ABAP

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 255

Page 270: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Actualice los textos breves.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

Tarea 2:Verifique su trabajo.

1. Active su clase.

a) Realice este paso de la forma habitual. Encontrará informaciónadicional en la biblioteca SAP.

2. Verifique la clase en el entorno de test del generador de clases.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

256 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 271: TAW12_01

TAW12_1 Lección: Clases e interfases globales

243 Ejercicio 15: Interfases globalesDuración del ejercicio: 30 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Describir las funciones del generador de clases� Crear interfases mediante el generador de clases� Referenciar clases/interfases globales en otros objetos de Repository

Ejemplo empresarialAñada un hotel como nuevo interlocutor comercial en su programa de gestiónde interlocutores comerciales de una agencia de viajes. Sustituya la interfaselocal que ha estado utilizando por una global, de manera que también pueda serimplementada por la clase de hotel global.

Datos del sistemaSistema: Will be assignedMandante: Will be assignedID de usuario: Will be assignedClave de acceso: Will be assignedParametrizaciones del sistema: No special settings are required if you are usinga standard SAP Web AS 6.20 system.

Tarea 1:Cree una interfase global para el acceso generalizado a instancias de interlocutorcomercial.

1. Si conviene, cambie el nombre de interfase en su diagrama UML porZIF_##_PARTNERS. (## es el número de grupo de dos cifras). )

2. Cree la interfase global ZIF_##_PARTNERS.

Defina el método de instancia DISPLAY_PARTNER y el evento de instanciaPARTNER_CREATED en la interfase.

Consejo: Importe la interfase local desde su programaZBC401_##_MAIN o desde la solución modelo de la lecciónanterior SAPBC401_EVES_MAIN_B.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 257

Page 272: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Tarea 2:Deje que la clase de hotel implemente la interfase.

1. Si es necesario, añada la clase ZCL_##_HOTEL a su diagrama UML.Debería implementar el método de interfase DISPLAY_PARTNER ydesencadenar el evento de instancia PARTNER_CREATED. Dibuje lasrelaciones en su diagrama.

2. Incluya la interfase en su clase de hotel.

3. Implemente el método de interfase de manera que se llame el método deinstancia DISPLAY_ATTRIBUTES del hotel.

4. a) Si no ha realizado el ejercicio opcional sobre eventos, incluya la referenciade su objeto de hotel en la lista de interlocutores de la agencia de viajes conel método ADD_PARTNER. (Ya lo ha hecho con la compañía aérea y conla de vehículos de alquiler). b) Si ha realizado el ejercicio opcional sobreeventos, desencadene el evento de interfase en el constructor para la clasede hotel. Al hacer esto, ya no tendrá que llamar explícitamente el métodoADD_PARTNER.

Tarea 3:Añada una instancia de su clase de hotel global a su programa principal.

1. Complete su programa ZBC401_##_MAIN o copie el programaSAPBC401_EVES_MAIN_B (donde ## es su número de grupo de doscifras). )

2. Elimine la definición de la interfase local y adapte todos los lugares donde seutilizó para que se ajuste a la nueva interfase global.

3. Defina una variable de referencia, especifique su clase de hotel global comoel tipo y cree una instancia.

4. Ejecute su programa. Si lo ha hecho todo correctamente, los atributosde hotel también deberían visualizarse ahora en la lista. Si no es así, eldebugging es la mejor manera de analizar los errores producidos.

258 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 273: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Solución 15: Interfases globalesTarea 1:Cree una interfase global para el acceso generalizado a instancias de interlocutorcomercial.

1. Si conviene, cambie el nombre de interfase en su diagrama UML porZIF_##_PARTNERS. (## es el número de grupo de dos cifras). )

a) Hable con su instructor si tiene cualquier duda.

2. Cree la interfase global ZIF_##_PARTNERS.

Defina el método de instancia DISPLAY_PARTNER y el evento de instanciaPARTNER_CREATED en la interfase.

Consejo: Importe la interfase local desde su programaZBC401_##_MAIN o desde la solución modelo de la lecciónanterior SAPBC401_EVES_MAIN_B.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

c) Nombre sugerido: IF_PARTNERS

Tarea 2:Deje que la clase de hotel implemente la interfase.

1. Si es necesario, añada la clase ZCL_##_HOTEL a su diagrama UML.Debería implementar el método de interfase DISPLAY_PARTNER ydesencadenar el evento de instancia PARTNER_CREATED. Dibuje lasrelaciones en su diagrama.

a) Hable con su instructor si tiene cualquier duda.

2. Incluya la interfase en su clase de hotel.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 259

Page 274: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

3. Implemente el método de interfase de manera que se llame el método deinstancia DISPLAY_ATTRIBUTES del hotel.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

4. a) Si no ha realizado el ejercicio opcional sobre eventos, incluya la referenciade su objeto de hotel en la lista de interlocutores de la agencia de viajes conel método ADD_PARTNER. (Ya lo ha hecho con la compañía aérea y conla de vehículos de alquiler). b) Si ha realizado el ejercicio opcional sobreeventos, desencadene el evento de interfase en el constructor para la clasede hotel. Al hacer esto, ya no tendrá que llamar explícitamente el métodoADD_PARTNER.

a) Realice este paso de la forma habitual. Para más información, consultela biblioteca SAP.

Tarea 3:Añada una instancia de su clase de hotel global a su programa principal.

1. Complete su programa ZBC401_##_MAIN o copie el programaSAPBC401_EVES_MAIN_B (donde ## es su número de grupo de doscifras). )

a) Realice este paso de la forma habitual. Para más información, consultela biblioteca SAP.

b) Solución modelo: SAPBC401_CLSS_MAIN_A

2. Elimine la definición de la interfase local y adapte todos los lugares donde seutilizó para que se ajuste a la nueva interfase global.

a) Consulte el extracto del código fuente de la solución modelo.

3. Defina una variable de referencia, especifique su clase de hotel global comoel tipo y cree una instancia.

a) Consulte el extracto del código fuente de la solución modelo.

4. Ejecute su programa. Si lo ha hecho todo correctamente, los atributosde hotel también deberían visualizarse ahora en la lista. Si no es así, eldebugging es la mejor manera de analizar los errores producidos.

a) Realice este paso de la forma habitual. Para más información, consultela biblioteca SAP.

ResultadoCódigo fuente:

Continúa en la página siguiente

260 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 275: TAW12_01

TAW12_1 Lección: Clases e interfases globales

SAPBC401_CLSS_MAIN_A

REPORT sapbc401_clss_main_a.

TYPES: ty_fuel TYPE p DECIMALS 2,

ty_cargo TYPE p DECIMALS 2.

TYPE-POOLS icon.

INCLUDE sapbc401_vehd_j.

INCLUDE sapbc401_clss_a.

DATA: r_vehicle TYPE REF TO lcl_vehicle,

r_truck TYPE REF TO lcl_truck,

r_bus TYPE REF TO lcl_bus,

r_passenger TYPE REF TO lcl_passenger_plane,

r_cargo TYPE REF TO lcl_cargo_plane,

r_carrier TYPE REF TO lcl_carrier,

r_rental TYPE REF TO lcl_rental,

r_agency TYPE REF TO lcl_travel_agency,

r_hotel TYPE REF TO cl_hotel.

START-OF-SELECTION.

*########################

******* create travel_agency *****************************************

CREATE OBJECT r_agency EXPORTING im_name = ’Fly&Smile Travel’.

******* create rental *****************************************

CREATE OBJECT r_rental EXPORTING im_name = ’HAPPY CAR RENTAL’.

* fires event PARTNER_CREATED in rental to add partner to partnerlist

******* create truck *****************************************

CREATE OBJECT r_truck EXPORTING im_make = ’MAN’

im_cargo = 45.

******* create truck *****************************************

CREATE OBJECT r_bus EXPORTING im_make = ’Mercedes’

im_passengers = 80.

******* create truck *****************************************

CREATE OBJECT r_truck EXPORTING im_make = ’VOLVO’

im_cargo = 48.

***** Create CARRIER ********************************************

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 261

Page 276: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

CREATE OBJECT r_carrier EXPORTING im_name = ’Smile&Fly Travel’.

* fires event PARTNER_CREATED in carrier to add partner to partnerlist

***** Passenger Plane ********************************************

CREATE OBJECT r_passenger EXPORTING

im_name = ’LH BERLIN’

im_planetype = ’747-400’

im_seats = 345.

***** cargo Plane ************************************************

CREATE OBJECT r_cargo EXPORTING

im_name = ’US Hercules’

im_planetype = ’747-500’

im_cargo = 533.

******* create hotel *****************************************

CREATE OBJECT r_hotel EXPORTING im_name = ’Holiday Inn’

im_beds = 345.

* fires event PARTNER_CREATED in hotel to add partner to partnerlist

******* show attributes of all partners of travel_agency ******

r_agency->display_agency_partners( ).

SAPBC401_VEHD_J

*&---------------------------------------------------------------------*

*& Include SAPBC401_VEHD_J *

*&---------------------------------------------------------------------*

*---------------------------------------------------------------------*

* work with the global interface if_hotel

*---------------------------------------------------------------------*

*---------------------------------------------------------------------*

* CLASS lcl_vehicle DEFINITION

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_truck DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_bus DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

Continúa en la página siguiente

262 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 277: TAW12_01

TAW12_1 Lección: Clases e interfases globales

...

*---------------------------------------------------------------------*

* CLASS lcl_rental DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_rental DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_name TYPE string.

METHODS add_vehicle FOR EVENT vehicle_created OF lcl_vehicle

IMPORTING sender.

METHODS display_attributes.

INTERFACES: if_partners.

PRIVATE SECTION.

"-------------------

DATA: name TYPE string,

vehicle_list TYPE TABLE OF REF TO lcl_vehicle.

ENDCLASS. "lcl_rental DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_rental IMPLEMENTATION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_rental IMPLEMENTATION.

METHOD if_partners~display_partner.

display_attributes( ).

ENDMETHOD. "lif_partners~display_partner

METHOD constructor.

name = im_name.

SET HANDLER add_vehicle FOR ALL INSTANCES.

RAISE EVENT if_partners~partner_created.

ENDMETHOD. "constructor

METHOD add_vehicle.

APPEND sender TO vehicle_list.

ENDMETHOD. "add_vehicle

METHOD display_attributes.

DATA: r_vehicle TYPE REF TO lcl_vehicle.

skip 2.

WRITE: / icon_transport_proposal AS ICON, name.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 263

Page 278: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

WRITE: ’ Here comes the vehicle list: ’. ULINE. ULINE.

LOOP AT vehicle_list INTO r_vehicle.

r_vehicle->display_attributes( ).

ENDLOOP.

ENDMETHOD. "display_attributes

ENDCLASS. "lcl_rental IMPLEMENTATION

*---------------------------------------------------------------------*

* CLASS lcl_travel_agency DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_travel_agency DEFINITION.

PUBLIC SECTION.

"-------------------

METHODS: constructor IMPORTING im_name TYPE string.

METHODS add_partner FOR EVENT partner_created OF if_partners

IMPORTING sender.

METHODS display_agency_partners.

PRIVATE SECTION.

"-------------------

DATA: name TYPE string,

partner_list TYPE TABLE OF REF TO if_partners.

ENDCLASS. "lcl_travel_agency DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_travel_agency IMPLEMENTATION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_travel_agency IMPLEMENTATION.

METHOD display_agency_partners.

DATA: r_partner TYPE REF TO if_partners.

WRITE: icon_dependents AS ICON, name.

WRITE: ’ Here are the partners of the travel agency: ’.ULINE.ULINE.

LOOP AT partner_list INTO r_partner.

r_partner->display_partner( ).

ENDLOOP.

ENDMETHOD. "display_agency_partners

METHOD constructor.

name = im_name.

Continúa en la página siguiente

264 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 279: TAW12_01

TAW12_1 Lección: Clases e interfases globales

SET HANDLER add_partner FOR ALL INSTANCES.

ENDMETHOD. "constructor

METHOD add_partner.

APPEND sender TO partner_list.

ENDMETHOD. "add_partner

ENDCLASS. "lcl_travel_agency IMPLEMENTATION

SAPBC401_CLSS_A

*------------------------------------------------------------------*

* INCLUDE SAPBC401_CLSS_A

*------------------------------------------------------------------*

* work with interface if_partners

* implement and raise events in lcl_carrier

*------------------------------------------------------------------*

* CLASS lcl_airplane DEFINITION *

*------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_cargo_plane DEFINITION

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_passenger_plane DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

...

*---------------------------------------------------------------------*

* CLASS lcl_carrier DEFINITION

*---------------------------------------------------------------------*

*

*---------------------------------------------------------------------*

CLASS lcl_carrier DEFINITION.

PUBLIC SECTION.

"----------------------------------------

INTERFACES if_partners.

METHODS: constructor IMPORTING im_name TYPE string,

get_name RETURNING value(ex_name) TYPE string,

add_airplane FOR EVENT airplane_created OF lcl_airplane

IMPORTING sender,

display_airplanes,

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 265

Page 280: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

display_attributes.

PRIVATE SECTION.

"-----------------------------------

DATA: name TYPE string,

airplane_list TYPE TABLE OF REF TO lcl_airplane.

ENDCLASS. "lcl_carrier DEFINITION

*---------------------------------------------------------------------*

* CLASS lcl_carrier IMPLEMENTATION

*---------------------------------------------------------------------*

CLASS lcl_carrier IMPLEMENTATION.

METHOD if_partners~display_partner.

display_attributes( ).

ENDMETHOD. "lif_partners~display_partner

METHOD add_airplane.

APPEND sender TO airplane_list.

ENDMETHOD. "add_airplane

METHOD display_attributes.

SKIP 2.

WRITE: icon_flight AS ICON, name . ULINE. ULINE.

display_airplanes( ).

ENDMETHOD. "display_attributes

METHOD display_airplanes.

DATA: r_plane TYPE REF TO lcl_airplane.

LOOP AT airplane_list INTO r_plane.

r_plane->display_attributes( ).

ENDLOOP.

ENDMETHOD. "display_airplanes

METHOD constructor.

name = im_name.

SET HANDLER add_airplane FOR ALL INSTANCES.

RAISE EVENT if_partners~partner_created.

ENDMETHOD. "constructor

METHOD get_name.

ex_name = name.

ENDMETHOD. "get_name

ENDCLASS. "lcl_carrier IMPLEMENTATION

266 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 281: TAW12_01

TAW12_1 Lección: Clases e interfases globales

253 Ejercicio 16: Asistente de refactoring(opcional)Duración del ejercicio: 15 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases

Ejemplo empresarialTrabajo práctico con el asistente de refactoring.

Tarea 1:Defina una clase superior global para casas y deje que su clase de hotel herede deella.

1. Si es necesario, añada la clase ZCL_##_HOUSE a su diagrama UML. (## esel número de grupo de dos cifras). )

Definirá el atributo NAME y el método DISPLAY_ATTRIBUTES. La claseZCL_##_HOTEL heredará de él. Dibuje las relaciones en su diagrama.

2. Cree la clase global ZCL_##_HOTEL y déjela vacía.

3. Defina una relación de herencia para que ZCL_##_HOUSE sea la clasesuperior y ZCL_##_HOTEL la subclase.

Tarea 2:Desplace los componentes generales de la clase ZCL_##_HOTEL a la clasesuperior.

1. Utilice el asistente de refactoring para desplazar el atributo NAME, elconstructor de instancia y el método DISPLAY_ATTRIBUTES a la claseZCL_##_HOUSE.

2. Adapte la firma y la implementación del constructor de instancia en la clasesuperior.

3. Adapte la implementación del método DISPLAY_ATTRIBUTES en la clasesuperior.

4. Defina el constructor de instancia para la subclase.

5. Redefina el método DISPLAY_ATTRIBUTES en la subclase.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 267

Page 282: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

6. Observe la ejecución del programa en el ABAP Debugger.

Si ha realizado todos los pasos correctamente, la visualización de la listadebería ser la misma que en el ejercicio anterior.

268 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 283: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Solución 16: Asistente de refactoring(opcional)Tarea 1:Defina una clase superior global para casas y deje que su clase de hotel herede deella.

1. Si es necesario, añada la clase ZCL_##_HOUSE a su diagrama UML. (## esel número de grupo de dos cifras). )

Definirá el atributo NAME y el método DISPLAY_ATTRIBUTES. La claseZCL_##_HOTEL heredará de él. Dibuje las relaciones en su diagrama.

a) Hable con su instructor si tiene cualquier duda.

2. Cree la clase global ZCL_##_HOTEL y déjela vacía.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

c) Solución modelo: CL_HOUSE

3. Defina una relación de herencia para que ZCL_##_HOUSE sea la clasesuperior y ZCL_##_HOTEL la subclase.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

Tarea 2:Desplace los componentes generales de la clase ZCL_##_HOTEL a la clasesuperior.

1. Utilice el asistente de refactoring para desplazar el atributo NAME, elconstructor de instancia y el método DISPLAY_ATTRIBUTES a la claseZCL_##_HOUSE.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 269

Page 284: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

2. Adapte la firma y la implementación del constructor de instancia en la clasesuperior.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

3. Adapte la implementación del método DISPLAY_ATTRIBUTES en la clasesuperior.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

4. Defina el constructor de instancia para la subclase.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

5. Redefina el método DISPLAY_ATTRIBUTES en la subclase.

a) Siga los procesos tal como se indica en la sección relevante de estaunidad.

b) Hable con su instructor si tiene cualquier duda.

6. Observe la ejecución del programa en el ABAP Debugger.

Si ha realizado todos los pasos correctamente, la visualización de la listadebería ser la misma que en el ejercicio anterior.

a) Realice este paso de la forma habitual. Para más información, consultela biblioteca SAP.

270 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 285: TAW12_01

TAW12_1 Lección: Clases e interfases globales

Resumen de la lección

Ahora podrá:� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases� Crear interfases mediante el generador de clases� Referenciar clases e interfases globales en otros objetos de Repository

Más informaciónEncontrará información acerca de este tema en la biblioteca SAP.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 271

Page 286: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Lección:258

Técnicas de programación especiales orientadas aobjetosDuración de la lección: 60 Minutos

Resumen de la lecciónEn esta unidad completará sus conocimientos acerca de la programación orientadaa objetos. Los conceptos introducidos aquí son válidos para otros lenguajes deprogramación orientados a objetos, de la misma manera o de manera similar.Pueden utilizarse libremente en objetos ABAP, tanto con clases locales comoglobales.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Definir clases abstractas� Definir métodos abstractos� Definir clases finales� Definir métodos finales� Limitar la visibilidad del constructor� Definir relaciones de amistad entre clases� Explicar el �patrón singleton�

The first two sections are mostly intended to complete the participants�understanding of ABAP Objects. Go into more depth towards the end of thislesson.

Ejemplo empresarialDesea añadir técnicas de programación especiales orientadas a objetos a susimplementaciones de objetos ABAP.

Clases abstractas y métodos abstractosEs posible evitar la instanciación de una clase utilizando el suplementoABSTRACT con la sentencia CLASS. Las clases superiores son un uso típico declases abstractas, ya que no están pensadas para que ellas mismas se instancien,sino sus subclases.

272 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 287: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

En una clase abstracta de este tipo, se pueden definir métodos abstractos (entreotras cosas). Esto significa que la implementación puede dejarse abierta. Si lasubclase de esta clase no es abstracta, los métodos abstractos deberán redefinirseen este lugar. Esto significa que se debe implementar por primera vez.

Nota: El indicador relevante se encuentra en el generador de clases, enla etiqueta Atributos de esta clase o método.

In this particular case, we suggest that you do not conduct a system demonstrationat this point.

Gráfico 126: Clases abstractas y métodos abstractos

Las referencias a estas clases abstractas pueden utilizarse, por lo tanto, para elacceso polimórfico a instancias de subclase.

Los métodos estáticos no pueden ser abstractos porque no se pueden redefinir.

Clases y métodos finalesEs posible impedir que una clase se herede utilizando el suplemento FINAL con lasentencia CLASS.

Es posible impedir que un método se redefina utilizando el suplemento FINALcon la sentencia METHODS.

Nota: El indicador relevante se encuentra en el generador de clases, enla etiqueta Atributos de esta clase o método.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 273

Page 288: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

In this particular case, we suggest that you do not conduct a system demonstrationat this point.

Gráfico 127: Clases y métodos finales

Así, todos los métodos de una clase final son implícitamente finales. Por lo tanto,no es necesario repetir el suplemento FINAL en los propios métodos

Las clases que son abstractas y finales deberían contener sólo componentesestáticos.

Visibilidad del constructor de instanciaEs posible limitar la instanciación de una clase utilizando el suplemento CREATEcon la sentencia CLASS.

Nota: El indicador relevante se encuentra en el generador de clases, enla etiqueta Atributos de la clase relevante.

274 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 289: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

Gráfico 128: Parametrización implícita de la visibilidad del constructor deinstancia

La variante CLASS ... DEFINITION CREATE PUBLIC ... es el casoestándar, es decir, la definición normal de una clase. Las otras dos varianteslimitan el contexto en el que la sentencia CREATE OBJECT puede aparecer,tal como se especifica más arriba. Por ello, es posible determinar la sección devisibilidad para el constructor de instancia.

Nota: Independientemente de todo ello, el constructor de instancia sedebe definir + siempre sintácticamente en la sección pública.

Clases sin instanciación múltipleHay muchos casos en los que es necesario evitar que una clase sea instanciadamás de una vez para cada contexto de programa. Es posible hacerlo de la manerasiguiente mediante el concepto singleton:

Be sure to demonstrate this concept in the system because it is a basicprogramming pattern for all standard object-oriented programming languages.

You could use the first (optional) exercise for this purpose, allowing theparticipants to become involved in the demonstration.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 275

Page 290: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Gráfico 129: Clases singleton

La clase se define con los suplementos FINAL y CREATE PRIVATE, y seinstancia utilizando su constructor estático.

Un componente estático público podría hacer que la referencia a la clase fueradisponible para un usuario externo.

Relación de amistadEn algunos casos, las clases tienen que trabajar tan estrechamente que una o ambasclases necesitan acceder a los componentes protegidos y privados de la otra. Demanera parecida, deben poder crear instancias de estas otras clases sin importar lavisibilidad de los constructores. Para evitar que estas opciones estén disponiblespara todos los usuarios, se puede utilizar el concepto de clase de amistad. Unaclase puede garantizar amistad a otras clases e interfases (y pedir a todas las clasesque implementen la interfase).

Este es el propósito del suplemento FRIENDS de la sentencia CLASS o la etiquetaFRIENDS en el generador de clases. Todas las clases e interfases que garantizanamistad están enumerados en este lugar.

En principio, la garantía de amistad es unilateral: Una clase que garantice unaamistad no es automáticamente una amiga de sus amigos. Si una clase quegarantiza amistad quiere acceder a los componentes que no son públicos de unamigo, este amigo debe garantizarle su amistad explícitamente.

276 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 291: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

Gráfico 130: Áreas de uso para relaciones de amistad

Una aplicación típica de la relación de amistad entre clases es cuando los métodosque tienen acceso a los mismos datos se distribuyen entre varias clases. Estosdatos compartidos, sin embargo, deben protegerse contra el acceso por parte declases �externas�. En estas relaciones de amistad, es posible convertir a la claseque contiene los datos en un singleton, es decir, es posible asegurarse de que sólose puede instanciar una vez en cada instancia de programa.

Gráfico 131: Definición de relaciones de amistad

El atributo de amigo es heredado: las clases que heredan de amigos y lasinterfases que contienen un amigo (como una interfase de componente) tambiénse convierten en amigos. Por ello, se debe tener mucho cuidado al garantizar laamistad. Cuanto más arriba esté un amigo en el árbol de herencia, más subclasespodrán acceder a todos los componentes de una clase que garantiza amistad.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 277

Page 292: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

En cambio, la garantía de amistad no se hereda. Por lo tanto, un amigo de unaclase superior no es automáticamente un amigo de sus subclases.

278 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 293: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

265 Ejercicio 17: Clases singleton (opcional)Duración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases� Definir clases singleton� Instanciar clases singleton

Ejemplo empresarialNecesita una clase que sólo pueda ser instanciada una vez para cada contextode programa.

Tarea 1:Cree una clase singleton global.

1. Cree la clase global ZCL_##_SINGLETON. (## es el número de grupode dos cifras). Especifique los atributos necesarios para la clase singletoncuando lo haga.

2. Defina el atributo R_SINGLETON para una referencia a la instanciasingleton, asegurándose de que el atributo tiene un tipo adecuado.

3. Defina e implemente el método GET_SINGLETON. Ofrecerá la referenciaa la instancia de singleton.

4. Asegúrese de que la instancia singleton se crea sólo con la primera llamadadel método GET_SINGLETON.

Tarea 2:Cree una instancia singleton.

1. Cree el programa ejecutable ZBC401_##_MAIN_SPECIAL.

2. Defina una variable de referencia para la instancia singleton.

3. Cree la instancia singleton.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 279

Page 294: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Solución 17: Clases singleton (opcional)Tarea 1:Cree una clase singleton global.

1. Cree la clase global ZCL_##_SINGLETON. (## es el número de grupode dos cifras). Especifique los atributos necesarios para la clase singletoncuando lo haga.

a) Realice este paso de la forma habitual. Encontrará informaciónadicional en la biblioteca SAP.

b) Especifique los atributos tal como se indica en la sección relevantede esta lección.

2. Defina el atributo R_SINGLETON para una referencia a la instanciasingleton, asegurándose de que el atributo tiene un tipo adecuado.

a) Utilice las secciones relevantes de la unidad como guía.

3. Defina e implemente el método GET_SINGLETON. Ofrecerá la referenciaa la instancia de singleton.

a) Utilice las secciones relevantes de la unidad como guía.

4. Asegúrese de que la instancia singleton se crea sólo con la primera llamadadel método GET_SINGLETON.

a) Utilice las secciones relevantes de la unidad como guía.

Tarea 2:Cree una instancia singleton.

1. Cree el programa ejecutable ZBC401_##_MAIN_SPECIAL.

a) Realice este paso de la forma habitual.

b) Solución modelo: SAPBC401_SPCS_MAIN_A

2. Defina una variable de referencia para la instancia singleton.

a) Realice este paso de la forma habitual. Consulte la solución modelo.

3. Cree la instancia singleton.

a) Consulte el extracto del código fuente de la solución modelo.

ResultadoExtracto del código fuente:

Continúa en la página siguiente

280 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 295: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

SAPBC401_SPCS_MAIN_A

REPORT sapbc401_spcs_main_a.

*--------------------------------------------------------*

* CLASS lcl_singleton DEFINITION

*--------------------------------------------------------*

CLASS lcl_singleton DEFINITION CREATE PRIVATE.

PUBLIC SECTION.

"--------------

CLASS-METHODS: class_constructor.

CLASS-METHODS: get_singleton RETURNING value(re_single)

TYPE REF TO lcl_singleton.

PRIVATE SECTION.

"----------------

CLASS-DATA: r_single TYPE REF TO lcl_singleton.

ENDCLASS. "lcl_singleton DEFINITION

*----------------------------------------------------------*

* CLASS lcl_singleton IMPLEMENTATION

*----------------------------------------------------------*

CLASS lcl_singleton IMPLEMENTATION.

METHOD class_constructor.

CREATE OBJECT r_single.

ENDMETHOD. "class_constructor

METHOD get_singleton.

re_single = r_single.

ENDMETHOD. "get_singleton

ENDCLASS. "lcl_singleton IMPLEMENTATION

*** Main Program;

*** creating the singleton via class-constructor

DATA: r_single TYPE REF TO cl_singleton.

START-OF-SELECTION.

*########################

r_single = lcl_singleton=>get_singleton( ).

*** repeat this statement and watch the execution in the Debugger !

*** you will see the implicit call of the class_constructor !

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 281

Page 296: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

282 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 297: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

269 Ejercicio 18: Relaciones de amistad(opcional)Duración del ejercicio: 45 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases� Definir relaciones de amistad� Acceder a atributos privados de una clase que garantiza la amistad

Ejemplo empresarialCree una clase global para agencias de viajes que pueda acceder a los atributosprivados de una clase singleton que es una amiga. La clase grabará los datos deconexión de vuelos en la memoria intermedia.

Tarea 1:Grabe en memoria intermedia los datos de vuelo en una clase singleton.

1. Añada el atributo CONNECTION_LIST de los datos de conexión de vuelosa su clase singleton ZCL_##_SINGLETON, asegurándose de que se hanfijado los atributos correctos para los datos de conexión de vuelos. (## es elnúmero de grupo de dos cifras). )

Consejo: Puede utilizar el tipo de tabla global TY_CONNECTIONS.

2. Asegúrese de que esta tabla interna se rellene con los datos de la tablatransparente SPFLI, pero sólo cuando se accede a la instancia singletonpor primera vez.

Tarea 2:Cree una clase global para agencias de viajes y haga que la clase singletongarantice su amistad. Permita que la nueva clase global pase datos de conexiónde vuelos a un usuario.

1. Cree la clase global ZCL_##_AGENCY. (## es el número de grupo de doscifras). La clase singleton debe garantizar su amistad.

2. Defina el atributo de instancia privado NAME del tipo STRING.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 283

Page 298: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

3. Defina e implemente un constructor de instancia que fija el atributo privadoNAME.

4. Defina el método de instancia público GET_CONNECTION con la siguientefirma:

ID Tipo Tipo asociadoIM_CARRID Importación S_CARR_IDIM_CONNID Importación S_CONN_IDEX_CONNECTION Exportación SPFLI

5. Implemente su método de manera que los datos adicionales de las conexionesde vuelos seleccionadas puedan leerse y exportarse desde la tabla internaprivada de la instancia singleton, utilizando un acceso de registro único.

Si el registro de datos necesario no existe, en este caso debería ser suficienteemitir un mensaje en la lista ABAP.

Consejo: Si es necesario, utilice la sentencia CLASS ...DEFINITION LOAD para permitir sintácticamente el accesodirecto a los componentes estáticos de la clase.

Este suplemento no es necesario en los releases posteriores.

Tarea 3:Cree una instancia de agencia de viajes y haga que ofrezca los datos de unaconexión de vuelo.

1. Añada una variable de referencia para una instancia de agencia de viajes alprograma ejecutable ZBC401_##_MAIN_SPECIAL creado anteriormente.(## es el número de grupo de dos cifras). )

2. Cree una instancia de agencia de viajes.

3. Llame el método GET_CONNECTION para una conexión de vuelo existentedesde el modelo de datos de vuelos (por ejemplo, LH/0400) y visualicelos datos en una lista ABAP.

284 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 299: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

Solución 18: Relaciones de amistad(opcional)Tarea 1:Grabe en memoria intermedia los datos de vuelo en una clase singleton.

1. Añada el atributo CONNECTION_LIST de los datos de conexión de vuelosa su clase singleton ZCL_##_SINGLETON, asegurándose de que se hanfijado los atributos correctos para los datos de conexión de vuelos. (## es elnúmero de grupo de dos cifras). )

Consejo: Puede utilizar el tipo de tabla global TY_CONNECTIONS.

a) Hable con su instructor si tiene cualquier duda.

b) Solución modelo: CL_SINGLETON

2. Asegúrese de que esta tabla interna se rellene con los datos de la tablatransparente SPFLI, pero sólo cuando se accede a la instancia singletonpor primera vez.

a) Hable con su instructor si tiene cualquier duda.

Tarea 2:Cree una clase global para agencias de viajes y haga que la clase singletongarantice su amistad. Permita que la nueva clase global pase datos de conexiónde vuelos a un usuario.

1. Cree la clase global ZCL_##_AGENCY. (## es el número de grupo de doscifras). La clase singleton debe garantizar su amistad.

a) Realice este paso de la forma habitual. Encontrará informaciónadicional en la biblioteca SAP.

b) Solución modelo: CL_AGENCY

2. Defina el atributo de instancia privado NAME del tipo STRING.

a) Realice este paso de la forma habitual. Encontrará informaciónadicional en la biblioteca SAP.

3. Defina e implemente un constructor de instancia que fija el atributo privadoNAME.

a) Realice este paso de la forma habitual. Encontrará informaciónadicional en la biblioteca SAP.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 285

Page 300: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

4. Defina el método de instancia público GET_CONNECTION con la siguientefirma:

ID Tipo Tipo asociadoIM_CARRID Importación S_CARR_IDIM_CONNID Importación S_CONN_IDEX_CONNECTION Exportación SPFLI

a) Realice este paso de la forma habitual. Encontrará informaciónadicional en la biblioteca SAP.

5. Implemente su método de manera que los datos adicionales de las conexionesde vuelos seleccionadas puedan leerse y exportarse desde la tabla internaprivada de la instancia singleton, utilizando un acceso de registro único.

Si el registro de datos necesario no existe, en este caso debería ser suficienteemitir un mensaje en la lista ABAP.

Consejo: Si es necesario, utilice la sentencia CLASS ...DEFINITION LOAD para permitir sintácticamente el accesodirecto a los componentes estáticos de la clase.

Este suplemento no es necesario en los releases posteriores.

a) Utilice las secciones relevantes de la unidad como guía.

Tarea 3:Cree una instancia de agencia de viajes y haga que ofrezca los datos de unaconexión de vuelo.

1. Añada una variable de referencia para una instancia de agencia de viajes alprograma ejecutable ZBC401_##_MAIN_SPECIAL creado anteriormente.(## es el número de grupo de dos cifras). )

a) Consulte el extracto del código fuente de la solución modelo.

2. Cree una instancia de agencia de viajes.

a) Consulte el extracto del código fuente de la solución modelo.

3. Llame el método GET_CONNECTION para una conexión de vuelo existentedesde el modelo de datos de vuelos (por ejemplo, LH/0400) y visualicelos datos en una lista ABAP.

a) Consulte el extracto del código fuente de la solución modelo.

Continúa en la página siguiente

286 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 301: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

ResultadoExtracto del código fuente:

SAPBC401_SPCS_MAIN_B

REPORT sapbc401_spcs_main_b.

TYPES: ty_connection_list TYPE HASHED TABLE OF spfli

WITH UNIQUE KEY carrid connid.

*** just because lcl_agency is defined later !

CLASS lcl_agency DEFINITION DEFERRED.

*-----------------------------------------------------------------*

* CLASS lcl_singleton DEFINITION

*-----------------------------------------------------------------*

CLASS lcl_singleton DEFINITION CREATE PRIVATE FRIENDS lcl_agency.

PUBLIC SECTION.

"--------------

CLASS-METHODS: class_constructor.

CLASS-METHODS: get_singleton RETURNING value(re_single)

TYPE REF TO lcl_singleton.

PRIVATE SECTION.

"----------------

CLASS-DATA: r_single TYPE REF TO lcl_singleton.

CLASS-DATA: connection_list TYPE ty_connection_list.

ENDCLASS. "lcl_singleton DEFINITION

*------------------------------------------------------------------*

* CLASS lcl_singleton IMPLEMENTATION

*------------------------------------------------------------------*

CLASS lcl_singleton IMPLEMENTATION.

METHOD class_constructor.

CREATE OBJECT r_single.

SELECT * FROM spfli INTO TABLE connection_list.

ENDMETHOD. "class_constructor

METHOD get_singleton.

re_single = r_single.

ENDMETHOD. "get_singleton

ENDCLASS. "lcl_singleton IMPLEMENTATION

*------------------------------------------------------------------*

* CLASS lcl_agency DEFINITION

*------------------------------------------------------------------*

CLASS lcl_agency DEFINITION.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 287

Page 302: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

PUBLIC SECTION.

"--------------

METHODS: constructor IMPORTING im_name TYPE string.

METHODS: get_connection IMPORTING im_carrid TYPE s_carr_id

im_connid TYPE s_conn_id

EXPORTING ex_connection TYPE spfli.

PRIVATE SECTION.

"----------------

DATA: name TYPE string.

ENDCLASS. "lcl_agency DEFINITION

*------------------------------------------------------------------*

* CLASS lcl_agency IMPLEMENTATION

*------------------------------------------------------------------*

CLASS lcl_agency IMPLEMENTATION.

METHOD constructor.

name = im_name.

ENDMETHOD. "constructor

METHOD get_connection.

*** direct access to the private components of the singletonclass.

*** the singleton object is created before via class_constructor !

*** the singleton object itself is not needed in this example

*** because we just access a static attribute !

READ TABLE lcl_singleton=>connection_list

INTO ex_connection

WITH TABLE KEY carrid = im_carrid

connid = im_connid.

ENDMETHOD. "get_singleton

ENDCLASS. "lcl_singleton IMPLEMENTATION

DATA: r_agency TYPE REF TO lcl_agency.

DATA: wa TYPE spfli.

START-OF-SELECTION.

*#########################

CREATE OBJECT r_agency EXPORTING im_name = ’I will access the private components of th

r_agency->get_connection( EXPORTING im_carrid = ’LH’

im_connid = ’0400’

IMPORTING ex_connection = wa ).

Continúa en la página siguiente

288 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 303: TAW12_01

TAW12_1 Lección: Técnicas de programación especiales orientadas a objetos

WRITE: / wa-carrid, wa-connid, wa-cityfrom, wa-cityto.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 289

Page 304: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

Resumen de la lección

Ahora podrá:� Definir clases abstractas� Definir métodos abstractos� Definir clases finales� Definir métodos finales� Limitar la visibilidad del constructor� Definir relaciones de amistad entre clases� Explicar el �patrón singleton�

Más informaciónEncontrará más información acerca de este tema en la biblioteca SAP y en ladocumentación de palabras clave ABAP para las sentencias individuales.

290 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 305: TAW12_01

TAW12_1 Resumen del capítulo

Resumen del capítuloAhora podrá:� Describir las funciones del generador de clases� Crear clases globales mediante el generador de clases� Crear interfases mediante el generador de clases� Referenciar clases e interfases globales en otros objetos de Repository� Definir clases abstractas� Definir métodos abstractos� Definir clases finales� Definir métodos finales� Limitar la visibilidad del constructor� Definir relaciones de amistad entre clases� Explicar el �patrón singleton�

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 291

Page 306: TAW12_01

Resumen del capítulo TAW12_1

292 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 307: TAW12_01

TAW12_1 Examine sus conocimientos

279Examine sus conocimientos

1. ¿Cuáles son las afirmaciones correctas?

Seleccione la(s) respuesta(s) correcta(s).□ A Es posible crear módulos de funciones mediante el generador

de clases.□ B Una clase global puede incluir una clase local.□ C Una interfase global puede incluir un interfase local.□ D Una clase global puede incluir una interfase local.□ E Una definición anidada de clases se refiere a aquella clase local

que se encuentra dentro de una clase global.□ F Mediante el generador de clases, una clase local puede

convertirse en una clase global.□ G Una clase local puede ser copiada mediante el generador de

clases. La copia será entonces una clase global.□ H Es posible utilizar el asistente de refactoring para desplazar los

métodos a una clase distinta dentro de la jerarquía de herencia.□ I Para diseñar diagramas de modelos se puede utilizar el asistente

de refactoring.

2. Para que un usuario pueda ejecutar un programa orientado a objetos, esnecesario suministrar siempre un programa de module pool o un programade grupo de funciones. De lo contrario, la sentencia CREATE OBJECTno podrá crear la instancia.Diga si estas afirmaciones son correctas o falsas.□ Correcto□ Falso

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 293

Page 308: TAW12_01

Examine sus conocimientos TAW12_1

3. ¿Cuáles son las afirmaciones correctas?Seleccione la(s) respuesta(s) correcta(s).□ A Una clase no abstracta puede contener métodos abstractos.□ B Una clase abstracta no contiene implementaciones.□ C Una método abstracto no contiene implementaciones.□ D Las clases finales no pueden ser clases superiores dentro de una

jerarquía de clases.□ E Un método final debe estar redefinido.□ F Las clases finales pueden contener métodos no finales.□ G Un amigo de una clase es también un amigo de sus subclases.□ H Las subclases de un amigo de una clase también son amigas de

la clase.□ I La visibilidad de un constructor de instancia puede ser limitada.□ J Un constructor de instancia privada (instanciación sólo por parte

de la clase misma) se puede definir en la sección privada.

294 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 309: TAW12_01

TAW12_1 Examine sus conocimientos

281Respuestas

1. ¿Cuáles son las afirmaciones correctas?

Respuesta: B, D, G, H, I

Encontrará información adicional en la biblioteca SAP.

2. Para que un usuario pueda ejecutar un programa orientado a objetos, esnecesario suministrar siempre un programa de module pool o un programade grupo de funciones. De lo contrario, la sentencia CREATE OBJECTno podrá crear la instancia.

Respuesta: Falso

Encontrará información adicional en la biblioteca SAP.

3. ¿Cuáles son las afirmaciones correctas?

Respuesta: C, D, H, I, J

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 295

Page 310: TAW12_01

Capítulo 3: Objetos de Repository orientados a objetos TAW12_1

296 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 311: TAW12_01

Capítulo 4283 El concepto de la excepción basada

en clase

This unit deals with the new class-based exception concept that was introducedwith SAP Web Application Server 6.10.

Resumen del capítuloEn esta unidad se explica el nuevo concepto de excepción basada en clase.

Objetivos del capítuloAl finalizar este capítulo podrá:

� Gestionar excepciones basadas en clases en programas ABAP� Crear clases de excepción� Crear excepciones basadas en clases en programas ABAP� Propagar excepciones basadas en clases en programas ABAP� Asignar excepciones basadas en clases entre sí en programas ABAP

Contenido del capítuloLección: Excepciones basadas en clases .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298

Procedimiento: Definir clases de excepción globales .. . . . . . . . . . . . . . . .307Ejercicio 19: Gestión de excepciones basadas en clases ... . . . . . . . . .317Ejercicio 20: Creación y uso de clases de excepción globales .. . . . .323

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 297

Page 312: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

Lección:284

Excepciones basadas en clasesDuración de la lección: 90 Minutos

Resumen de la lecciónEn esta unidad se explica el nuevo concepto de excepción basada en clase quese introdujo con SAP Web Application Server 6.10. Se explican en detalle lascaracterísticas principales y las actividades que se deben realizar, y luego seaplican en ejemplos prácticos.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Gestionar excepciones basadas en clases en programas ABAP� Crear clases de excepción� Crear excepciones basadas en clases en programas ABAP� Propagar excepciones basadas en clases en programas ABAP� Asignar excepciones basadas en clases entre sí en programas ABAP

It is particularly important that you point out that this is again an enhancementof the functional scope of the ABAP programming language. The old exceptionsconcept remains valid, but will no longer continue to be developed.

Participants with experience in Java will notice marked similarities in syntax andruntime behavior. The main aim again is to present the additional user-friendlyoptions available in ABAP Objects and the ABAP Workbench.

In the event that participants remain skeptical about object-oriented programming,it may help to motivate them with a simple example from procedural programming:Until now, subroutines could not raise exceptions that could be handled. Instead,you had to implement a check yourself, using EXIT (or RETURN as of SAP WebAS 6.10) and auxiliary variables that you defined yourself. Now, any processingblock in ABAP can raise a class-based exception.

Ejemplo empresarialDebería utilizar el nuevo concepto de excepciones en sus programas ABAP.

Excepciones: ResumenUtilizamos el término excepción para denominar una situación que aparecemientras se ejecuta un programa, en la que no hay ningún motivo para seguirejecutando el programa de manera normal. SAP Web Application Server 6.10

298 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 313: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

introdujo un nuevo concepto de excepción ABAP de manera paralela al conceptoexistente. Las excepciones y el tratamiento de excepciones se basan ahora enclases.

Si antes del SAP Web Application Server 6.10 el sistema provocaba una excepción(debido a un desbordamiento de la memoria o a una asignación incorrecta delos parámetros, por ejemplo), la variable de sistema sy-subrc se establecía en unvalor distinto de cero. Un desarrollador podría rodear el punto crítico mediantela sintaxis CATCH ... ENDCATCH. y leer el valor de sy-subrc después deeste bloque. Si no había ningún CATCH ... ENDCATCH., se producía unerror en tiempo de ejecución.

Si se producen estados no deseados en módulos de funciones y métodos, eldesarrollador podría declarar esta clase de excepción de procedimiento yprovocarla con RAISE <exception>. Los programas de llamada tenían queprogramar un query adecuado para la variable de sistema sy-subrc en el códigofuente después de la llamada de rutina, en caso contrario se producía un erroren tiempo de ejecución.

Ambos casos siguen dándose en los sistemas basados en SAP Web ApplicationServer 6.10 o superior. Cuando se producen excepciones del sistema, siempre segenera una excepción de tipo clásica y otra excepción basada en clase. Cuando losdesarrolladores responden ante una excepción, pueden elegir cómo desean tratarla.En el caso de los módulos de funciones y los métodos, el desarrollador tiene queelegir uno de los conceptos para este tipo de procedimiento. En consecuencia, elusuario de un módulo de funciones está obligado a elegir la técnica de tratamientonueva o la anterior.

Una nueva característica de SAP Web Application Server 6.10 y versionessuperiores es la posibilidad de generar excepciones en cualquier punto delprograma. Esto sólo funciona con la técnica basada en clase.

Resumen de los dos conceptos de excepciónLugar en el que seproduce la excepción

Antes de 6.10 A partir de 6.10

Excepción del sistema(por ejemplo, divisiónpor cero)

sy-subrc sy-subrc ANDclass-based

módulos de funciones,métodos

sy-subrc sy-subrc OR class-based

provocada porun bloqueo delprocesamiento generadopor un comando explícito

no es posible basada en clase

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 299

Page 314: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

To illustrate the relevance of the topic more clearly:

Approximately 380,000 function modules exist with SAP NetWeaver 7.0. Ofthese, approximately 1,100 use the class-based exception concept. These figuresmay be sobering, but bear in mind: from 6.20 to 7.0 the total number of functionmodules did not even double, whereas there was a near tenfold increase in thenumber of function modules using the class-based exception concept over thesame release span. In the case of global methods, approximately one eighth usethe class-based exception concept with SAP NetWeaver 7.0.

Tratamiento de excepciones basadas en clases

Gráfico 132: Resumen del concepto de excepción basada en clase

Las excepciones basadas en clases son provocadas por la sentencia RAISEEXCEPTION o por el entorno de tiempo de ejecución. La división por cero, porejemplo, sería un ejemplo del último caso.

En una situación de excepción, una excepción se representa por un objeto deexcepción, es decir, una instancia de una clase de excepción. Los atributos de cadaobjeto de excepción contienen información acerca de la situación de error.

Al tratar una excepción de este tipo, se pueden provocar nuevas excepciones y asícrear una cadena de excepciones. Así, en casos especiales, es posible interceptaruna excepción de tiempo de ejecución y dejar que emita una excepción propia.

300 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 315: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

El propio usuario puede definir clases de excepción, pero ya existe una serie declases de excepción predefinidas en el sistema, en especial para excepciones en elentorno de tiempo de ejecución. Generalmente, las clases de excepción se creanglobalmente en el generador de clases, pero también se pueden definir clases deexcepción local dentro de un programa o clase global.

El uso de excepciones basadas en clases no está limitado a contextos orientados aobjetos. Las excepciones basadas en objetos se pueden emitir y tratar en todoslos bloques de procesamiento. En particular, todos los errores de tiempo deejecución interceptables anteriormente se pueden tratar ahora como excepcionesbasadas en clases.

Si se produce una excepción basada en clase, el sistema interrumpe el flujo normaldel programa e intenta navegar a un programa de control adecuado. Si no puedeencontrar un programa de control, aparecerá un error en tiempo de ejecución.

Todas las clases de excepción se derivan de una de estas clases: CX_NO_CHECK,CX_DYNAMIC_CHECK o CX_STATIC_CHECK, y por lo tanto, de la clasesuperior que comparten, que es CX_ROOT.

Gráfico 133: Clases de excepción: la jerarquía de herencia

To demonstrate this, program a zero division and point out the exception classdisplayed in the dump. You should perhaps also mention the transaction ST22for analyzing the dump.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 301

Page 316: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

La manera en que las clases de excepción se asignan a una de estas tresderivaciones en la jerarquía de herencia define cómo se propagarán las excepcionesasociadas. (Esta cuestión se discutirá de manera más detallada posteriormente).

En el sistema estándar SAP, los nombres de todas las clases de excepciónempiezan por CX_. El nombre de las clases de excepción definidas por el clienteempieza por un área para nombres + el prefijo CX_ (por ejemplo, ZCX_ o/NAMESPACE/CX_).

La clase CX_ROOT proporciona métodos predefinidos que son heredados portodas las clases de excepción. El método GET_SOURCE_POSITION devuelveel nombre del programa principal y (si es relevante) los nombres del programade Include y el número de línea del código fuente en el que se ha producido laexcepción. El método GET_TEXT devuelve un texto de excepción en forma destring. El método GET_LONGTEXT también está disponible para todas las clasesde excepciones, sin embargo, no siempre se puede generar un texto explicativopor cada excepción.

Las clases de excepción definidas recientemente heredan de una de estas clasessuperiores, de manera que puedan añadirse otros componentes. Suelen ser textosde excepción individuales.

Es posible asignar varios textos a cada clase. Los ID asignados a estas clases soncreados por el generador de clases como constantes estáticas que llevan el mismonombre. A continuación, se puede especificar el texto que se debe utilizar cuandose produce una excepción, transmitiendo una de estas constantes al parámetro deimportación TEXTID del constructor de instancia.

Todas las clases de excepción heredan el atributo KERNEL_ERRID deCX_ROOT. Este atributo contiene el nombre del error en tiempo de ejecuciónapropiado si la excepción ha sido provocada por el entorno de tiempo deejecución, como BCD_ZERODIVIDE si el programa intercepta una excepciónCX_SY_ZERODIVIDE (división entre cero). Si no se trata la excepción, seproduce este error en tiempo de ejecución.

Sólo se puede tratar una excepción si la sentencia que podría provocarla estáanidada en un bloque TRY-ENDTRY. La excepción se trata a continuaciónmediante la sentencia CATCH en el bloque TRY-ENDTRY.

302 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 317: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

Gráfico 134: Secuencia TRY-ENDTRY

El bloque TRY contiene la secuencia con las excepciones que se deben tratar.Si se produce una excepción en el bloque TRY, el sistema buscará primero unasentencia CATCH en el mismo bloque TRY-ENDTRY y luego buscará bloquesde sentencias CATCH hacia el exterior para gestionar la excepción en cualquierconjunto TRY-ENDTRY que pueda haber. Si encuentra una, navegará a suprograma de control. Si no puede encontrar un programa de control, pero elbloque TRY-ENDTRY está incluido en un procedimiento, el sistema intentarápropagar la excepción al programa de llamada. (Esta cuestión se discutirá demanera más detallada posteriormente).

Un bloque CATCH contiene el programa de control de excepciones que se ejecutasi se produce una excepción especificada en el bloque TRY correspondiente.Es posible especificar un número indeterminado de clases de excepción parala sentencia CATCH. De esta manera, se define un programa de control deexcepciones para todas estas clases de excepción y sus subclases.

Como todas las estructuras de control en ABAP, los bloques TRY-ENDTRYse pueden anidar hasta el nivel que se desee. Así, el bloque TRY, los bloquesCATCH y el bloque CLEANUP concretamente pueden contener a su vez bloquesTRY-ENDTRY enteros.

Después de producirse una excepción, el sistema busca a través de los programasde control de excepciones enumerados en el orden especificado. A continuaciónejecuta el primer programa de control de excepciones cuya sentencia CATCHcontenga la clase de excepción relevante o una de sus clases superiores.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 303

Page 318: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

Un bloque CLEANUP se ejecuta si se sale del bloque TRY-ENDTRY, porqueel sistema no puede encontrar ningún programa de control para una excepción,pero la excepción se trata dentro de un bloque TRY-ENDTRY circundante o sepropaga a un programa de llamada.

En las siguientes secciones, nos centraremos en clases de excepción globales quese tratan de manera local. Recuerde que también se pueden utilizar clases deexcepción locales que se tratan localmente o clases de excepción globales que setratan en métodos de otras clases globales.

Ejemplo: tratamiento de una excepción predefinidaHay dos características especiales a tener en cuenta en el siguiente ejemplo: enprimer lugar, instanciaremos simplemente una clase de excepción estándar, enlugar de definir una clase nueva. En segundo lugar, la excepción será emitida porel sistema de tiempo de ejecución como resultado de un error, en lugar de seremitida por un procedimiento.

Gráfico 135: Ejemplo de sintaxis para tratar excepciones predefinidas

En el cálculo superior, si se supera el ámbito de valores para tiposde datos I, el sistema de tiempo de ejecución emitirá la excepciónCX_SY_ARITHMETIC_OVERFLOW. Esta excepción la trata el bloque CATCHimplementado. La referencia a la instancia relevante se guarda en el objetode datos gx_exc. El programa de control puede acceder entonces al texto de

304 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 319: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

excepción de la instancia mediante el método funcional GET_TEXT. El textose almacena en el objeto de datos de tipo STRING ge_text y luego se visualizacomo mensaje de información.

Nota: La sentencia MESSAGE se amplió en SAP Web Application Server6.10, por lo que se puede enviar cualquier string como objeto de datosdel tipo CLIKE.

MESSAGE string TYPE message_type.

Además del mensaje string que se debe visualizar, se debe especificarel tipo de mensaje message_type.

Si no se supera el ámbito de valores para el tipo de datos I, no se producirá ningunaexcepción y el bloque TRY se procesará por completo. A continuación, se vuelvea ejecutar el bloque de procesamiento después de la palabra clave ENDTRY.

La clase CX_SY_ARITHMETIC_OVERFLOW es una subclase de las clasesCX_SY_ARITHMETIC_ERROR, CX_DYNAMIC_CHECK, y CX_ROOT. Así,la excepción emitida arriba también se puede tratar si se introduce una de estasclases después de la sentencia CATCH.

Atención: Este es un ejemplo de muestra que se ha estructuradodeliberadamente de manera sencilla. Normalmente, la variable ge_resultse define con el tipo numérico P para evitar un error en tiempo deejecución. A continuación se puede definir el tamaño del valor resultanteantes de utilizar MOVE para convertirlo a una variable entera en casonecesario.

Al igual que ocurre con el uso (obsoleto) de CATCH SYSTEM-EXCEPTIONS,aquí también se trata de interceptar los errores en tiempo de ejecución que no sepueden excluir por completo. Un ejemplo típico de esto es el uso de asignacionesdowncast (descendentes).

La documentación de palabras clave ABAP de cada sentencia enumera las clasescuyas excepciones pueden aparecer cuando se ejecuta la sentencia.

Puede elegir entre el concepto de excepción clásica y excepción basada en clasecuando declare excepciones para módulos de funciones y métodos de clasesglobales. En consecuencia, como usuario debe interceptar las excepciones con unquery sy-subrc o con una sentencia TRY-ENDTRY. El patrón en el Editor ABAPinserta automáticamente la opción correcta, siempre que lo haya definido así en elWorkbench ABAP, en Utilidades→ Opciones→ Editor ABAP→ Patrón.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 305

Page 320: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

Gráfico 136: Cómo interceptar excepciones con el patrón

This is a good time to do the first exercise in this unit: Catching Exceptions.

A continuación se explicará cómo crear sus propias clases de excepción globales.

306 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 321: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

293Definir clases de excepción globales

1. En el generador de clases, cree una clase global tal como se describe en labiblioteca SAP. Cuando introduzca el nombre, use el área de nombres decliente seguido del prefijo CX_. Seleccione la opción Clase de excepcióncomo el Tipo de clase.

A partir de SAP NetWeaver 7.0 puede seleccionar la casilla de verificaciónCon clase de mensaje cuando cree una clase de excepción. Los textos quedesee que aparezcan cuando se produzcan excepciones se pueden tomar dela clase de mensaje que conoce la sentencia MESSAGE. (Encontrará estosmensajes y estas clases de mensaje en la tabla T100).

Si no marca este campo o si trabaja en un sistema con un release anteriora SAP NetWeaver 7.0, puede crear los textos de excepción haciendo dobleclic en ellos en el generador de clases y guardándolos en el OTR (OnlineText Repository).

Gráfico 137: Creación de clases de excepción globales

2. Si es necesario, otorgue atributos adicionales a su clase de excepción (porejemplo, para extensiones de textos de excepción).

Si los atributos son públicos, el generador de clases generará un constructorde instancia apropiado, de manera que estos atributos puedan activarsecuando se produzca la excepción. Los parámetros de importación se generancon los mismos nombres que los atributos.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 307

Page 322: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

3. Grabe todos los textos de excepción que necesite. Al hacerlo, puedeinsertar sus atributos como parámetros en el texto, con el formato&<attribute_name>&.

Nota: Para el primer texto que cree usted mismo, utilice siempreuna constante estática predefinida como ID. Siempre tiene el mismonombre que la propia clase de excepción. Si no hay ningún textoespecificado explícitamente en el momento de emitir la excepción,se utilizará el texto con este ID en su lugar.

Para el resto de textos, se deben definir otros ID. Entonces el generador declases generará automáticamente constantes estáticas con nombres idénticos.Cuando se produzca la excepción, transmita una de estas constantes alparámetro de importación TEXTID para especificar el texto apropiado parala instancia de excepción.

Continúa en la página siguiente

308 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 323: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

Gráfico 138: Definición de textos de excepción variables

Nota: Antes de SAP NetWeaver 7.0, los textos de excepción paraclases de excepción globales se guardaban con sus traduccionesen el Open Text Repository (OTR). Tenga en cuenta que se puedeasignar varios textos a una misma clase. Para asignar un texto a unaexcepción, utilice el atributo TEXTID, que contiene el ID únicoglobal del objeto de texto en el OTR en una instancia en tiempo deejecución. A continuación, el método GET_TEXT lee este texto,sustituye los parámetros de texto por el contenido de los atributosrelevantes según sea necesario, y devuelve el texto en forma destring de caracteres.

4. Active su clase de excepción.

Demo: Create an exception class that derives its texts from message classes.CX_DNW7AW_NO_DATA can be used for orientation.

Propagación y tratamiento de una excepciónLas excepciones basadas en clase que se producen durante los procedimientos nose tienen que tratar necesariamente cuando se producen; se pueden propagar alprograma de llamada del procedimiento. El programa de llamada puede tratarla excepción él mismo o propagarla a su propio programa de llamada, etc. Los

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 309

Page 324: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

niveles superiores a los que se puede propagar una excepción son bloques deprocesamiento sin áreas de datos locales, es decir, bloques de evento o módulosde diálogo. Las excepciones propagadas por los procedimientos llamados sedeben tratar allí, al igual que las excepciones emitidas dentro de este bloque deprocesamiento. De lo contrario, se producirá un error en tiempo de ejecución.

Para propagar una excepción desde un procedimiento, normalmente se usa elsuplemento RAISING cuando se define la firma del procedimiento. En métodosde subrutinas y clases locales, el suplemento RAISING se especifica directamentecuando se define el procedimiento:

METHODS meth_name ... RAISING cx_...cx_... o

FORM subr_name ... RAISING cx_...cx_....

Después de RAISING están las clases de excepción cuyas instancias se debepropagar. En métodos de clases globales, las clases de excepción cuyas instanciasse deben propagar se introducen en la tabla de excepciones del método en elgenerador de clases. También se debe activar el indicador Clase de excepción paracada tabla de excepciones. El proceso es similar para módulos de funciones. Paraactivar el indicador en el Function Builder, seleccione la etiqueta Excepciones.Está claro que un método global o un módulo de funciones sólo pueden provocarexcepciones basadas en clases o excepciones convencionales.

Gráfico 139: Propagación de excepciones

310 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 325: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

El parámetro TEXTID es opcional: el valor de propuesta siempre es la constanteestática, que tiene el mismo nombre que la clase de excepción. Sin embargo, unade las constantes estáticas definidas como ID de texto adicional en la clase deexcepción también puede utilizarse para sustituir el valor. Cuando se produce laexcepción, se activa el texto correspondiente para la instancia de la excepción.Una vez interceptada la excepción, puede leer el texto con el método funcionalGET_TEXT.

Si el programa de llamada no intercepta la excepción, puede propagarse haciaarriba al programa de llamada del siguiente nivel. Antes de que el controlse transfiera al programa de llamada del siguiente nivel, se ejecuta el bloqueCLEANUP (opcional). Después, este bloque deberá utilizarse para ejecutar lassentencias adecuadas.

Demo: SAPDNW7AW_EXCEPTIONS_D1

.

Ejemplo: cómo provocar, propagar y tratar unaexcepciónREPORT sapdnw7aw_exceptions_d1.

DATA: gx_no_data TYPE REF TO cx_dnw7aw_no_data,

gs_plane TYPE saplane,

ge_text TYPE string.

*---------------------------------------------------------------------*

CLASS lcl_planes DEFINITION.

PUBLIC SECTION.

CLASS-METHODS:

read_plane_details

IMPORTING ie_planetype TYPE saplane-planetype

RETURNING value(re_plane) TYPE saplane

RAISING cx_dnw7aw_no_data.

ENDCLASS. "lcl_planes

*---------------------------------------------------------------------*

CLASS lcl_planes IMPLEMENTATION.

METHOD read_plane_details.

SELECT SINGLE * FROM saplane INTO re_plane

WHERE planetype = ie_planetype.

IF sy-dbcnt = 0.

RAISE EXCEPTION TYPE cx_dnw7aw_no_data

EXPORTING

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 311

Page 326: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

textid = cx_dnw7aw_no_data=>planetype_wrong

planetype = ie_planetype.

ENDIF.

ENDMETHOD. "read_plane_details

ENDCLASS. "lcl_planes

START-OF-SELECTION.

TRY.

gs_plane = lcl_planes=>read_plane_details( ’A320’ ).

WRITE: / gs_plane-planetype, gs_plane-seatsmax, gs_plane-producer.

CATCH cx_dnw7aw_no_data INTO gx_no_data.

ge_text = gx_no_data->get_text( ).

WRITE: / ge_text.

ENDTRY.

Excepciones basadas en clases en modo debuggingSi se produce una excepción, el nombre de la clase de excepción se visualizaráen el campo Excepción emitida en el Debugger clásico o en el mensaje de statusen el nuevo Debugger.

Si la excepción se intercepta mediante un bloque CATCH, se visualizará en formade mensaje de éxito. El puntero de la sentencia actual se mueve a continuacióna este bloque CATCH.

Gráfico 140: Excepciones basadas en clases en modo debugging

312 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 327: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

También aparecen dos pulsadores. Permiten visualizar los valores de los atributosde la instancia de excepción y navegar hacia el punto del código fuente en el que seha producido la excepción. Si no ha usado el suplemento INTO <reference>opcional con la sentencia CATCH y desea ver una instancia de excepción tambiénen el Debugger, marque Crear objeto de excepción siempre en las opciones delDebugger de antemano.

We advise you to have the participants do the second exercise at this point (definean exception class and raise, propagate, and handle a class-based exception).

Clases de excepción: la jerarquía de herenciaA continuación se explican las consecuencias que aparecen tras la selección deuna clase superior de clase de excepción. También se indica cómo las excepcionesdel sistema de tiempo de ejecución se han integrado en la jerarquía de herencia delas clases de excepción.

Gráfico 141: Integración de excepciones estándar en el sistema de tiempode ejecución

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 313

Page 328: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

En el caso de las subclases de CX_STATIC_CHECK, una excepción relevanteen los procedimientos debe tratarse o propagarse explícitamente medianteel suplemento RAISING. Si éste no es el caso, la verificación de sintaxisemitirá un mensaje de advertencia. Si define sus propias clases de excepción,CX_STATIC_CHECK se define como la clase superior de propuesta.

Los mismo se aplica a las subclases de CX_DYNAMIC_CHECK con respectoa las subclases de CX_STATIC_CHECK: Las excepciones basadas en estodeben tratarse o propagarse de forma explícita con el suplemento RAISING. Ladiferencia es que no se realiza una verificación estática. No se emitirá ningúnmensaje de advertencia sintáctica si la excepción no se trata ni se propaga. Si laexcepción se emite a continuación, aparecerá un error en tiempo de ejecución.Ejemplos típicos de esta situación son las excepciones predefinidas CX_SY_...para los errores que ocurren en el entorno de tiempo de ejecución. Suelen sersubclases de CX_DYNAMIC_CHECK.

Para subclases de CX_NO_CHECK, la regla es que las excepcionescorrespondientes no pueden propagarse explícitamente mediante elsuplemento RAISING. Estas excepciones pueden tratarse. En los demás casos,se propagan automáticamente. Ni los mensajes de advertencia sintáctica ni loserrores en tiempo de ejecución se producen directamente donde se emiten. Ensu lugar, todas las excepciones que no se tratan en algún lugar de la jerarquíade llamada, se propagan hacia el nivel de llamada más alto. Si tampoco seinterceptan allí, se producirá un error en tiempo de ejecución en este punto.Algunas excepciones predefinidas con el prefijo CX_SY_... para situaciones deerror en el entorno de tiempo de ejecución son subclases de CX_NO_CHECK.

Asignación de excepciones entre síPara mayor claridad, cabe destacar que una excepción se puede propagar através de un número indeterminado de jerarquías de llamadas antes de ser tratadafinalmente.

En la sección siguiente se muestra cómo se puede entrelazar la generación deexcepciones. Una excepción puede emitir una segunda, etc. Cada instanciadebería seguir siendo válida, independientemente de si ya se ha abandonadoel bloque CATCH correspondiente o no. Para ello, se debe asegurar de que lainstancia de excepción anterior siempre pueda localizarse por medio de al menosuna referencia. El atributo de instancia pública PREVIOUS, heredado por todaslas clases de excepción desde CX_ROOT, ofrece un buen modo de lograrlo.

314 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 329: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

Gráfico 142: Asignación de excepciones entre sí: el principio

Gráfico 143: Asignación de excepciones entre sí

Al emitir la siguiente excepción, sólo debe transmitirse una referencia a lainstancia de excepción anterior a la nueva instancia. Para ello se utiliza elparámetro PREVIOUS opcional para el constructor de instancia, es decir, en

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 315

Page 330: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

RAISE EXCEPTION. De este modo se asigna la nueva excepción a la anterior.Una vez interceptada la excepción asignada, el atributo de instancia PREVIOUScontiene una referencia a la instancia de excepción anterior, y así sucesivamente.De esta manera, se puede acceder a cada instancia en la cadena de excepciones.De este modo puede realizar un seguimiento del historial de las excepcionesproducidas en el programa.

Demo: If the participants express an interest, show the reportSAPDNW7AW_EXCEPTIONS_D2.

316 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 331: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

303 Ejercicio 19: Gestión de excepcionesbasadas en clasesDuración del ejercicio: 20 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Tratar excepciones basadas en clases

Ejemplo empresarialEn su empresa utilizan un código fuente ABAP que puede provocar excepcionesbasadas en clases. Por lo tanto, debe poder reaccionar e interceptar estasexcepciones.

Tarea 1:Copiar el programa de modelo

1. Copie el programa de modelo SAPDNW7AW_EXCEPTIONS_T1 aZDNW7AW_EXCEPTIONS_##_1. (## representa el número de grupo dedos dígitos). El programa es una calculadora sencilla.

Active su copia.

Tarea 2:Provocar una excepción (dump)

1. Realice las entradas necesarias en la pantalla de selección para provocarlos errores siguientes y fíjese en las excepciones provocadas en el análisisdel dump:

División entre cero

Desbordamiento

Entradas de caracteres en vez de numéricas. (En realidad el desarrollador delprograma podría haberlo evitado poniendo campos de enteros en el campode selección, en vez de campos de caracteres...)

Consejo: Para analizar también dumps a posteriori, inicie latransacción ST22.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 317

Page 332: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

Tarea 3:Interceptar excepciones

1. La operación se calcula en el programa, en el evento ATSELECTION-SCREEN.

Proceso de fondo: Si intercepta errores aquí y envía mensajes de correoelectrónico, los usuarios tendrán que cambiar sus entradas en la pantallade selección.

Intercepte las excepciones con el concepto de excepción basado en clasedel modo siguiente:

En el caso de la división entre cero, se debería visualizar el siguiente mensajede error: �Ni siquiera ABAP puede dividir entre cero.�

En caso de desbordamiento o si se introduce un operando no válido, el objetode excepción generado por el sistema debería ser interceptado, y el resultadode este método GET_TEXT se debería visualizar como mensaje de error.

318 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 333: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

Solución 19: Gestión de excepcionesbasadas en clasesTarea 1:Copiar el programa de modelo

1. Copie el programa de modelo SAPDNW7AW_EXCEPTIONS_T1 aZDNW7AW_EXCEPTIONS_##_1. (## representa el número de grupo dedos dígitos). El programa es una calculadora sencilla.

Active su copia.

a) Proceda de la manera habitual.

Tarea 2:Provocar una excepción (dump)

1. Realice las entradas necesarias en la pantalla de selección para provocarlos errores siguientes y fíjese en las excepciones provocadas en el análisisdel dump:

División entre cero

Desbordamiento

Entradas de caracteres en vez de numéricas. (En realidad el desarrollador delprograma podría haberlo evitado poniendo campos de enteros en el campode selección, en vez de campos de caracteres...)

Consejo: Para analizar también dumps a posteriori, inicie latransacción ST22.

a) Inicie el programa con F8

Tarea 3:Interceptar excepciones

1. La operación se calcula en el programa, en el evento ATSELECTION-SCREEN.

Proceso de fondo: Si intercepta errores aquí y envía mensajes de correoelectrónico, los usuarios tendrán que cambiar sus entradas en la pantallade selección.

Intercepte las excepciones con el concepto de excepción basado en clasedel modo siguiente:

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 319

Page 334: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

En el caso de la división entre cero, se debería visualizar el siguiente mensajede error: �Ni siquiera ABAP puede dividir entre cero.�

En caso de desbordamiento o si se introduce un operando no válido, el objetode excepción generado por el sistema debería ser interceptado, y el resultadode este método GET_TEXT se debería visualizar como mensaje de error.

a) Consulte la solución modelo.

Resultado

Solución modelo

REPORT sapdnw7aw_exceptions_s1.

DATA:

ge_result TYPE p DECIMALS 2,

ge_message TYPE string,

gx_error TYPE REF TO cx_root.

PARAMETERS:

pa_int1 TYPE c LENGTH 10 DEFAULT ’9999999999’,

pa_op TYPE dnw7aw_operator OBLIGATORY DEFAULT ’*’ VALUE CHECK,

pa_int2 TYPE c LENGTH 10 DEFAULT ’9999999999’.

AT SELECTION-SCREEN.

TRY.

CASE pa_op.

WHEN ’+’.

ge_result = pa_int1 + pa_int2.

WHEN ’-’.

ge_result = pa_int1 - pa_int2.

WHEN ’*’.

ge_result = pa_int1 * pa_int2.

WHEN ’/’.

TRY.

ge_result = pa_int1 / pa_int2.

CATCH cx_sy_zerodivide.

MESSAGE ’Even ABAP cannot divide by zero’(zer) TYPE ’E’.

ENDTRY.

ENDCASE.

CATCH cx_sy_arithmetic_overflow

cx_sy_conversion_no_number

INTO gx_error.

Continúa en la página siguiente

320 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 335: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

ge_message = gx_error->get_text( ).

MESSAGE ge_message TYPE ’E’.

ENDTRY.

START-OF-SELECTION.

WRITE: ’Result:’(res), ge_result.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 321

Page 336: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

322 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 337: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

309 Ejercicio 20: Creación y uso de clases deexcepción globalesDuración del ejercicio: 25 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Definir clases de excepción globales� Declarar, provocar y tratar excepciones basadas en clases

Ejemplo empresarialDesea probar el concepto de excepción basada en clase mediante un pequeñoejemplo.

Tarea 1:Crear una clase de excepción global

1. Cree una clase de excepción global llamada ZCX_DNW7AW_## . (##indica el número de grupo de dos dígitos). Seleccione la clase superior demanera que la verificación sintáctica determine si la excepción relevante setrata o si se propaga explícitamente. Los textos de error se deberían derivarde una clase de mensaje.

2. Cuando se provoca la excepción, el nombre de una aerolínea se deberíatransferir al objeto de excepción. Por ello, debe crear un atributo de instanciapública llamado CARRIER e introducirlo con referencia a SCARR-CARRID.

3. Cada clase tiene automáticamente un ID de texto llamado igual que la clase.Determine el uso del mensaje 005 de la clase de mensaje DNW7AW parasu ID de texto ZCX_DNW7AW_##.

4. Cree otro ID de texto y llámelo CARRIER_WRONG. Determine que se debeusar el mensaje 006 de la clase de mensaje DNW7AW para este ID detexto. Este mensaje incluye una reserva-espacio (&1). En su lugar se debeusar el atributo CARRIER.

5. Active su clase de excepción.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 323

Page 338: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

Tarea 2:Copiar el programa de modelo

1. Copie el programa de modelo SAPDNW7AW_EXCEPTIONS_T2 aZDNW7AW_EXCEPTIONS_##_2. (## representa el número de grupo dedos dígitos.) Active la copia y familiarícese con las diversas funciones.

Tarea 3:Declarar y provocar una excepción

1. Amplíe la firma para el método READ_CARRIER_DETAILS de modo quese pueda provocar una excepción de la clase ZCX_DNW7AW_##.

2. Amplíe la implementación del método READ_CARRIER_DETAILS demodo que se provoque una excepción del tipo ZCX_DNW7AW_## si nose encuentra ninguna aerolínea con la selección de base de datos. UseCARRIER_WRONG para el ID de texto. La abreviatura de la aerolíneatambién se debe transferir.

3. Interrumpa la excepción posible en START-OF-SELECTION. Si se produceun error, llame el método GET_TEXT y visualice el texto resultante en lalista.

324 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 339: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

Solución 20: Creación y uso de clases deexcepción globalesTarea 1:Crear una clase de excepción global

1. Cree una clase de excepción global llamada ZCX_DNW7AW_## . (##indica el número de grupo de dos dígitos). Seleccione la clase superior demanera que la verificación sintáctica determine si la excepción relevante setrata o si se propaga explícitamente. Los textos de error se deberían derivarde una clase de mensaje.

a) Visualice la lista de objetos para el paquete en la transacción SE80. Acontinuación, haga clic en el paquete con el botón derecho del ratón yseleccione Crear→ Biblioteca de clases→ Clase.

b) En la siguiente pantalla, introduzca el nombre ZCX_DNW7AW_##.Introduzca una descripción adecuada. Seleccione Clase de excepción yCon clase de mensaje. Grabe la clase.

2. Cuando se provoca la excepción, el nombre de una aerolínea se deberíatransferir al objeto de excepción. Por ello, debe crear un atributo de instanciapública llamado CARRIER e introducirlo con referencia a SCARR-CARRID.

a) En el Object Navigator, vaya a la etiqueta Atributos de la vista detalladade su clase. Sitúe el cursor en el primer campo en blanco de la columnaAtributo e introduzca: INSTANCIA AEROLÍNEA PÚBLICA TIPOSCARR-CARRID en las columnas relevantes. Pulse Intro.

3. Cada clase tiene automáticamente un ID de texto llamado igual que la clase.Determine el uso del mensaje 005 de la clase de mensaje DNW7AW parasu ID de texto ZCX_DNW7AW_##.

a) En el Object Navigator, vaya a la etiqueta Textos de la vista detalladade su clase. Sitúe el cursor en el ID de excepción ZCX_DNW7AW_##y haga clic en Texto de mensaje. En la siguiente pantalla, introduzca laclase de mensaje DNW7AW y el mensaje 005. Grabe las entradas.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 325

Page 340: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

4. Cree otro ID de texto y llámelo CARRIER_WRONG. Determine que se debeusar el mensaje 006 de la clase de mensaje DNW7AW para este ID detexto. Este mensaje incluye una reserva-espacio (&1). En su lugar se debeusar el atributo CARRIER.

a) En el Object Navigator, vaya a la etiqueta Textos de la vista detalladade su clase. Sitúe el cursor en el primer campo en blanco de la columnaID de excepción e introduzca CARRIER_WRONG. Haga clic en Textode mensaje. En la siguiente pantalla, introduzca la clase de mensajeDNW7AW y el mensaje 005. Para el Atributo 1, marque la entradaCARRIER. Grabe las entradas.

5. Active su clase de excepción.

a) Haga clic en o seleccione Ctrl + F3.

Tarea 2:Copiar el programa de modelo

1. Copie el programa de modelo SAPDNW7AW_EXCEPTIONS_T2 aZDNW7AW_EXCEPTIONS_##_2. (## representa el número de grupo dedos dígitos.) Active la copia y familiarícese con las diversas funciones.

a) Proceda de la manera habitual.

Tarea 3:Declarar y provocar una excepción

1. Amplíe la firma para el método READ_CARRIER_DETAILS de modo quese pueda provocar una excepción de la clase ZCX_DNW7AW_##.

a) Consulte la solución modelo.

2. Amplíe la implementación del método READ_CARRIER_DETAILS demodo que se provoque una excepción del tipo ZCX_DNW7AW_## si nose encuentra ninguna aerolínea con la selección de base de datos. UseCARRIER_WRONG para el ID de texto. La abreviatura de la aerolíneatambién se debe transferir.

a) Consulte la solución modelo.

3. Interrumpa la excepción posible en START-OF-SELECTION. Si se produceun error, llame el método GET_TEXT y visualice el texto resultante en lalista.

a) Consulte la solución modelo.

ResultadoSolución modelo

Continúa en la página siguiente

326 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 341: TAW12_01

TAW12_1 Lección: Excepciones basadas en clases

REPORT sapdnw7aw_exceptions_s2.

DATA: gx_no_data TYPE REF TO cx_dnw7aw_no_data,

gs_carrier TYPE scarr,

ge_text TYPE string.

*---------------------------------------------------------------------*

CLASS lcl_carrier DEFINITION.

PUBLIC SECTION.

CLASS-METHODS:

read_carrier_details

IMPORTING ie_carrid TYPE scarr-carrid

RETURNING value(re_carrier) TYPE scarr

RAISING cx_dnw7aw_no_data.

ENDCLASS. "lcl_carrier

*---------------------------------------------------------------------*

CLASS lcl_carrier IMPLEMENTATION.

METHOD read_carrier_details.

SELECT SINGLE * FROM scarr INTO re_carrier

WHERE carrid = ie_carrid.

IF sy-dbcnt = 0.

RAISE EXCEPTION TYPE cx_dnw7aw_no_data

EXPORTING

textid = cx_dnw7aw_no_data=>carrier_wrong

carrier = ie_carrid.

ENDIF.

ENDMETHOD. "read_carrier_details

ENDCLASS. "lcl_carrier

*---------------------------------------------------------------------

*START-OF-SELECTION.

TRY.

gs_carrier = lcl_carrier=>read_carrier_details( ’XY’ ).

WRITE:

/ gs_carrier-carrid,

gs_carrier-carrname,

gs_carrier-currcode.

CATCH cx_dnw7aw_no_data INTO gx_no_data.

ge_text = gx_no_data->get_text( ).

WRITE: / ge_text.

ENDTRY.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 327

Page 342: TAW12_01

Capítulo 4: El concepto de la excepción basada en clase TAW12_1

Resumen de la lección

Ahora podrá:� Gestionar excepciones basadas en clases en programas ABAP� Crear clases de excepción� Crear excepciones basadas en clases en programas ABAP� Propagar excepciones basadas en clases en programas ABAP� Asignar excepciones basadas en clases entre sí en programas ABAP

328 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 343: TAW12_01

TAW12_1 Resumen del capítulo

Resumen del capítuloAhora podrá:� Gestionar excepciones basadas en clases en programas ABAP� Crear clases de excepción� Crear excepciones basadas en clases en programas ABAP� Propagar excepciones basadas en clases en programas ABAP� Asignar excepciones basadas en clases entre sí en programas ABAP

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 329

Page 344: TAW12_01

Resumen del capítulo TAW12_1

330 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 345: TAW12_01

TAW12_1 Examine sus conocimientos

317Examine sus conocimientos

1. El nuevo concepto de excepción sustituye el concepto antiguo. Por tanto,todas las secciones de código fuente anteriores deben escribirse de nuevo. Apartir de SAP Web Application Server 6.20, los módulos de funciones de laversión estándar del sistema SAP provocan automáticamente excepcionesorientadas a objetos.

Diga si estas afirmaciones son correctas o falsas.□ Correcto□ Falso

2. Al contrario que las excepciones antiguas, las nuevas se pueden emitirtambién desde subrutinas y propagarse.Diga si estas afirmaciones son correctas o falsas.□ Correcto□ Falso

3. Las clases de excepción nuevas sólo se pueden definir globalmente. De estamanera se garantiza una actualización y reutilización central.Diga si estas afirmaciones son correctas o falsas.□ Correcto□ Falso

4. Cuando se define una clase de excepción, la superclase elegida especificasi las excepciones se deben interceptar de forma explícita o no conTRY-CATCH-ENDTRY y, en caso afirmativo, cómo reaccionará el sistema sila excepción no se intercepta.Diga si estas afirmaciones son correctas o falsas.□ Correcto□ Falso

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 331

Page 346: TAW12_01

Examine sus conocimientos TAW12_1

318Respuestas

1. El nuevo concepto de excepción sustituye el concepto antiguo. Por tanto,todas las secciones de código fuente anteriores deben escribirse de nuevo. Apartir de SAP Web Application Server 6.20, los módulos de funciones de laversión estándar del sistema SAP provocan automáticamente excepcionesorientadas a objetos.

Respuesta: Falso

Los módulos de funciones pueden usar el concepto de excepción nuevo oel anterior.

2. Al contrario que las excepciones antiguas, las nuevas se pueden emitirtambién desde subrutinas y propagarse.

Respuesta: Correcto

Véase la sección relevante de la unidad.

3. Las clases de excepción nuevas sólo se pueden definir globalmente. De estamanera se garantiza una actualización y reutilización central.

Respuesta: Falso

Véase la sección relevante de la unidad.

4. Cuando se define una clase de excepción, la superclase elegida especificasi las excepciones se deben interceptar de forma explícita o no conTRY-CATCH-ENDTRY y, en caso afirmativo, cómo reaccionará el sistema sila excepción no se intercepta.

Respuesta: Correcto

Véase la sección relevante de la unidad.

332 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 347: TAW12_01

Capítulo 5319 Objetos compartidos

Since this unit contains only one lesson, you will find the instructor notes here too.

Resumen del capítuloEn esta unidad se explica cómo realizar objetos compartidos, un área especial dememoria que varios usuarios pueden usar a la vez. Se ofreció por primera vez conSAP NetWeaver 2004.

Objetivos del capítuloAl finalizar este capítulo podrá:

� Explicar cómo se crean clases para objetos compartidos� Explicar cómo se pueden utilizar objetos compartidos para implementar

aplicaciones� Acceder a objetos compartidos desde un programa ABAP

Contenido del capítuloLección: Objetos compartidos.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .334

Ejercicio 21: Objetos compartidos .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .355

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 333

Page 348: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Lección:320

Objetos compartidosDuración de la lección: 60 Minutos

Resumen de la lecciónA partir de SAP NetWeaver 2004, puede almacenar datos en forma de objetoscompartidos en la memoria compartida. En esta lección, examinaremos esteconcepto y su implementación.

La ventaja de esta técnica es que los datos se pueden grabar como objetos. Losprogramas pueden acceder rápidamente a estos datos, independientemente delmodo de usuario. Esta técnica se ha desarrollado con el objetivo principal degrabar información de catálogo y de cestas de la compra. Un atributo de loscatálogos es que se leen a menudo, pero rara vez se modifican. En el caso delas cestas de la compra, una aplicación escribe los datos y posteriormente otroprograma los lee (en un modo de usuario diferente). Además, esta técnica ofreceun rendimiento considerablemente mejor que el obtenido al guardar los datospersistentemente en la base de datos.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Explicar cómo se crean clases para objetos compartidos� Explicar cómo se pueden utilizar objetos compartidos para implementar

aplicaciones� Acceder a objetos compartidos desde un programa ABAP

The instructor should ensure that the terms are clearly understood, as the subjectmatter is very complex.

Ejemplo empresarialEl Sr. Jiménez es un programador de software de una importante empresa quedesarrolla aplicaciones empresariales de propiedad en ABAP. Se le ha encargadoel desarrollo de una nueva aplicación para reservas de vuelos. Un requisito de laaplicación es que muchos empleados deben poder acceder a la vez a los datosdel mismo cliente sin necesidad de tener que leer cada vez los datos de la basede datos. El Sr. Jiménez sabe que los objetos compartidos se pueden utilizarpara permitir la accesibilidad de los datos de la memoria principal sin límites demodo. Por lo tanto, utiliza objetos compartidos para desarrollar su aplicaciónde reserva de vuelos.

334 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 349: TAW12_01

TAW12_1 Lección: Objetos compartidos

Acceso a objetos compartidosA partir de SAP NetWeaver 2004, puede almacenar datos en forma de objetoscompartidos entre programas y modos de usuario en la memoria compartida. Estopermite crear aplicaciones en las que los usuarios escriben datos en esta área.Otros usuarios pueden leer estos datos más adelante.

Es posible imaginar muchos usos potenciales distintos para los objetoscompartidos:

� Guardar un catálogo

Un �autor� escribe un catálogo en el área de objetos compartidos al quepueden acceder muchos usuarios a la vez.

� Grabar una cesta de la compra

El encargado de compras rellena el cesto de la compra y el vendedor lee losdatos más adelante.

Memoria compartidaLa memoria compartida es un área de la memoria de un servidor de aplicación alque pueden acceder todos los programas ABAP que se ejecutan en dicho servidor.

Gráfico 144: Modelo de memoria de un servidor de aplicación

Antes de que existieran los objetos compartidos, las sentencias ABAP debíanutilizar las sentencias EXPORT y IMPORT con los suplementos SHAREDBUFFER y SHARED MEMORY para acceder a esta área de la memoria. Instanciasde clases "residían" exclusivamente en el modo interno de un programa ABAP.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 335

Page 350: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Con la introducción de los objetos compartidos en SAP NetWeaver 2004, lamemoria compartida se ha ampliado conMemoria de objetos compartidos,donde se pueden grabar los objetos compartidos. Estos objetos compartidos segraban en áreas de la memoria compartida.

Nota: SAP NetWeaver 2004 sólo admite el almacenamiento de instanciasde clase.

A partir de SAP NetWeaver 7.0 se puede almacenar referencias de datosque señalen a objetos de datos de la misma versión de instancia de área enla memoria compartida. Puede utilizar los tipos siguientes para el objetode datos anónimo: todos los tipos de datos visibles de clases e interfasesglobales, tablas de base de datos y estructuras en el Dictionary ABAP,tipos de datos de grupos de tipos. No obstante, (aún) no es posible crearreferencias de datos en la memoria compartida cuyos objetos de datostengan el tipo de elementos de datos o tipos de tabla.

Aún no es posible grabar ningún objeto de datos como objeto compartido.Sin embargo, los objetos de datos que no son variables de referencia sepueden almacenar como atributos de clases.

Gráfico 145: Acceso a objetos compartidos

336 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 351: TAW12_01

TAW12_1 Lección: Objetos compartidos

Atributos de objetos compartidos

� Grabación en la memoria intermedia de todos los programas de datos que seleen con frecuencia pero raramente se escriben.

(Recomendación: de una vez al día a una vez cada hora).

� Los accesos de lectura simultáneos están soportados.� El acceso está regulado por un mecanismo de bloqueo.� Los datos se guardan como atributos de objeto.� Los cuellos de botella de memoria derivan en errores en tiempo de ejecución

y deben ser interceptados.

Los accesos de escritura se deben realizar en contadas ocasiones debido a que laescritura de datos en el área de objetos compartidos consume mucho rendimiento.En este caso se trata de optimizar el tiempo de ejecución, lo cual no sería posibleen caso de que el acceso de escritura se realizara con mayor frecuencia.

Nota: SAP usa también internamente los objetos compartidos. Estatécnica se utiliza, por ejemplo, para navegar en el Workbench ABAP.Además del ahorro de memoria (aproximadamente 3 MB por entrada alsistema del usuario), la navegación durante el primer acceso es más rápidoen un factor de 100.

Un requisito previo para guardar un objeto en la memoria compartida es quela clase del objeto se haya definido con el suplemento SHARED MEMORYENABLED de la sentencia CLASS, o que el atributo Memoria compartidapermitida esté seleccionado en el generador de clases.

Áreas e instancias de área

Gráfico 146: Áreas e instancias de área

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 337

Page 352: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Un área es un modelo para instancias de área en la memoria compartida. Apartir de un área se pueden crear varias instancias de área con nombres distintos.Además, una instancia de área puede tener varias versiones (�versiones deinstancia de área�) con distintos ID de versión. En el caso más sencillo, sin gestiónde versiones, una instancia de área consta de una única versión.

Clases de área y handles de área

Gráfico 147: Creación de un área

Defina un área en la transacción SHMA. Se crea una clase de área final global conel mismo nombre que una subclase de CL_SHM_AREA. En un programa ABAP,se accede al área exclusivamente mediante métodos de la clase de área generada.

Consejo: Debido a que el área y la clase de área tienen el mismo nombre,es lógico asignar un nombre al área según las convenciones para fijarnombres correspondientes a las clases � ZCL_*, por ejemplo, en el áreapara nombres del cliente.

Puede utilizar métodos estáticos (métodos para �vincular�) de una clase deárea para conectar un programa ABAP (o su modo interno, donde se procesa elprograma ABAP) a una instancia de área en la memoria compartida. Al conectarun programa ABAP, se crea una instancia de la clase de área como un handlede área.

338 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 353: TAW12_01

TAW12_1 Lección: Objetos compartidos

En el diagrama anterior se muestra además otra clase denominada la clase de raízde área. Puede crear un número indeterminado de objetos en una instancia deárea, dependiendo de la aplicación específica. Acceda a estos objetos de manerauniforme a través de la instancia de la clase de raíz de área.

Nota: Nos limitaremos a dos clases en un ejemplo específico.

Desarrollo de una aplicación de ejemplo

Gráfico 148: Aplicación de ejemplo

En esta lección, desarrollaremos una sencilla aplicación de catálogo comoejemplo. Vamos a utilizar objetos compartidos para crear un catálogo de fechas devuelo donde los usuarios puedan seleccionar un vuelo.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 339

Page 354: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Gráfico 149: Acceso a áreas

En el diagrama se ilustra de nuevo el hecho de que cualquier programa puedaacceder a objetos en la memoria de objetos compartidos. En este caso, dosaplicaciones, que se ejecutan en diferentes modos de usuario, acceden a objetos enla misma área. Por tanto, necesitaremos varias cosas para la aplicación de ejemplo:

� Creación de un área� Desarrollo de un programa para crear una instancia de área� Desarrollo de un programa para leer datos desde el área

Creación de un áreaLos objetos compartidos se graban en áreas de la memoria compartida. Utilice latransacción SHMA para crear y gestionar áreas y sus atributos.

Gráfico 150: Gestión de área (transacción SHMA)

340 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 355: TAW12_01

TAW12_1 Lección: Objetos compartidos

Llame el código de transacción SHMA e introduzca el nombre del área. Se aplicanlas reglas habituales del área de nombres, es decir, el nombre de área debe empezarpor Y o Z en el sistema del cliente. También se admiten áreas de nombres quecontienen barras diagonales.

Consejo: Tenga en cuenta que se crea una clase de área final global con elmismo nombre que una subclase de CL_SHM_AREA. Por tanto, tienelógica seleccionar el nombre de área con inteligencia, tal como se muestraen nuestro ejemplo.

En un programa ABAP, se accede más tarde al área exclusivamente mediantemétodos de la clase de área generada.

Gráfico 151: Actualización de áreas

Después de pulsar Crear, Modificar o Visualizar, se visualiza la imagende actualización de áreas.

Cada área está enlazada con una clase de raíz de área global, cuyos atributospueden contener datos de propiedad y referencias a otras clases compartidas dememoria habilitada. La clase de raíz de área se debe asignar a un área cuandose actualiza. Si una versión de instancia de área no está vacía, debe contener almenos una instancia de la clase de raíz de área como su objeto raíz, que se utilizacomo referencia a otros objetos. Al generar la clase de área, se genera un atributoROOT y se le asigna el tipo estático de la clase de raíz de área.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 341

Page 356: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Otros términos importantes para crear un áreaÁrea dependiente del mandante

Las áreas y, por tanto, los objetos de un área, no tienen un ID de mandantepor defecto. No obstante, puede especificar un área como dependiente delmandante. En las áreas dependientes del mandante, los métodos de la clasede área para acceder a una instancia hacen referencia al mandante activo pordefecto. Puede utilizar el parámetro de importación opcional CLIENT paraacceder explícitamente a otro mandante.

Área transaccionalUna versión de instancia de área de un área transaccional no se activainmediatamente cuando se quita un bloqueo de las modificaciones medianteel método DETACH_COMMIT; sólo se activa después del siguiente commiten la base de datos.Esto resulta particularmente útil en la implementación de cestas de la compraen la memoria de objetos compartidos.

Configuración de una instancia de áreaEn la última sección, hemos definido un área. También hemos creado las clasesque se instanciarán en este área. En esta sección, examinaremos las sentenciasque podemos utilizar para crear una instancia de área. Utilizaremos el ejemploanterior.

Gráfico 152: Antes de crear una instancia de área

342 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 357: TAW12_01

TAW12_1 Lección: Objetos compartidos

Al crear un área, se crea también una clase final global con el mismo nombre.Para configurar un área o acceder a un área existente, es necesaria una variable dereferencia con la clase de área genérica. Esta referencia se utiliza como handlepara acceder al área.

Gráfico 153: Creación de una instancia de área

Al crear una instancia de clase de área, se crea una instancia del área en la memoriacompartida. El programa debe obtener además el handle para la instancia de área.A partir de entonces, todas las operaciones se realizarán con el handle.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 343

Page 358: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Gráfico 154: Generación de objetos en la memoria compartida

Una vez que se ha creado la instancia de área, los objetos se pueden crear en lamemoria de objetos compartidos. Para ello, utilice el suplemento AREA HANDLEpara la sentencia CREATE OBJECT. Se indica al sistema la instancia de áreadonde se crearán los objetos.

Gráfico 155: Generación de objetos en la memoria compartida II

344 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 359: TAW12_01

TAW12_1 Lección: Objetos compartidos

En el diagrama anterior, se crean instancias de ambos objetos en el programa.Otra opción es crear una instancia del objeto raíz desde el programa. También sepueden crear los demás objetos en esta instancia de área a partir del constructordel objeto raíz.

En este caso no es necesario asignar las referencias.

Gráfico 156: Configuración del objeto raíz

Para direccionar los objetos creados en la instancia de área, debe asignar el objetoraíz al atributo ROOT del handle de área. Para ello, utilice el método SET_ROOTdel handle de área.

Como consecuencia, cualquier programa de cualquier aplicación puede acceder aesta área. Para ello, la aplicación solamente tiene que llamar una referencia en lainstancia de área y, a continuación, podrá acceder inmediatamente a los objetosque contiene dicha instancia de área.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 345

Page 360: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Gráfico 157: Eliminación del bloqueo de escritura

El acceso de lectura a una instancia de área no es posible hasta que no se canceleel bloqueo de escritura. Para ello, utilice el método DETACH_COMMIT que heredala clase de área de la clase CL_SHM_AREA.

Acceso a una instancia de áreaUna vez que se ha configurado una instancia de área, cualquier usuario yaplicación podrá acceder a ella. Los programas de lectura deben implementar lossiguientes pasos:

346 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 361: TAW12_01

TAW12_1 Lección: Objetos compartidos

Gráfico 158: Acceso a un objeto existente en la memoria compartida

Los programas de lectura necesitan primero una variable de referencia con el tipode clase de área. Esta variable de referencia permite acceder a la instancia de área.

El programa debe obtener además el handle de la instancia de área. Esto seconsigue mediante el método ATTACH_FOR_READ que proporciona la claseCL_SHM_AREA. Se establece un bloqueo de lectura que impide el borrado dela instancia de área durante el acceso.

Ahora se puede acceder a los objetos de esta instancia de área, siempre utilizandoel handle de área.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 347

Page 362: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Gráfico 159: Eliminación del bloqueo de lectura

Una vez finalizada la actividad de lectura, la aplicación elimina el bloqueo delectura. Se puede usar el método DETACH para el handle de área para este fin. Elbloqueo de lectura se puede eliminar también automáticamente cuando se cierrael modo interno.

Estados de las versiones de instancia de áreaAl crear un área, puede especificar que se permitan varias versiones de unainstancia de área. ¿Qué significan exactamente estas versiones de instancia deárea? Para responder a esta pregunta, examinaremos un ejemplo en la siguientesección.

Para supervisar las instancias de área para objetos compartidos, se utiliza latransacción SHMM.

348 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 363: TAW12_01

TAW12_1 Lección: Objetos compartidos

Versión activa

Gráfico 160: Configuración de un bloqueo de lectura en la versión activa

El estado normal es el siguiente: se ha configurado una instancia de área. Unavez finalizada la configuración (con el método DETACH_COMMIT) y cuando elsistema haya enviado un commit en base de datos, la versión de la instancia deárea pasará a estar activa.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 349

Page 364: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Versión objeto de la configuración

Gráfico 161: Versión objeto de la configuración

Si el atributo Número de versiones del área está definido correctamente, puedenexistir versiones adicionales de la instancia de área además de la versión activa.

Una vez que se ha configurado un nuevo catálogo, existen varias versionestemporales de la misma instancia de área. Tan pronto como una aplicaciónestablece un bloqueo de modificación para una instancia de área, se crea una�versión objeto de configuración� en paralelo a la versión activa.

350 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 365: TAW12_01

TAW12_1 Lección: Objetos compartidos

Versión obsoleta

Gráfico 162: Escritura finalizada. La versión anterior está obsoleta.

Si la configuración de la nueva versión ha finalizado durante un acceso de lecturade la versión actualmente activa, se activa la versión objeto de configuración. A laversión anteriormente activa se le asigna el atributo Obsoleta.

Gráfico 163: Nuevos bloqueos de lectura para la nueva versión activa

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 351

Page 366: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Los bloqueos de lectura de la versión obsoleta se mantienen hasta que finalicenlas operaciones de lectura. En contraste, los nuevos bloqueos de lectura para lainstancia de área están siempre establecidos para la versión activa. Por tanto, doslectores diferentes podrían obtener dos resultados de lectura distintos en este caso.

Versión caducada

Gráfico 164: Ningún bloqueo de lectura para la versión obsoleta: la versiónha caducado

Al eliminar el último bloqueo de lectura existente para una versión obsoleta, laversión caduca. El recolector de basura se encarga de eliminarlo. No se puedenestablecer bloqueos para versiones caducadas, ni se utilizan para determinar elnúmero de versiones (esto es importante si el número de versiones de instancia deárea se ha restringido).

352 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 367: TAW12_01

TAW12_1 Lección: Objetos compartidos

Gráfico 165: Nuevos bloqueos de lectura para la versión activa

Siempre se establecen nuevos bloqueos de lectura para la versión activa. Sólopuede haber una versión activa para cada instancia. Dependiendo del númeromáximo de versiones, pueden existir en paralelo varias versiones desfasadas paralas cuales aún hay establecidos bloqueos de lectura.

Demo in the system:

Area: CL_DNW7AW_SHARED_OBJ_AREA

Root class: CL_DNW7AW_SHARED_OBJ_ROOT

Catalog class: CL_DNW7AW_SHARED_OBJ_CATALOG

Write program: SAPDNW7AW_SHARED_OBJ_WRITER_D1

Read program: SAPDNW7AW_SHARED_OBJ_READER_D1

Where possible, you should program everything in front of the audience. Youcan dispense (initially) with the catalog class and define the itab with the linksdirectly as a public instance attribute for the root class. The correct sequencewould then be:

1. Create root class2. Create area3. Create write program4. Execute write program and check result in SHMA monitor5. Create and execute read program

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 353

Page 368: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

354 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 369: TAW12_01

TAW12_1 Lección: Objetos compartidos

341 Ejercicio 21: Objetos compartidosDuración del ejercicio: 35 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Crear un área de objetos compartidos� Escribir datos en un área de objetos compartidos� Leer datos de un área de objetos compartidos

Ejemplo empresarialDesea poner en funcionamiento una tienda en Internet basándose en un sistemaSAP. En este ejercicio creará las bases para ello, concretamente al guardar losvuelos ofertados. Para que sus clientes de Internet puedan acceder lo más rápidoposible a las ofertas, guarde la información de los vuelos en la memoria de objetoscompartidos.

Necesitará un �programa de escritura� para gestionar y describir esta información,y también tendrá que desarrollar una aplicación de test para leer los datos.

Datos del sistemaSistema: Will be assignedMandante: Will be assignedID de usuario: Will be assignedClave de acceso: Will be assignedParametrizaciones del sistema: No special settings required in the standardtraining system

Tarea 1:Crear una clase de raíz

1. Cree una clase global ZCL_DNW7AW_ROOT_##. (## indica el número degrupo de dos dígitos). La memoria compartida debería estar habilitada.

La clase debería tener una tabla interna pública llamadaMT_FLIGHTS deltipo TY_FLIGHTS como único componente (instancia).

Active la clase.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 355

Page 370: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Tarea 2:Crear un área en la memoria de objetos compartidos

1. Cree un área llamada ZCL_DNW7AW_AREA_## mediante la transacciónSHMA. Este área deberá contener los siguientes atributos:

Específico de mandanteCon gestión de versionesDesplazamiento imposibleClase de raíz: ZCL_DNW7AW_ROOT_##

Tarea 3:Crear un programa de escritura para configurar una instancia de área enla memoria de objetos compartidos

1. Cree un programa con el tipo Programa ejecutable.

Nombre del programa: ZDNW7AW_WRITE_CATALOG_##.

2. Necesita dos variables de referencia: una para el handle de área y otra para laclase de raíz de área.

3. Genere una instancia de área y una instancia para la clase de raíz de área.Enlace la instancia de clase de raíz de área al handle de instancia de área.

4. Lea todos los datos de la tabla de base de datos SFLIGHT para el atributo(público) MT_FLIGHTS de la instancia de clase de raíz de área.

5. No olvide eliminar el bloqueo de escritura una vez que los datos se hayanescrito correctamente.

6. Inicie el programa en modo debugging y siga la creación paso a paso del áreay los bloqueos activados en una ventana separada, en la transacción SHMM.

Tarea 4:Implementar un programa de lectura

1. Cree un programa con el tipo Programa ejecutable.

Nombre del programa: ZDNW7AW_READ_CATALOG_##.

2. Necesita una variable de referencia para el handle de área.

Cree un bloqueo de lectura en el área. El handle permite acceder ahoraal objeto de clase de raíz y, en consecuencia, a su tabla interna con lainformación de los vuelos.

Visualice el contenido de la tabla interna con la sentencia WRITE.

Continúa en la página siguiente

356 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 371: TAW12_01

TAW12_1 Lección: Objetos compartidos

Una solución más elegante sería la edición con el ALV. Para ello, debe copiarel contenido de la tabla interna en la memoria de objetos compartidos a unatabla de programa interna a la que se haya asignado el tipo exactamente delmismo modo. (El ALV necesita acceso de escritura a la tabla interna).

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 357

Page 372: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Solución 21: Objetos compartidosTarea 1:Crear una clase de raíz

1. Cree una clase global ZCL_DNW7AW_ROOT_##. (## indica el número degrupo de dos dígitos). La memoria compartida debería estar habilitada.

La clase debería tener una tabla interna pública llamada MT_FLIGHTS deltipo TY_FLIGHTS como único componente (instancia).

Active la clase.

a) Cree la clase en el Object Navigator (transacción SE80) de la formahabitual. En la etiqueta Propiedades, seleccione Memoria compartidapermitida.

b) Cree la tabla interna en la etiqueta Atributos.

c) Pulse Ctrl + F3.

Tarea 2:Crear un área en la memoria de objetos compartidos

1. Cree un área llamada ZCL_DNW7AW_AREA_## mediante la transacciónSHMA. Este área deberá contener los siguientes atributos:

Específico de mandanteCon gestión de versionesDesplazamiento imposibleClase de raíz: ZCL_DNW7AW_ROOT_##

a) Introduzca ZCL_DNW7AW_AREA_## en la pantalla inicial de latransacción SHMA y seleccione Crear. En la siguiente pantalla,introduzca los detalles necesarios. Grabe las entradas.

Tarea 3:Crear un programa de escritura para configurar una instancia de área enla memoria de objetos compartidos

1. Cree un programa con el tipo Programa ejecutable.

Nombre del programa: ZDNW7AW_WRITE_CATALOG_##.

a) Proceda de la manera habitual.

Continúa en la página siguiente

358 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 373: TAW12_01

TAW12_1 Lección: Objetos compartidos

2. Necesita dos variables de referencia: una para el handle de área y otra para laclase de raíz de área.

a) Consulte la solución modelo.

3. Genere una instancia de área y una instancia para la clase de raíz de área.Enlace la instancia de clase de raíz de área al handle de instancia de área.

a) Consulte la solución modelo.

4. Lea todos los datos de la tabla de base de datos SFLIGHT para el atributo(público) MT_FLIGHTS de la instancia de clase de raíz de área.

a) Consulte la solución modelo.

5. No olvide eliminar el bloqueo de escritura una vez que los datos se hayanescrito correctamente.

a) Consulte la solución modelo.

6. Inicie el programa en modo debugging y siga la creación paso a paso del áreay los bloqueos activados en una ventana separada, en la transacción SHMM.

a) Inicie la transacción SHMM. Después de ejecutar el métodoATTACH_FOR_WRITE y actualizar la visualización, debería poder verel área ZCL_DNW7AW_AREA_## y se debería visualizar un bloqueode escritura en la transacción SHMM. Después del comando SELECT,la tabla interna de la instancia de área debería estar completada.Después de llamar el método DETACH_COMMIT, sólo debería haberuna versión activa, sin bloqueos. Ahora puede comprobar también elcontenido de la tabla interna: Haga doble clic en el área. En la pantallasiguiente, marque la versión de instancia de área (predeterminada) yluego seleccione Leer versión activa.

Tarea 4:Implementar un programa de lectura

1. Cree un programa con el tipo Programa ejecutable.

Nombre del programa: ZDNW7AW_READ_CATALOG_##.

a) Proceda de la manera habitual.

2. Necesita una variable de referencia para el handle de área.

Cree un bloqueo de lectura en el área. El handle permite acceder ahoraal objeto de clase de raíz y, en consecuencia, a su tabla interna con lainformación de los vuelos.

Visualice el contenido de la tabla interna con la sentencia WRITE.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 359

Page 374: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Una solución más elegante sería la edición con el ALV. Para ello, debe copiarel contenido de la tabla interna en la memoria de objetos compartidos a unatabla de programa interna a la que se haya asignado el tipo exactamente delmismo modo. (El ALV necesita acceso de escritura a la tabla interna).

a) Consulte la solución modelo.

Resultado

Programa para escribir los datos

REPORT sapdnw7aw_shared_obj_writer_s1.

DATA: go_handle TYPE REF TO cl_dnw7aw_shared_obj_area_s1,

go_root TYPE REF TO cl_dnw7aw_shared_obj_root_s1.

TRY.

go_handle = cl_dnw7aw_shared_obj_area_s1=>attach_for_write( ).

CREATE OBJECT go_root AREA HANDLE go_handle.

go_handle->set_root( go_root ).

SELECT * FROM sflight INTO TABLE go_root->mt_flights.

CALL METHOD go_handle->detach_commit.

CATCH cx_shm_exclusive_lock_active

cx_shm_version_limit_exceeded

cx_shm_change_lock_active

cx_shm_parameter_error

cx_shm_pending_lock_removed

cx_shm_wrong_handle

cx_shm_already_detached

cx_shm_secondary_commit

cx_shm_event_execution_failed

cx_shm_completion_error.

ENDTRY.

Programa para leer los datos

REPORT sapdnw7aw_shared_obj_reader_s1.

DATA: go_handle TYPE REF TO cl_dnw7aw_shared_obj_area_s1,

gt_sflight TYPE ty_flights,

gs_sflight TYPE sflight,

Continúa en la página siguiente

360 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 375: TAW12_01

TAW12_1 Lección: Objetos compartidos

go_alv TYPE REF TO cl_salv_table.

TRY.

go_handle = cl_dnw7aw_shared_obj_area_s1=>attach_for_read( ).

LOOP AT go_handle->root->mt_flights INTO gs_sflight.

WRITE:

/ gs_sflight-carrid,

gs_sflight-connid,

gs_sflight-fldate,

gs_sflight-seatsocc,

gs_sflight-seatsmax.

ENDLOOP.

* Alternative: ALV display

* ALV requires write access to the table, hence a local copy

* is needed.

* gt_sflight = go_handle->root->mt_flights.

*

* CALL METHOD cl_salv_table=>factory

* IMPORTING

* r_salv_table = go_alv

* CHANGING

* t_table = gt_sflight.

*

* go_alv->display( ).

CALL METHOD go_handle->detach.

CATCH cx_shm_inconsistent

cx_shm_no_active_version

cx_shm_read_lock_active

cx_shm_exclusive_lock_active

cx_shm_parameter_error

cx_shm_change_lock_active

cx_salv_msg

cx_shm_wrong_handle

cx_shm_already_detached.

ENDTRY.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 361

Page 376: TAW12_01

Capítulo 5: Objetos compartidos TAW12_1

Resumen de la lección

Ahora podrá:� Explicar cómo se crean clases para objetos compartidos� Explicar cómo se pueden utilizar objetos compartidos para implementar

aplicaciones� Acceder a objetos compartidos desde un programa ABAP

362 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 377: TAW12_01

TAW12_1 Resumen del capítulo

Resumen del capítuloAhora podrá:� Explicar cómo se crean clases para objetos compartidos� Explicar cómo se pueden utilizar objetos compartidos para implementar

aplicaciones� Acceder a objetos compartidos desde un programa ABAP

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 363

Page 378: TAW12_01

Resumen del capítulo TAW12_1

364 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 379: TAW12_01

Capítulo 6349 Programación dinámica

This unit explains dynamic programming using field symbols. It concludes bydescribing RTTI and RTTC.

Resumen del capítuloLa sintaxis que da soporte a la programación dinámica con ABAP se amplíacontinuamente con cada release desde ABAP/4. En esta unidad se introducesistemáticamente todo su alcance.

Desde SAP R/3 4.6C, las clases estándar de SAP en ABAP permiten consultar losatributos de tipo en tiempo de ejecución. Este concepto (RTTI = identificaciónde tipo en tiempo de ejecución) se ha ampliado en SAP NetWeaver 2004 con unaopción para crear objetos dinámicos en tiempo de ejecución (RTTC = creación detipo en tiempo de ejecución). Combinados, estos dos conceptos forman los RTTS(Run Time Type Services), que se describen en la segunda parte de esta unidad.

Objetivos del capítuloAl finalizar este capítulo podrá:

� Acceder dinámicamente a componentes de clase y componentes de objeto� Definir símbolos de campo� Definir referencias de datos� Anular referencias de datos� Generar dinámicamente objetos de datos� Consultar atributos de tipo en tiempo de ejecución� Crear tipos dinámicamente

Contenido del capítuloLección: Programación dinámica con símbolos de campo y referencias 367

Ejercicio 22: Casting de tipo para estructuras ... . . . . . . . . . . . . . . . . . . . . . . .381

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 365

Page 380: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Lección: Run Time Type Services .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387Ejercicio 23: RTTI: consulta de los atributos de un tipo de datos.. . .397

366 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 381: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

Lección:350

Programación dinámica con símbolos de campo yreferenciasDuración de la lección: 120 Minutos

Resumen de la lecciónLa sintaxis que da soporte a la programación dinámica con ABAP se amplíacontinuamente con cada release desde ABAP/4. Nuestro objetivo en este casono es realizar un seguimiento de este desarrollo, sino presentar todo el alcancede forma sistemática.

No obstante, si conoce la historia puede comprender por qué a veces seimplementan conceptos similares utilizando estructuras de sintaxis muydivergentes.

Desde SAP Web AS 6.10, ABAP ofrece al menos las mismas opciones quepudiera conocer de otros lenguajes de programación. En contraste con estosotros lenguajes, ABAP puede confiar en la compatibilidad del Workbench ABAP,incluso en el área de la programación dinámica.

Objetivos de la lecciónAl finalizar esta lección podrá:

� Acceder dinámicamente a componentes de clase y componentes de objeto� Definir símbolos de campo� Definir referencias de datos� Anular referencias de datos� Generar dinámicamente objetos de datos

This lesson explains how to define field symbols and data references. In thislesson, highlight the difference between real data references and field symbols(dereferenced pointers).

Ejemplo empresarialEl Sr. Jiménez es un programador de software de una importante empresa quedesarrolla aplicaciones empresariales de propiedad en ABAP. Se le solicitaque desarrolle una aplicación flexible. El Sr. Jiménez busca una técnica deprogramación en ABAP comparable con los punteros en otros lenguajes deprogramación. Los símbolos de campo parecen una característica similar, por loque el Sr. Jiménez los utiliza para desarrollar su aplicación flexible.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 367

Page 382: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Símbolos de campoABAP lleva utilizando símbolos de campo como punteros de referencia anuladadurante algún tiempo. Los símbolos de campo permiten acceso �simbólico� a unobjeto de datos existente. Todos los accesos al símbolo de campo se realizan en elobjeto de datos asignado. Por tanto, sólo puede acceder al contenido del objeto dedatos al que señala el símbolo de campo. Esta técnica se denomina �semántica devalor de símbolos de campo�.

Gráfico 166: Símbolos de campo

Declare los símbolos de campo mediante la sentencia FIELD-SYMBOLS.

Atención: Tenga en cuenta que los paréntesis angulares (<>) en el nombrede símbolo de campo forman parte de la sintaxis.

Utilice la sentencia ASSIGN para asignar un objeto de datos al símbolo de campo.Si el símbolo de campo no tiene ningún tipo asignado (TYPE ANY), adopta eltipo de objeto de datos.

Mediante la especificación de un tipo para el símbolo de campo, puede garantizarque sólo se le asignen objetos compatibles.

Ejemplo:

DATA: date TYPE d VALUE ’20040101’, time TYPE t.

FIELD-SYMBOLS: <fs_date> TYPE d, <fs_time> TYPE t.

ASSIGN: date TO <fs_date>, time TO <fs_time>.

368 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 383: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

* possible?

<fs_time> = <fs_date>.

La última sentencia representa un error de sintaxis. De lo contrario, el uso de lasiguiente construcción desencadenaría un error de tiempo de ejecución:

FIELD-SYMBOLS: <fs_date> TYPE ANY, <fs_time> TYPE ANY.

Puede usar IS ASSIGNED para comprobar si se ha asignado un objeto de datosal símbolo de campo. La sentencia UNASSIGN fija el símbolo de campo en �noseñalar nada�. Por consiguiente, la expresión lógica IS ASSIGNED es falsadespués de esta sentencia.

If the participants are less than enthusiastic about this topic, point out thetremendous runtime savings that can result from using nested internal tables.

Gráfico 167: Casting de tipo para símbolos de campo

Si utiliza el suplemento CASTING cuando asigna un objeto de datos a un símbolode campo que tenga un tipo diferente, puede eliminar las restricciones del uso deltipo original del objeto de datos. El objeto de datos se interpreta como si tuviera eltipo de datos del símbolo de campo.

Si utiliza el suplemento CASTING TYPE cuando asigne un objeto de datos aun símbolo de campo que tenga un tipo diferente, puede acceder al objeto dedatos mediante el símbolo de campo como si el objeto tuviera ese tipo definidode manera explícita.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 369

Page 384: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

En el ejemplo anterior, observe que el campo de sistema sy-datum es uncomponente de tipo carácter elemental de longitud 8.

También puede utilizar el casting de tipo dinámicamente cuando asigne un objetode datos a un símbolo de campo.

Ejemplo de casting de tipo dinámico:

PARAMETERS tabname TYPE dd02l-tabname.

DATA: line(65535) TYPE c.

FIELD-SYMBOLS <fs_wa> TYPE ANY.

ASSIGN line TO <fs_wa> CASTING TYPE (tabname).

Ahora puede usar <fs_wa> para acceder a line como si este objeto de datosatómico tuviera el mismo tipo que el tipo de línea de la tabla transparentetransferida mediante tabname.

Nota: Este ejemplo sencillo sólo funcionará en sistemas Unicode sitabname define una estructura de tipo carácter.

Acceso a atributos con símbolos de campoLos símbolos de campo se pueden utilizar para acceder a atributos estáticosy atributos de instancia, asignando su contenido a los símbolos de campo. Acontinuación accederá al atributo en la sintaxis en vez de al objeto de datos.

Acceso a atributos con la sentencia ASSIGN

ASSIGN class=>static_attribute TO <fs>.

ASSIGN o_ref->instance_attribute TO <fs>.

Si el símbolo de campo <fs> tiene un tipo genérico, las características de tipoque falten se copiarán de los atributos durante la asignación.

Este acceso también puede realizarse dinámicamente:

Acceso dinámico a atributos con lasentencia ASSIGN

DATA:

classname TYPE seoclsname VALUE ’CLASS’,

attributname TYPE seocpdname VALUE ’ATTRIBUTE’.

370 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 385: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

ASSIGN (classname)=>(attributname) TO <fs>.

ASSIGN o_ref->(attributname) TO <fs>.

We recommend going through the first (optional) exercise at this point. It shouldprovide a simple example for participants who cannot appreciate the potentialof using field symbols.

Be sure to stress that this is an example, however. If we consider the task posed inthe exercise separately, two MOVE statements would also do the trick.

Referencias de datosLas referencias de datos y las referencias de objetos se han introducido en lossímbolos de campo como parte de las mejoras de SAP R/3 4.6A. A partir deentonces, ABAP ofrece una �semántica de referencia� completa.

Gráfico 168: Referencias de datos

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 371

Page 386: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Las variables de referencia de datos contienen referencias de datos o punteros queseñalan a los objetos de datos. Puede utilizar el suplemento TYPE REF TO parala sentencia TYPES con el fin de definir un tipo de referencia para un objeto dedatos. En esta sentencia puede especificar un tipo de datos explícito o utilizarTYPE REF TO data

para elegir la variante genérica. En este caso, su referencia dedatos puede señalar a cualquier tipo de objeto de datos.

Nota: El elemento sintácticodata

representa un identificador predefinido y escomparable con

spaceo

constructor.

La sentencia DATA correspondiente define la propia variable de referencia dedatos. Las variables de referencia son objetos de datos que pueden contener ladirección de cualquier objeto de datos (TYPE REF TO data) o un objeto dedatos del tipo especificado.

Las referencias de datos implican el uso de semántica de referencia, es decir,cuando se accede a una variable de referencia de datos, se direcciona la propiareferencia de datos, lo que significa que todas las modificaciones afectarán a lasdirecciones.

Las variables de referencia de datos se pueden gestionar en ABAP de la mismamanera que otros objetos de datos de tipo elemental. Esto significa que unavariable de referencia se puede definir no sólo como un campo individual sinotambién como la unidad indivisible más pequeña de objetos de datos complejoscomo estructuras o tablas internas.

Una vez definida, una variable de referencia de datos es inicial, es decir, contieneun puntero vacío. Para que una referencia de datos contenga una referencia queseñale a un objeto de datos, la sentencia GET REFERENCE OF debe recuperartambién una referencia a un objeto de datos ya definido.

También se puede asignar una referencia de datos existente en otra variable dereferencia de datos, o se puede crear un objeto de datos dinámicamente con lareferencia. (Más adelante, encontrará información adicional al respecto).

La referencia a las referencias de datos de tipo estático se puede anulardirectamente mediante el operador de dereferenciación

->*

372 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 387: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

. Esto significa que accederán directamente al contenido delobjeto de datos que señala a la referencia. Para garantizar la compatibilidad,debe anular las referencias de datos de tipo genérico (TYPE REF TO data) yasignarlas a un símbolo de campo que se pueda utilizar para acceder al contenido.(Este método se volverá a demostrar más adelante).

En consecuencia, la expresión data_reference->*podría compararse sin duda a la expresión

<field_symbol>.

Cuando hay implicadas referencias de datos de tipo estructurado estáticamente,se pueden direccionar los componentes directamente al objeto de datos referidomediante el selector de componentes

->y usarlos en cualquier elemento de operando.

Ejemplo:

DATA: wa TYPE sflight,

ref TYPE REF TO sflight.

GET REFERENCE OF wa INTO REF.

ref->fldate = ref->fldate + 5.

WRITE: / ref->seatsmax.

Por tanto, el selector de componente corresponde aquí al guión-

para el acceso de componente regular a objetos de datosestructurados.

Validez de referencias: expresión lógica

... ref IS [NOT] BOUND ...

La expresión ref IS [NOT] BOUND se usa para consultar si la variable dereferencia ref contiene una referencia válida. ref debe ser una variable dereferencia de objeto o de datos.

Cuando hay implicada una referencia de datos, esta expresión lógica es verdaderasi se puede anular la referencia. Cuando hay implicada una referencia de objeto,es verdadera si señala a un objeto. La expresión lógica es siempre falsa si refcontiene una referencia cero.

En cambio, la expresión lógica ... ref IS [NOT] INITIAL ... sólopermite saber si ref contiene una referencia cero o no.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 373

Page 388: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

In other programming languages, data references are used mainly in concatenatedlists. This is not the case in ABAP, because ABAP internal tables are extremelyeasy to handle. Therefore, if the participants are not enthusiastic, point out thetwo main areas of use within ABAP that now follow: dynamic method calls andinstantiation of data objects at runtime.

Instanciación dinámica y asignaciones de casting paraobjetos de datosPuede utilizar las referencias de datos y la sentencia CREATE DATA para generarobjetos de datos en tiempo de ejecución análogos a instancias de clase:

Instanciación de objetos de datos en tiempode ejecución

DATA ref TYPE REF TO typename.

CREATE DATA ref.

La referencia de datos ref señala entonces al objeto de datos creado. Comoalternativa a la variante estática, también puede determinar el tipo de datos entiempo de ejecución:

Asignación de tipo genérico a objetos dedatos en tiempo de ejecución

DATA ref TYPE REF TO data.

CREATE DATA ref TYPE typename.

La referencia ref debe tener el tipo genérico TYPE REF TO data. En lasiguiente variante dinámica, el nombre de tipo typename se puede especificartambién mediante una variable var_type:

Instanciación dinámica de objetos de datosen tiempo de ejecución

DATA ref TYPE REF TO data.

DATA var_type TYPE ... .

var_type = ... .

CREATE DATA ref TYPE (var_type).

374 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 389: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

If any of the participants still fail to show the necessary enthusiasm for this topic,you should now put special emphasis on the following options. If the participantsare still unsure of the advantages offered by dynamic instantiation, demonstratethe example program below to solve a specific problem.

Para acceder al contenido de un objeto de datos al que señala una referencia dedatos, la referencia al objeto se debe anular tal como se ha descrito anteriormente.Para garantizar la compatibilidad, sin embargo, se requiere un símbolo de campopara las referencias de datos de tipo genérico (TYPE REF TO data):

Gráfico 169: Anulación de referencias de datos de tipo genérico

La sentencia ASSIGN ref_itab->* TO <fs_itab> asigna el objeto dedatos especificado en la variable de referencia ref_itab al símbolo de campo<fs_itab>. Si la asignación es correcta, sy-subrc se fija en cero.

Si el símbolo de campo no es de tipo genérico por completo, adopta el tipo deobjeto de datos. Si al símbolo de campo se le ha asignado parcial o totalmente untipo, el sistema verifica la compatibilidad de los tipos de datos. También puedeasignar un casting al objeto de datos asignado.

Si la referencia de datos es inicial o no válida, no se puede anular. En este caso, elsímbolo de campo no se modifica y sy-subrc se fija en cuatro.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 375

Page 390: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

We highly recommend demonstrating the following program in the system(excerpt from executable program SAPBC402_DYND_DATADECL andSAPBC402_DYND_DATADECL_RTTI); ideally, you will develop it togetherwith the participants.

Generación de objetos de datos en tiempo deejecución: aplicación de ejemplo

REPORT ... .

DATA:

ref_itab TYPE REF TO data,

ref_wa TYPE REF TO data.

FIELD-SYMBOLS:

<fs_itab> TYPE ANY TABLE,

<fs_wa> TYPE ANY,

<fs_comp> TYPE ANY.

PARAMETERS pa_tab TYPE dd02l-tabname DEFAULT ’SPFLI’.

START-OF-SELECTION.

CREATE DATA ref_itab TYPE STANDARD TABLE OF (pa_tab)

WITH NON-UNIQUE DEFAULT KEY.

ASSIGN ref_itab->* TO <fs_itab>.

SELECT * FROM (pa_tab)

INTO TABLE <fs_itab>

UP TO 100 ROWS.

CREATE DATA ref_wa LIKE LINE OF <fs_itab>. "or: TYPE (pa_tab).

ASSIGN ref_wa->* TO <fs_wa>.

LOOP AT <fs_itab> INTO <fs_wa>.

DO.

ASSIGN COMPONENT sy-index OF STRUCTURE <fs_wa> TO <fs_comp>.

IF sy-subrc NE 0.

NEW-LINE.

EXIT.

ENDIF.

WRITE <fs_comp>.

ENDDO.

ENDLOOP.

376 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 391: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

El ejemplo puede mostrar el contenido de cualquier tabla transparente. Puedeutilizar la cláusula FROM de la sentencia SELECT dinámica.

Para la cláusula INTO, necesitará un objeto de datos que tenga un tipo de líneacompatible con el de la tabla que se va mostrar. Debido a que el nombre y, porlo tanto, el tipo de línea de la tabla no se conocen hasta el tiempo de ejecución,no se debe crear el objeto de datos hasta entonces. A diferencia de los objetosde datos convencionales, puede especificar el tipo de objeto de datos creadodinámicamente en tiempo de ejecución. El suplemento TYPE de la sentenciaCREATE DATA contiene el nombre de la tabla para garantizar que el sistemasiempre cree la estructura �apropiada�.

La sentencia ASSIGN ref_wa->* TO <fs_wa> asigna el objeto de datos alsímbolo de campo. El símbolo de campo hereda el tipo de datos de la tabla, porlo que ya no es necesario el casting de tipo. Ahora puede escribir cada registrode datos de la sentencia SELECT directamente en el objeto de datos de tipocompatible mediante el símbolo de campo <fs_wa>.

Si conoce los nombres de los componentes, podrá visualizar los camposdirectamente mediante WRITE <fs_wa>-.... En la mayoría de los casos, sinembargo, lo normal es no conocer los nombres ni la cantidad de componentes. Enconsecuencia, debe usar la variante ASSIGN-COMPONENT para la visualización:cada componente de la estructura <fs_wa> se asigna consecutivamente alsímbolo de campo <fs_comp> y posteriormente se visualiza. Si se agotan loscomponentes del loop, el programa solicita el siguiente registro de datos.

At this point, we recommend having the participants do the second exercise ofthis lesson. In addition, you might want to point out the capabilities of the SAPList Viewer (both the old version and the new one in Release 6.40 and later) fordynamic programming.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 377

Page 392: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Gráfico 170: Asignación de casting de referencias de datos

De manera análoga a las referencias de objeto, también se puede utilizar eloperador CAST para copiar referencias de datos a variables de referencia cuyotipo estático es idéntico al tipo dinámico de la referencia de fuente. Éste es el casoen el primer ejemplo, pero no en el segundo.

Nota: Si el operador de asignación de casting ?= no se ha utilizado, estasasignaciones no pasarían ni siquiera una verificación de sintaxis debido aque los tipos de fuente y de destino no son compatibles.

If necessary and/or requested, use program SAPBC402_DYND_DATACAST todemonstrate.

Si a una variable de referencia de datos se le asigna un tipo de forma estática, pasasus atributos de tipo al asignarse a una referencia de datos sin tipo. Este atributopuede ser muy útil, especialmente si hay implicada información adicional detipos de datos globales.

378 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 393: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

Gráfico 171: Transferencia de información de tipo global para referencias:teoría

Durante la anulación de referencia, el tipo de variable de referencia es crucial, noasí el tipo del objeto de datos al que �señala� la referencia. Esto se ilustra en elejemplo siguiente:

Gráfico 172: Transferencia de información de tipo global para referencias:ejemplo de sintaxis

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 379

Page 394: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

En el ejemplo anterior, a la variable de referencia REF_CITYTO se le asigna untipo estáticamente con el elemento de datos. En el tiempo de ejecución, recibe unareferencia al objeto de datos CITYFROM, que tiene un tipo diferente. Entonces lareferencia se anula mediante el símbolo de campo de tipo genérico <FS_GEN>y pasa a asumir los atributos de tipo de la referencia. En consecuencia, ladocumentación de campo para el elemento de datos se visualizará en forma delista, por ejemplo.

Consejo: Para obtener un resultado coherente, a la referenciaREF_CITYTO se le debería asignar un tipo genéricamente o de acuerdocon el objeto de datos CITYFROM.

Atención: Este ejemplo se ha diseñado específicamente para mostrar queel tipo de una variable de referencia de tipo estático es realmente decisivo.

If necessary and/or requested, use programSAPBC402_DYND_REF_GLOB_TYPE to demon-strate.

380 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 395: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

363 Ejercicio 22: Casting de tipo paraestructurasDuración del ejercicio: 30 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Utilizar símbolos de campo para casting de tipo� Desarrollar un programa sencillo para visualizar el contenido de la tabla

Ejemplo empresarialSe le ha pedido que desarrolle un programa sencillo para visualizar el contenidode la tabla. El usuario debe poder introducir el nombre de una tabla en la pantallade selección. El programa debe leer los datos de esta tabla y mostrarlos en unalista convencional.

Datos del sistemaSistema: Will be assignedMandante: Will be assignedID de usuario: Will be assignedClave de acceso: Will be assignedParametrizaciones del sistema: No special settings required in the standard SAPWeb AS 6.40 training system

Tarea:Desarrolle un programa sencillo que muestre el contenido de una tabla determinadaen una lista. Permita al usuario introducir el nombre de tabla en una imagen deselección.

Genere un objeto de datos estructurado con el tipo de nombre introducido. Desealeer los datos de su estructura desde la tabla de base de datos especificada. Utilicesímbolos de campo.

Tenga en cuenta que necesitará otro símbolo de campo para mostrar los datosen la lista en función del tipo ABAP.

1. Cree un programa con el nombre ZBC402_##_CREATE_DATA.

Como alternativa, puede copiar el programa de modeloSAPBC402_DYNT_CREATE_DATA.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 381

Page 396: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

2. Cree un objeto de datos estructurado en tiempo de ejecución cuyo tipode línea sea compatible con la tabla introducida por el usuario (nombrepropuesto: GR_STRUC).

3. Asigne un símbolo de campo de tipo correcto al objeto de datos generadoque le permita acceder a su contenido.

4. Programe la selección de datos. Lea los datos de la tabla transparenteespecificada en la estructura de un loop SELECT.

En este loop SELECT, muestre los datos en una lista convencional. Para ello,necesitará un segundo símbolo de campo al que asignar consecutivamentelos componentes de la estructura.

Consejo: Para simplificar, use el suplemento UP TO ... ROWSpara mantener los requisitos del programa en tiempo de ejecucióndentro de límites razonables. Siempre podrá encontrar una soluciónmás elegante para limitar la cantidad de datos más adelante.

382 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 397: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

Solución 22: Casting de tipo paraestructurasTarea:Desarrolle un programa sencillo que muestre el contenido de una tabla determinadaen una lista. Permita al usuario introducir el nombre de tabla en una imagen deselección.

Genere un objeto de datos estructurado con el tipo de nombre introducido. Desealeer los datos de su estructura desde la tabla de base de datos especificada. Utilicesímbolos de campo.

Tenga en cuenta que necesitará otro símbolo de campo para mostrar los datosen la lista en función del tipo ABAP.

1. Cree un programa con el nombre ZBC402_##_CREATE_DATA.

Como alternativa, puede copiar el programa de modeloSAPBC402_DYNT_CREATE_DATA.

a) Cree el programa en su paquete. Establezca los atributos para que elprograma se pueda ejecutar directamente.

Solución modelo: SAPBC402_DYNS_CREATE_DATA

2. Cree un objeto de datos estructurado en tiempo de ejecución cuyo tipode línea sea compatible con la tabla introducida por el usuario (nombrepropuesto: GR_STRUC).

a) Consulte el extracto de código fuente.

3. Asigne un símbolo de campo de tipo correcto al objeto de datos generadoque le permita acceder a su contenido.

a) Consulte el extracto de código fuente.

4. Programe la selección de datos. Lea los datos de la tabla transparenteespecificada en la estructura de un loop SELECT.

En este loop SELECT, muestre los datos en una lista convencional. Para ello,necesitará un segundo símbolo de campo al que asignar consecutivamentelos componentes de la estructura.

Consejo: Para simplificar, use el suplemento UP TO ... ROWSpara mantener los requisitos del programa en tiempo de ejecucióndentro de límites razonables. Siempre podrá encontrar una soluciónmás elegante para limitar la cantidad de datos más adelante.

a) Consulte el extracto de código fuente.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 383

Page 398: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Resultado

Extracto del código fuente:

*&---------------------------------------------------------------------*

*& Report SAPBC402_DYNS_CREATE_DATA

*&

*&---------------------------------------------------------------------*

*& This program works similar to the Data Browser.

*& Features:

*& Selection-Screen for a table name

*& Selects Data from the table provided

*& Output as classical list

*&---------------------------------------------------------------------*

REPORT sapbc402_dyns_create_data.

*----------------------------------------------------------------------*

DATA:

ok_code LIKE sy-ucomm,

ref_struc TYPE REF TO data.

*----------------------------------------------------------------------*

FIELD-SYMBOLS:

<fs_struc> TYPE ANY,

<fs_comp> TYPE ANY.

*----------------------------------------------------------------------*

PARAMETERS:

pa_tab TYPE dd02l-tabname DEFAULT ’SPFLI’.

*----------------------------------------------------------------------*

START-OF-SELECTION.

*----------------------------------------------------------------------*

CREATE DATA ref_struc TYPE (pa_tab).

ASSIGN ref_struc->* TO <fs_struc>.

SELECT * FROM (pa_tab)

INTO <fs_struc>

UP TO 100 ROWS

.

DO.

ASSIGN COMPONENT sy-index OF STRUCTURE <fs_struc> to <fs_comp>.

Continúa en la página siguiente

384 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 399: TAW12_01

TAW12_1 Lección: Programación dinámica con símbolos de campo y referencias

IF sy-subrc <> 0.

NEW-LINE.

EXIT.

ENDIF.

WRITE: <fs_comp>.

ENDDO.

ENDSELECT.

IF sy-subrc <> 0.

MESSAGE e041(bc402).

ENDIF.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 385

Page 400: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Resumen de la lección

Ahora podrá:� Acceder dinámicamente a componentes de clase y componentes de objeto� Definir símbolos de campo� Definir referencias de datos� Anular referencias de datos� Generar dinámicamente objetos de datos

386 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 401: TAW12_01

TAW12_1 Lección: Run Time Type Services

Lección:369

Run Time Type ServicesDuración de la lección: 50 Minutos

Resumen de la lecciónDesde SAP R/3 4.6C, las clases estándar de SAP en ABAP permiten consultar losatributos de tipo en tiempo de ejecución. Este concepto (RTTI = identificaciónde tipo en tiempo de ejecución) se ha ampliado en SAP NetWeaver 2004 con unaopción para crear objetos dinámicos en tiempo de ejecución (RTTC = creaciónde tipo en tiempo de ejecución). Combinados, estos dos conceptos forman losRTTS (Run Time Type Services).

Objetivos de la lecciónAl finalizar esta lección podrá:

� Consultar atributos de tipo en tiempo de ejecución� Crear tipos dinámicamente

ABAP is a programming language that contains both procedural andobject-oriented components. The procedural parts of ABAP have to be usedwithin classes � even within the object-oriented contexts.

However, certain concepts (for example, Runtime Type Identification, BusinessAdd-Ins, Control Framework) are only implemented as object-oriented concepts.Nevertheless, they can be used in both procedural and object-oriented concepts.

Ultimately, separating ABAP into its procedural and object-oriented parts does notmake any sense, and should not be propagated �artificially�.

You can use this lesson to illustrate these concepts again.

The concept of RTTS (RTTI & RTTC) will conclude the subject of dynamicprogramming by resolving all remaining issues.

Ejemplo empresarialEl Sr. Jiménez es un programador de software de una importante empresa quedesarrolla aplicaciones empresariales de propiedad en ABAP. Se le ha pedido quedesarrolle una nueva aplicación flexible. Sabe que ABAP ofrece varias opcionesde programación. Una nueva función permite la creación de tipos de datos entiempo de ejecución. El Sr. Jiménez utilizará estas nuevas opciones y desarrollaráuna aplicación flexible.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 387

Page 402: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Identificación de tipo en tiempo de ejecución (RTTI)La implementación de objetos ABAP introdujo un concepto basado en clasellamado Run Time Type Identification (RTTI), y que se puede usar para determinaratributos de tipo en tiempo de ejecución. Este concepto incluye todos los tiposABAP y, en consecuencia, abarca todas las funciones de las sentencias que ahoraestán obsoletas: DESCRIBE FIELD y DESCRIBE TABLE.

Hay una clase de descripción para cada tipo con atributos especiales para atributosde tipo especiales:

Gráfico 173:

La jerarquía de las clases de descripción corresponde a la jerarquía de los tipos enABAP. Además, las clases de descripción para tipos complejos, referencias, clasese interfases tienen métodos especiales que se utilizan para especificar referenciasa subtipos. Es posible utilizar estos métodos para navegar a través de un tipocompuesto a todos sus subtipos.

Para obtener una referencia de un objeto de descripción de un tipo, debe utilizarlos métodos estáticos de la clase CL_ABAP_TYPEDESCR o los métodos denavegación de la clase de descripción especial. Los objetos de descripción secrean a partir de una de las subclases. En tiempo de ejecución, existe sólo unobjeto de descripción para cada tipo. Los atributos del objeto de descripcióncontienen información acerca de los atributos del tipo.

388 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 403: TAW12_01

TAW12_1 Lección: Run Time Type Services

Gráfico 174:

Análisis de tipo de datos dinámicoEn el siguiente ejemplo de aplicación, los atributos de una estructurase deben identificar utilizando RTTI. Para ello, utilizaremos la subclaseCL_ABAP_STRUCTDESCR.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 389

Page 404: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Gráfico 175:

Dado que necesitamos los atributos de una estructura, definimos primero unareferencia a la clase de descripción apropiada. Las instancias de esta clase tienenun atributo COMPONENTS que usted utiliza para describir los componentesindividuales de la estructura relevante. Este atributo es una tabla interna. Por ello,también es necesario definir un área de trabajo con un tipo de línea compatible.

El método funcional devuelve la referencia a la instancia de descripción de laestructura transferida. (La estructura gs se podría haber generado dinámicamente;en este ejemplo, es como siempre estática).

Sólo la clase abstracta CL_ABAP_TYPEDESCR contiene el métodoDESCRIBE_BY_DATA. Su parámetro de retorno se introduce como una referenciaa esta clase superior. No obstante, puesto que el parámetro actual REF_DESCRtiene el tipo de la subclase CL_ABAP_STRUCTDESCR, se necesita una asignacióndowncast (descendente).

A continuación, se podrá acceder a los atributos de la instancia de descripción decualquier forma. En este ejemplo, los nombres de componente se visualizan comocabeceras. (Para mayor claridad, hemos omitido las opciones de formato).

Demo: SAPDNW7AW_RTTI_ELEMENTARY_D1 (for elementarydata objects) and SAPDNW7AW_RTTI_STRUCTURE_D1 orSAPDNW7AW_RTTI_STRUCTURE_D2 (for structures).

390 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 405: TAW12_01

TAW12_1 Lección: Run Time Type Services

Análisis de tipo de objeto dinámicoRTTI permite también analizar los atributos de los objetos. Para tal fin,están disponibles la clase CL_ABAP_OBJECTDESCR y sus dos subclases,CL_ABAP_CLASSDESCR y CL_ABAP_INTFDESCR.

En el ejemplo siguiente, vamos a analizar los atributos de un objeto. La variablede referencia SENDER se transfiere al método DESCRIBE_BY_OBJ_REF.

Nota: Para obtener información sobre una definición de clase, llame elmétodo DESCRIBE_BY_NAME y transfiera el nombre de clase.

Gráfico 176:

Después de llamar el método, la variable de referencia go_descr contiene unareferencia a un objeto de descripción que, a su vez, contiene información sobreel objeto de go_vehicle. Entre otros datos, el objeto de descripción indica eltipo (de objeto) de go_vehicle. Si el objeto go_vehicle tiene el tipo de la claseLCL_TRUCK, puede realizar una asignación segura mediante ?=.

Consejo: Sólo la clase abstracta CL_ABAP_TYPEDESCR tiene elmétodo DESCRIBE_BY_OBJECT_REF. A su parámetro de retornose le asigna el tipo como referencia a su clase superior. No obstante,puesto que el parámetro actual go_descr tiene el tipo de la subclaseCL_ABAP_CLASSDESCR, se necesita una asignación downcast.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 391

Page 406: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

We have not constructed an object model as part of this course. For thisreason, it makes no sense to use RTTI to determine the object types andother object attributes. As a result, an effective demonstration of the methodDESCRIBE_BY_OBJECT_REF is not possible.

The demonstration program SAPDNW7AW_DYNAMIC_RTTI_OBJECT_D1illustrates the object type analysis for a class entered in the selection screen.Discuss this program.

Run Time Type Creation (RTTC)En SAP NetWeaver 2004, las clases de tipo RTTI se ampliaron con RTTC a finde que se pudieran crear tipos en tiempo de ejecución. Mientras que la sentenciaCREATE DATA crea un tipo implícitamente, RTTC permite además crear tiposnuevos explícitamente en tiempo de ejecución.

En el proceso, los atributos de los tipos se implementan a través de los atributos deobjeto de tipo. Esto significa que cada tipo tiene un objeto tipo, cuyos atributosdescriben las propiedades del tipo.

Gráfico 177:

392 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 407: TAW12_01

TAW12_1 Lección: Run Time Type Services

La jerarquía de clases de tipo corresponde a la jerarquía de los tipos en el sistemade tipo ABAP. Los objetos de tipo pueden crearse mediante los métodos de clasede tipo. Puede utilizar los métodos estáticos de la clase CL_ABAP_TYPEDESCRo llamar métodos de las clases de tipo específico (GET_I, GET_C, ..., CREATE)para obtener referencias a objetos de tipo.

Gráfico 178:

RTTC permite crear tipos de datos elementales y complejos (como estructuras ytablas internas) en tiempo de ejecución. Esto puede demostrarse utilizando unatabla interna.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 393

Page 408: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Gráfico 179:

Con el método CREATE, la clase CL_ABAP_TABLEDESCR permite crear untipo de tabla en tiempo de ejecución. Un parámetro formal importante de estemétodo estático es P_LINE_TYPE, que describe el tipo de línea a través de unareferencia a la clase CL_ABAP_TYPEDESCR. En el ejemplo ofrecido aquí,SPFLI se utiliza como el tipo de línea. El método DESCRIBE_BY_NAME sirvede instancia a un objeto adecuado para el mismo.

Ahora la cuestión es: ¿qué puede hacer el programa con el tipo de tabla que acabade crear? Por ejemplo, se puede utilizar como ejemplo de creación de una tablainterna en tiempo de ejecución:

Generación de una tabla interna con un tipocreado dinámicamente

...DATA r_itab TYPE REF TO data,

r_tableType TYPE REF TO cl_abap_tabledescr.

...

* Creation of internal tabletype with static method

* CREATE of RTTS-class cl_abap_tabledescr

...

CREATE DATA r_itab TYPE HANDLE r_tabletype.

394 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 409: TAW12_01

TAW12_1 Lección: Run Time Type Services

Mediante el suplemento HANDLE, la sentencia CREATE DATA en el ejemplocrea una tabla interna cuyo tipo se ha descrito mediante un objeto de tipo RTTS.Para el HANDLE se especifica una variable de referencia del tipo estático dela clase CL_ABAP_TABLEDESCR, que hace referencia a un objeto de tipo.Este objeto de tipo puede haberse creado mediante la aplicación de los métodosRTTS a los objetos de datos existentes o a través de una definición dinámica deun nuevo tipo de datos.

Since this topic is complex and some people who are new to the subject matterusually find it overwhelming, make sure that you also refer to the correspondingrelevant areas relating to RTTI and RTTC in the documentation so that theparticipants know that they can always refer to it themselves at a later stage. Infact, it might be best to point out the documentation in advance.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 395

Page 410: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

396 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 411: TAW12_01

TAW12_1 Lección: Run Time Type Services

379 Ejercicio 23: RTTI: consulta de losatributos de un tipo de datosDuración del ejercicio: 40 Minutos

Objetivos de los ejerciciosAl finalizar este ejercicio podrá:� Utilizar RTTI para consultar los atributos de un tipo de datos en tiempo

de ejecución

Ejemplo empresarialDesea utilizar las opciones que ofrece Run Time Type Identification para laprogramación flexible.

Tarea 1:Crear un programa y llamar un módulo de funciones

1. Cree un nuevo programa ejecutable (report) y llámelo ZDNW7AW_RTTI_##.(## indica el número de grupo de dos dígitos).

2. Llame el módulo de funciones DNW7AW_RETURN_RAN-DOM_DATA_REF. Este módulo de funciones devuelve referencias a objetosde datos anónimos de tipo aleatorio.

En principio, para objetos de datos anónimos son posibles los tipos siguientescon este módulo de funciones:

Tipos de datos atómicos (por ejemplo, campos numéricos o strings decaracteres) si el parámetro import IV_SIMPLE_TYPES = �X�.

Tipos de estructura plana si el parámetro import IV_STRUCTURED_TYPES= �X�.

Tipos de tabla interna si el parámetro import IV_TABLE_TYPES = �X�.

En esta tarea, actualice los parámetros llamados, de modo que devuelvan deforma definitiva una referencia a un objeto de datos atómico.

3. Cree una variable de referencia de tipo adecuado llamada gr_data ytransfiérala al módulo de funciones.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 397

Page 412: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Tarea 2:Examine la referencia de datos en el caso de un objeto de datos atómico

1. Llame el método estático DESCRIBE_BY_DATA_REF de la claseCL_ABAP_TYPEDESCR para su referencia de datos gr_data. Grabe elresultado en una referencia de objeto llamada go_type que debe crear conreferencia a la clase CL_ABAP_TYPEDESCR.

2. Use un método adecuado de la referencia de objeto go_type para buscar elnombre relativo del tipo y visualizarlo con el comando WRITE.

3. Compare el atributo type_kind de la referencia de objeto go_type conconstantes adecuadas de la clase CL_ABAP_TYPEDESCR a fin dedeterminar si el objeto de datos anónimo es un string de caracteres, un campode fecha o un número empaquetado. (Puede ignorar las demás opciones detipo de datos atómico). Visualice el resultado con el comando WRITE.

4. Para acceder a los atributos especiales del tipo de datos atómico, necesitauna variable con el tipo de la clase CL_ABAP_ELEMDESCR. Cree estavariable y llámela go_elem_type. Programe una asignación downcastdesde la referencia de clase superior go_type a la referencia de subclasego_elem_type. A continuación, evalúe el atributo output_length y visualiceel resultado con el comando WRITE.

5. Active y ejecute el programa.

Tarea 3:Opcional: Examine la referencia de datos en el caso de un objeto de datosestructurado.

1. A continuación cambie la llamada de módulo de funcionesDNW7AW_RETURN_RANDOM_DATA_REF, de modo que el objeto dedatos anónimo creado por el generador de números aleatorios pueda ser tantoatómico como estructurado. Active los parámetros IV_SIMPLE_TYPES yIV_STRUCTURED_TYPES con �X�. En consecuencia, en la evaluacióndebe consultar si se ha devuelto una referencia a un objeto de datos atómicoo una referencia a una estructura. Para ello, compare el atributo clase dela variable go_type en una sentencia CASE con constantes relevantes dela clase CL_ABAP_TYPEDESCR.

Si la referencia de datos gr_data señala a un objeto de datos elemental, sedebería visualizar este hecho. Además, se debería ejecutar el código dela sentencia anterior.

En cambio, si la referencia de datos señala a una estructura, sedebería visualizar con el comando WRITE junto con el número decampos en la estructura. Busque un método adecuado en la clase

Continúa en la página siguiente

398 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 413: TAW12_01

TAW12_1 Lección: Run Time Type Services

CL_ABAP_STRUCTDESCR que devuelva los nombres de campo (yasí, indirectamente, su cantidad). Plantéese usar de nuevo la asignacióndowncast para llamar este método.

2. Active y ejecute el programa.

Tarea 4:Opcional: Examine la referencia de datos si el objeto de datos es un tipo de tablainterna.

1. A continuación, cambie la llamada de módulo de funcionesDNW7AW_RETURN_RANDOM_DATA_REF, de modo que el objeto dedatos anónimo creado por el generador de números aleatorios pueda seratómico, estructurado o una tabla interna. Para ello, active los parámetrosIV_SIMPLE_TYPES, IV_STRUCTURED_TYPES y IV_TABLE_TYPEScon �X�. En consecuencia, debe ampliar la evaluación CASE. Para ello,compare el atributo clase de la variable go_type en una sentencia CASE conconstantes relevantes de la clase CL_ABAP_TYPEDESCR.

Si el objeto es ahora una tabla interna, este hecho se debería visualizar con elcomando WRITE, junto con el tipo de tabla. Busque un atributo adecuado enla clase CL_ABAP_TABLEDESCR. Plantéese usar de nuevo la asignacióndowncast para acceder a este atributo.

2. Active y ejecute el programa.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 399

Page 414: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Solución 23: RTTI: consulta de losatributos de un tipo de datosTarea 1:Crear un programa y llamar un módulo de funciones

1. Cree un nuevo programa ejecutable (report) y llámelo ZDNW7AW_RTTI_##.(## indica el número de grupo de dos dígitos).

a) Proceda de la manera habitual.

2. Llame el módulo de funciones DNW7AW_RETURN_RAN-DOM_DATA_REF. Este módulo de funciones devuelve referencias a objetosde datos anónimos de tipo aleatorio.

En principio, para objetos de datos anónimos son posibles los tipos siguientescon este módulo de funciones:

Tipos de datos atómicos (por ejemplo, campos numéricos o strings decaracteres) si el parámetro import IV_SIMPLE_TYPES = �X�.

Tipos de estructura plana si el parámetro import IV_STRUCTURED_TYPES= �X�.

Tipos de tabla interna si el parámetro import IV_TABLE_TYPES = �X�.

En esta tarea, actualice los parámetros llamados, de modo que devuelvan deforma definitiva una referencia a un objeto de datos atómico.

a) Consulte la solución modelo.

3. Cree una variable de referencia de tipo adecuado llamada gr_data ytransfiérala al módulo de funciones.

a) Consulte la solución modelo.

Tarea 2:Examine la referencia de datos en el caso de un objeto de datos atómico

1. Llame el método estático DESCRIBE_BY_DATA_REF de la claseCL_ABAP_TYPEDESCR para su referencia de datos gr_data. Grabe elresultado en una referencia de objeto llamada go_type que debe crear conreferencia a la clase CL_ABAP_TYPEDESCR.

a) Consulte la solución modelo.

2. Use un método adecuado de la referencia de objeto go_type para buscar elnombre relativo del tipo y visualizarlo con el comando WRITE.

a) Consulte la solución modelo.

Continúa en la página siguiente

400 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 415: TAW12_01

TAW12_1 Lección: Run Time Type Services

3. Compare el atributo type_kind de la referencia de objeto go_type conconstantes adecuadas de la clase CL_ABAP_TYPEDESCR a fin dedeterminar si el objeto de datos anónimo es un string de caracteres, un campode fecha o un número empaquetado. (Puede ignorar las demás opciones detipo de datos atómico). Visualice el resultado con el comando WRITE.

a) Consulte la solución modelo.

4. Para acceder a los atributos especiales del tipo de datos atómico, necesitauna variable con el tipo de la clase CL_ABAP_ELEMDESCR. Cree estavariable y llámela go_elem_type. Programe una asignación downcastdesde la referencia de clase superior go_type a la referencia de subclasego_elem_type. A continuación, evalúe el atributo output_length y visualiceel resultado con el comando WRITE.

5. Active y ejecute el programa.

a) Seleccione Ctrl + F3 y F8.

Tarea 3:Opcional: Examine la referencia de datos en el caso de un objeto de datosestructurado.

1. A continuación cambie la llamada de módulo de funcionesDNW7AW_RETURN_RANDOM_DATA_REF, de modo que el objeto dedatos anónimo creado por el generador de números aleatorios pueda ser tantoatómico como estructurado. Active los parámetros IV_SIMPLE_TYPES yIV_STRUCTURED_TYPES con �X�. En consecuencia, en la evaluacióndebe consultar si se ha devuelto una referencia a un objeto de datos atómicoo una referencia a una estructura. Para ello, compare el atributo clase dela variable go_type en una sentencia CASE con constantes relevantes dela clase CL_ABAP_TYPEDESCR.

Si la referencia de datos gr_data señala a un objeto de datos elemental, sedebería visualizar este hecho. Además, se debería ejecutar el código dela sentencia anterior.

En cambio, si la referencia de datos señala a una estructura, sedebería visualizar con el comando WRITE junto con el número decampos en la estructura. Busque un método adecuado en la claseCL_ABAP_STRUCTDESCR que devuelva los nombres de campo (yasí, indirectamente, su cantidad). Plantéese usar de nuevo la asignacióndowncast para llamar este método.

a) Consulte la solución modelo.

2. Active y ejecute el programa.

a) Seleccione Ctrl + F3 y FL.

Continúa en la página siguiente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 401

Page 416: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Tarea 4:Opcional: Examine la referencia de datos si el objeto de datos es un tipo de tablainterna.

1. A continuación, cambie la llamada de módulo de funcionesDNW7AW_RETURN_RANDOM_DATA_REF, de modo que el objeto dedatos anónimo creado por el generador de números aleatorios pueda seratómico, estructurado o una tabla interna. Para ello, active los parámetrosIV_SIMPLE_TYPES, IV_STRUCTURED_TYPES y IV_TABLE_TYPEScon �X�. En consecuencia, debe ampliar la evaluación CASE. Para ello,compare el atributo clase de la variable go_type en una sentencia CASE conconstantes relevantes de la clase CL_ABAP_TYPEDESCR.

Si el objeto es ahora una tabla interna, este hecho se debería visualizar con elcomando WRITE, junto con el tipo de tabla. Busque un atributo adecuado enla clase CL_ABAP_TABLEDESCR. Plantéese usar de nuevo la asignacióndowncast para acceder a este atributo.

2. Active y ejecute el programa.

a) Seleccione Ctrl + F3 y F8.

Resultado

SAPDNW7AW_RTTI_S1

REPORT sapdnw7aw_rtti_s1.

DATA:

gr_data TYPE REF TO data,

go_type TYPE REF TO cl_abap_typedescr,

go_elem_type TYPE REF TO cl_abap_elemdescr,

go_struc_type TYPE REF TO cl_abap_structdescr,

go_table_type TYPE REF TO cl_abap_tabledescr,

gt_components TYPE abap_component_tab,

gv_name TYPE string,

gv_output_length TYPE i,

gv_lines TYPE sy-tabix.

TRY.

CALL FUNCTION ’DNW7AW_RETURN_RANDOM_DATA_REF’

EXPORTING

iv_simple_types = ’X’

iv_structured_types = ’X’

iv_table_types = ’X’

IMPORTING

pr_data = gr_data.

Continúa en la página siguiente

402 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 417: TAW12_01

TAW12_1 Lección: Run Time Type Services

IF gr_data IS NOT INITIAL.

CALL METHOD cl_abap_typedescr=>describe_by_data_ref

EXPORTING

p_data_ref = gr_data

RECEIVING

p_descr_ref = go_type.

gv_name = go_type->get_relative_name( ).

WRITE: / gv_name.

CASE go_type->kind.

WHEN cl_abap_typedescr=>kind_elem.

WRITE: / ’It is an elementary type’(ele).

go_elem_type ?= go_type.

gv_output_length = go_elem_type->output_length.

WRITE: / ’The output length:’(out), gv_output_length.

CASE go_type->type_kind.

WHEN cl_abap_typedescr=>typekind_char.

WRITE: / ’It is a character type’(cha).

WHEN cl_abap_typedescr=>typekind_packed.

WRITE: / ’It is a packed type’(pac).

WHEN cl_abap_typedescr=>typekind_date.

WRITE: / ’It is a date type’(dat).

ENDCASE.

WHEN cl_abap_typedescr=>kind_struct.

WRITE: / ’It is a structured type’(str).

go_struc_type ?= go_type.

gt_components = go_struc_type->get_components( ).

gv_lines = LINES( gt_components ).

WRITE: / ’The number of fields:’(fie), gv_lines.

WHEN cl_abap_typedescr=>kind_table.

WRITE: / ’It is a table type’(tab).

go_table_type ?= go_type.

CASE go_table_type->table_kind.

WHEN cl_abap_tabledescr=>tablekind_hashed.

WRITE: / ’It is a hashed table’(has).

WHEN cl_abap_tabledescr=>tablekind_sorted.

WRITE: / ’It is a sorted table’(sor).

WHEN cl_abap_tabledescr=>tablekind_std.

WRITE: / ’It is a standard table’(std).

ENDCASE.

ENDCASE.

ENDIF.

CATCH cx_dnw7aw_no_data.

ENDTRY.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 403

Page 418: TAW12_01

Capítulo 6: Programación dinámica TAW12_1

Resumen de la lección

Ahora podrá:� Consultar atributos de tipo en tiempo de ejecución� Crear tipos dinámicamente

404 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 419: TAW12_01

TAW12_1 Resumen del capítulo

Resumen del capítuloAhora podrá:� Acceder dinámicamente a componentes de clase y componentes de objeto� Definir símbolos de campo� Definir referencias de datos� Anular referencias de datos� Generar dinámicamente objetos de datos� Consultar atributos de tipo en tiempo de ejecución� Crear tipos dinámicamente

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 405

Page 420: TAW12_01

Resumen del capítulo TAW12_1

406 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 421: TAW12_01

TAW12_1 Examine sus conocimientos

389Examine sus conocimientos

1. ¿Cuáles de las siguientes afirmaciones sobre programación dinámica soncorrectas?Seleccione la(s) respuesta(s) correcta(s).□ A Los símbolos de campo contienen las direcciones de objetos de

datos en tiempo de ejecución.□ B Cuando modifica el contenido de un símbolo de campo, se

modifica la dirección del objeto de datos asignado.□ C Cuando modifica el contenido de un símbolo de campo, se

modifica una dirección. Es decir, el símbolo de campo ya no hacereferencia al objeto de datos.

□ D Puede usar símbolos de campo para acceder a los objetos de datoscomo si tuvieran un tipo distinto al tipo estático.

□ E No existen referencias de datos en ABAP; los símbolos de camposon simples punteros de referencia anulada.

□ F Cuando modifica el contenido de una referencia de datosasignada, se modifica una dirección. Es decir, la referencia yano señala al objeto de datos.

□ G En ABAP, puede definir el tipo de un objeto cuando defina lareferencia o esperar hasta que se genere en tiempo de ejecución.

□ H En ABAP, puede definir el tipo de un objeto cuando lo defina oesperar a que se genere en tiempo de ejecución.

□ I Una referencia de datos de tipo global señala a un objeto de datosal que ya se le ha asignado un tipo global diferente. Además, seha utilizado un símbolo de campo de tipo genérico para anular lareferencia de datos. Si esta referencia de campo se utiliza paraacceder al objeto de datos, se aplicarán los atributos de tipo delobjeto de datos y no los de la referencia de datos.

□ J Si a una variable de referencia de datos se le asigna un tipoestático, pasa sus atributos de tipo al asignarse a una referenciade datos sin tipo.

□ K Puede utilizar clases RTTI en ABAP para determinar todas laspropiedades de un objeto (de datos) en tiempo de ejecución.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 407

Page 422: TAW12_01

Examine sus conocimientos TAW12_1

390Respuestas

1. ¿Cuáles de las siguientes afirmaciones sobre programación dinámica soncorrectas?

Respuesta: A, D, F, G, H, J, K

Feedback

408 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 423: TAW12_01

TAW12_1 Resumen del curso

Resumen del cursoAhora podrá:

� Utilizar elementos fundamentales de la modelación orientada a objetos enUML

� Crear programas de objetos ABAP que contengan todas las técnicas deprogramación útiles orientadas a objetos

� Utilizar las herramientas relevantes para crear objetos de Repositoryorientados a objetos

� Describir y aprovechar el rango de aplicaciones de objetos ABAP� Definir, emitir y tratar excepciones basadas en clases� Consultar atributos de tipo y de clase en el tiempo de ejecución� Realizar modificaciones especializadas en la versión estándar del sistema

SAP� Evaluar los distintos métodos de modificación y elegir el adecuado en cada

caso� Explicar la arquitectura de un componente Web Dynpro� Describir las partes de un controlador Web Dynpro� Crear elementos de contexto en controladores Web Dynpro� Explicar cómo se puede implementar la navegación y las transferencias de

datos en componentes Web Dynpro y entre ellos� Definir la interfase de usuario de un componente Web Dynpro� Internacionalizar una aplicación Web Dynpro� Definir y enviar mensajes en un componente Web Dynpro� Definir la ayuda para entradas y la ayuda semántica para elementos de UI en

un componente Web Dynpro

Más información

� Use un URL o una etiqueta de referencia cruzada para destacar informaciónadicional que pueda resultar útil a los participantes, como sitios Web o WhitePapers. Bórrelos si son irrelevantes.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 409

Page 424: TAW12_01

Resumen del curso TAW12_1

410 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 425: TAW12_01

ÍndiceNúmeros/Símbolos?=, 378->*, 372, 375Aabstracción, 20ACTIVACIÓN, 198agregación, 27, 55anulación, 372, 375, 380anulación de referencia, 378área, 338área de nombresclase, 47

asignaciónde excepción, 314, 316

Asistente de refactoring, 248asociación, 24binaria y recursiva, 24

ASSIGN, 368, 375CASTING, 369CASTING TYPE, 369

atributo, 39estático, 43KERNEL_ERRID, 302PREVIOUS, 314privado, 41público, 41

atributo de clase, 43atributo de instancia, 43atributo estático, 43autoreferencia, 65Ccadena de excepciones, 300,314

CALL METHOD, 57�58EXCEPTIONS, 45EXPORTING, 45IMPORTING, 45

cardinalidad, 24cesta de la compra, 334clase, 18abstracta, 272amistad, 276CL_ABAP_CLASSDE-SCR, 391CL_ABAP_STRUCTDE-SCR, 390CL_ABAP_TYPE-DESCR, 388, 390final, 273instanciación, 274parte de definición, 38

CLASEABSTRACTA, 272AMIGOS, 276CREAR, 274FINAL, 273INHERITING FROM,108SECCIÓN PRIVADA, 42SECCIÓN PÚBLICA, 42

clase de excepción, 301clase superior, 314CX_DY-NAMIC_CHECK,301, 314CX_NO_CHECK, 301,314CX_ROOT, 301�302, 314CX_STATIC_CHECK,301, 314CX_SY_ARITH-METIC_ERROR, 305CX_SY_ARITH-METIC_OVERFLOW,304

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 411

Page 426: TAW12_01

Índice TAW12_1

CX_SY_MOVE_CAST_ER-ROR, 124, 161CX_SY_ZERODIVIDE,302global, 301jerarquía de herencia, 314local, 301

clase de mensaje, 307clase de raíz de área, 341clase globalimprimir, 239test, 241

clase singleton, 277clase superior, 106clases, 275clases de área, 338clasificaciónde objeto, 18

CLASS, 233CLASS EVENTS, 195CLASS_CONSTRUCTOR,64

CLASS-METHODS, 48comportamientode objeto, 22

composición, 27concepto de amigo, 276constructor, 62, 111estático, 64

CONSTRUCTOR, 62constructor de instancia, 62,111sección de visibilidad, 274

constructor estático, 64control de eventos, 14Creación de tipo en tiempo deejecución, 392

CREATE DATA, 374TYPE, 374

CREATE OBJECT, 51CHCHANGING, 45DDATA

TYPE REF TO, 51, 372,378TYPE REF TO data, 372

DEFAULT, 45definiciónde método, 45

Definiciónde clase, 38

DEFINICIÓN, 38Definición deCLASE, 38

delegación, 30DESCRIBE FIELD, 388DESCRIBE TABLE, 388destructor, 62diagrama de clases, 23diagrama de objetos, 29diagrama de secuencias, 29down cast, 123Down cast, 160downcast, 123, 305Eencapsulación, 7, 41enlace de objetos, 24error en tiempo de ejecuciónBCD_ZERODIVIDE, 302interceptable, 301

especialización, 28, 106eventoestático, 192

evento de instancia, 192EVENTS, 195excepciónbasada en clase, 299de tabla, 298propagar, 303, 309

FFIELD-SYMBOLS, 368Firma, 45GGenerador de clasesparametrizaciones devisualización, 245

412 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 427: TAW12_01

TAW12_1 Índice

tratamiento decomponentes de clase,239

generalización, 28, 106grupo de funcionesgestión de datos, 7

Hherencia, 14herencia múltiple, 108IID de texto, 311identidadde objeto, 19

Identificación de tipo entiempo de ejecución, 388

Inscripción, 197, 199instancia, 19instancia de área, 338instancia de excepción, 300instanciaciónclase, 50tipo de datos, 374

instanciación múltiple, 11interfaceclase, 41compuesto, 163método, 45

INTERFACE, 153interface compuesto, 163interface de componente, 163INTERFACES, 153IS ASSIGNED, 369IS BOUND, 373IS INITIAL, 53, 373LLllamadade método, 58

MME, 65memoria compartida, 334MESSAGE, 305métodoabstracto, 273

DESCRIBE_BY_DATA,390estático, 48, 273final, 273firma, 45funcional, 59GET_SOURCE_POSI-TION, 302GET_TEXT, 302, 304,309, 311llamada, 57parámetro, 45privado, 47público, 47redefinición, 109

método de clase, 48método de instancia, 48método de programa decontrol de eventos, 193

método estático, 48MÉTODOS, 48ABSTRACTOS, 273FINALES, 273FOR EVENT, 196

modelo de programaciónorientado a objetos, 11proceso, 5

MOVE, 52, 160operador de asignacióndown cast, 122?TO, 378

multiplicidad, 24Nnombre alias, 153�154, 164OObject Management Group(OMG), 21

objetos compartidos, 334OMG, 21Online Text Repository, 307operador de asignación decasting, 378

Operador de asignación downcast, 160

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 413

Page 428: TAW12_01

Índice TAW12_1

operador de asignaciónnarrowing cast, 122

operador de dereferenciación,372, 375, 378

operador de resolución deinterface, 153�154

OPTIONAL, 45OTR, 309Ppaquete, 22parte de definición, 38patrón de diseño de rol, 126polimorfismo, 14, 120Polimorfismo, 158principio de delegación, 13PROTECTED SECTION, 112punterode referencia anulada, 368

RRAISE EVENT, 196RAISING, 310Recolector de basura, 53redefinición, 109referenciaindependiente, 53validez, 373

referencia cero, 51, 373referencia de datos, 372relación de amistad, 276herencia, 277

RETURNING, 45rol, 24RTTC, 392RTTI, 388RTTS, 387Ssección de visibilidadprotegida, 112

SECCIÓN PRIVADA, 42SECCIÓN PÚBLICA, 42semántica de referencia, 372semántica de valor, 368SENDER, 196SET HANDLER, 198

ACTIVATION, 198FOR ALL INSTANCES,198

SHMA, 338SHMM, 348símbolo de campo, 368singletonsin instanciación múltiple,275

SÓLO DE LECTURA, 40, 42statusde objeto, 19, 22

subclase, 106SUPER, 109supresión de información, 41Ttabla de programa de control,199

TABLE_LINE, 54textos de excepción, 302tipodinámico, 117estático, 117

tipos de referencia, 378tratamiento de excepciones,300CATCH, 302�303CLEANUP, 304, 311TRY, ENDTRY, 302�303verificación de sintaxis,314verificación estática, 314

TYPE REF TO, 51TYPE REF TO data, 372TYPESTYPE REF TO, 372, 378TYPE REF TO data, 372

UUML, 21UNASSIGN, 369Unified Modeling Language,21

up cast, 116Up cast, 156

414 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 429: TAW12_01

TAW12_1 Índice

Vvariable de referencia, 51, 372tipo de datos, 378

variable de referencia dedatos, 372

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 415

Page 430: TAW12_01

Índice TAW12_1

416 © 2009 SAP AG. Reservados todos los derechos. 10-07-2009

Page 431: TAW12_01

FeedbackSAP AG ha tomado todas las medidas posibles en la preparación de este curso paraasegurar la exactitud de los contenidos del mismo así como que esté completo. Sitiene algunas correcciones o sugerencias para mejorarlo, anótelas en los espaciosprevistos para este fin en la evaluación del curso.

10-07-2009 © 2009 SAP AG. Reservados todos los derechos. 417