Quarta ed ultima parte di un corso sulla programmazione ABAP ad Oggetti tenuto da me

1. ABAP OBJECTS
Quarta parte

2. 2
Agenda del corso
• Dai function module agli oggetti
• Definizione di una classe
• Oggetti e metodi
• Incapsulamento, ereditarietà, polimorfismo
• Interfacce
• Eventi

3. 3
Agenda del corso
• Dai function module agli oggetti
• Definizione di una classe
• Oggetti e metodi
• Incapsulamento, ereditarietà, polimorfismo
• Interfacce
• Eventi

4. Interfacce
• L’ABAP come il Java non permette l’ereditarietà
multipla
• Con l’utilizzo delle interfacce è possibile in parte
aggirare questo limite
4

5. 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

6. 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

7. 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

8. Interfacce
• In ogni classe si possono implementare una o più
interfacce
• Più classi possono implementare la stessa
interfaccia
8

9. 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

10. Interfacce
• Un interfaccia può contenere a sua volta un’altra
interfaccia
INTERFACE <nome_interfaccia1>.
...
ENDINTERFACE.
INTERFACE <nome_interfaccia2>.
...
INTERFACES <nome_interfaccia1>.
ENDINTERFACE.
10

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

12. 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

13. 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

14. 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

15. 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

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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. Eventi
31

32. ESSENTIA.COM srl
Via Druento, 290 - 10078 Venaria Reale (TO)
Tel.: 011 – 4560.511 fax: 011 – 4560.577
Via Nizza, 56 – 00198 Roma
Tel.: 06 – 85305570 fax: 06 – 85800504
Mail: inforoma@e-ssentia.it
Web: www.e-ssentia.com
Powerd by
Bossù Piergiorgio