ABAP OBJECTSQuarta parte

2

Agenda del corso

• Dai function module agli oggetti• Definizione di una classe• Oggetti e metodi• Incapsulamento, ereditarietà,

polimorfismo• Interfacce• Eventi

3

Agenda del corso

• Dai function module agli oggetti• Definizione di una classe• Oggetti e metodi• Incapsulamento, ereditarietà,

polimorfismo• Interfacce• Eventi

Interfacce

• L’ABAP come il Java non permette l’ereditarietà multipla

• Con l’utilizzo delle interfacce è possibile in parte aggirare questo limite

4

Interfacce

• Le interfacce sono simili alle classi astratte ma hanno solo la parte della definizione

• Le interfacce sono definite come strutture indipendenti

INTERFACE <nome_interfaccia>.…

ENDINTERFACE.

5

Interfacce

• Un interfaccia può contenere sia componenti instance che static.

• All’interno di un interfaccia tutti i componenti sono automaticamente public e non si deve definire esplicitamente la sezione

6

Interfacce

• In un interfaccia è possibile definire i metodi ma non la loro implementazione

• Similmente a come una sottoclasse implementa i metodi di una classe astratta, cosi tutte le classi che usano l’interfaccia devono implementarne i metodi

7

Interfacce

• In ogni classe si possono implementare una o più interfacce

• Più classi possono implementare la stessa interfaccia

8

Interfacce

• Un interfaccia deve essere dichiarata nella sezione public della classe che vuole usarla

INTERFACES <nome_interfaccia>

• In questo modo tutti i componenti dell’interfaccia vengono aggiunti alla classe

• Le classi che usano l’interfaccia devono implementare tutti i metodi in essa definiti

METHOD nome_interfaccia~metodo

9

Interfacce

• Un interfaccia può contenere a sua volta un’altra interfaccia

INTERFACE <nome_interfaccia1>....

ENDINTERFACE.INTERFACE <nome_interfaccia2>.

...INTERFACES <nome_interfaccia1>.

ENDINTERFACE.

10

Interfacce

• Quando una classe usa un interfaccia che ne contiene un’altra deve implementare ogni metodo di ognuna delle due interfacce definite

11

Interfacce

• Il nome completo di un metodo di un interfaccia all’interno di una classe o di un’altra interfaccia è:

nome_interfaccia~nome_metodo

• Al fine di semplificare l’accesso ai moduli è possibile definire degli alias

ALIASES metodo FOR nome_interfaccia~nome_metodo

12

Interfacce

• Gli alias permettono di accedere ad un metodo di un interfaccia in modo diretto

CALL METHOD oggetto->metodo

• All’interno dell’implementazione della classe tuttavia i metodi devono sempre essere richiamati con il nome completo

13

Interfacce

• Come per le classi anche le interfacce possono essere usate per referenziare un oggetto

• E’ possibile eseguire il narrow cast anche attraverso un interfaccia

14

Interfacce

• Le interfacce permetto di usare differenti classi con lo stesso riferimento

• Differenti classi possono implementare i metodi di un interfaccia in maniera differente fra loro

15

Interfacce

• Un interfaccia utilizzata in una superclasse viene ereditata dalla sottoclasse e questa può implementarne i metodi in modo differente

16

Eventi

• Gli eventi servono a gestire gli stati di un oggetto/classe e le loro variazioni in seguito a determinate condizioni

• Un evento può essere static e quindi riferito in modo generico alla classe o instance e quindi proprio dell’oggetto

17

Eventi

• Un evento può essere dichiarato come public, protected o private

• Gli eventi possono anche essere definiti all’interno di un interfaccia ed in questo caso saranno obbligatoriamente public

18

Eventi

• Una classe può definire un metodo per generare un evento

• La stessa classe o un’altra classe può definire un altro metodo per gestire l’evento

19

Eventi

• Un evento deve essere definito nella sezione DEFINITION della casse

EVENTS <nome_evento>.

• Un evento può avere solo parametri di EXPORTING e non deve essere implementato nella sezione di IMPLEMENTATION

20

Eventi

• Un evento può essere generato da qualsiasi metodo all’interno della classe con l’istruzione

RAISE EVENT <nome_evento>.

• Una volta generato l’evento questo deve essere gestito per mezzo di un altro metodo

21

Eventi

• Qualsiasi classe può definire un metodo per gestire un evento sia che questo sia stato generato dalla stessa classe che da un’altra

• Un evento può avere diversi metodi di gestione a lui associati

22

Eventi

• I metodi che gestiscono un evento devono essere definiti come:

METHODS: <nome_metodo> FOR EVENT <nome_evento> OF CLASS <nome_classe>

O:METHODS: <nome_metodo> FOR EVENT

<nome_evento> OF INTERFACE <nome_interfaccia>

23

Eventi

• I metodi per la gestione dell’evento hanno solo parametri di IMPORTING

• I parametri che sono dichiarati con l’evento vengono passati al metodo di gestione dell’evento

• Tuttavia ogni metodo di gestione può decidere quali parametri passati dall’evento utilizzare

24

Eventi

• I metodi che gestiscono un evento non possono essere richiamati con una CALL METHOD

• Essi vengono richiamati in automatico quando l’evento associato viene generato

25

Eventi

• Dopo che un evento è stato generato tutti i metodi di gestione dichiarati vengono eseguiti prima che si passi all’istruzione successiva

• La sequenza con cui i metodi di gestione vengono eseguiti è la stessa in cui sono stati dichiarati

26

Eventi

• Il processo di registrazione è dinamico cioè viene istituito il collegamento in fase di runtime

• Per dichiarare il gestore di un evento si usa l’istruzione:

SET HANDLER oggetto->meth_gest_evento FOR oggetto.

27

Eventi

• I metodi per la gestione di un evento possono di volta in volta essere “attivati” o “disattivati”

• Per attivare o disattivare un metodo di gestione si utilizza l’attributo ACTIVATION dell’istruzione SET HANDLER

28

Eventi

SET HANDLER oggetto->meth_gest_evevento FOR oggetto ACTIVATION = ‘X’.

• Attiva un metodo

SET HANDLER oggetto->meth_gest_evevento FOR oggetto ACTIVATION = ‘ ’.

• Disattiva un metodo

29

Eventi

• A runtime viene definita una struttura invisibile che accoglierà la lista dei metodi di gestione degli eventi e la loro sequenza di esecuzione

• Un metodo per la gestione di un evento può a sua volta generare un altro evento

30

Eventi

31

ESSENTIA.COM srl

Via Druento, 290 - 10078 Venaria Reale (TO)Tel.: 011 – 4560.511 fax: 011 – 4560.577

Via Nizza, 56 – 00198 RomaTel.: 06 – 85305570 fax: 06 – 85800504

Mail: inforoma@e-ssentia.itWeb: www.e-ssentia.com

Powerd by Bossù Piergiorgio