ABAP OBJECTS Quarta parte
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: [email protected]: www.e-ssentia.com
Powerd by Bossù Piergiorgio