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