Appunti riassuntivi Programmazione (parte 6, adapter e observer)

=>

RIASSUNTO CAPITOLO 10 PROGRAMMAZIONE LIBRO

Adapter

A volte si possono verificare dei casi in cui è necessario usare un codice (come, ad

esempio, una classe) che però originariamente non è sta: pensato per essere usato

con un certo sistema e risulta impossibile o troppo costoso riscriverlo per renderlo

u:lizzabile.

A questo punto un ruolo fondamentale viene svolto dal design pa@ern Adapter il cui

scopo è quello di conver:re l’interfaccia di una classe in un’interfaccia diversa che è

quella a@esa dal codice client.

L’Adapter consente a classi diverse di poter lavorare assieme anche se non

potrebbero a causa delle interfacce compa:bili. Il seguente pa@ern può essere

implementato come class adapter oppure object adapter.

Una presentazione compa@a del pa@ern può essere la seguente:

1. Problema: dato un ogge@o, questo presenta un’interfaccia molto simile ma

non uguale quella che ci serve.

2. Contesto:

i. Si vuole riusare una classe già esistente.

ii. Non si vuole o non si può cambiare l’interfaccia della classe.

iii. Non è pra:co estendere la gerarchia di ereditarietà della classe per

renderla più generale.

3. Soluzione: Si “impacche@a” la classe o l’ogge@o in una classe che fornisce

l’interfaccia a@esa dal codice client fornendo due versioni della soluzione: la

versione per la classe e quella per l’ogge@o.

4. Conseguenza: l’implementazione riceve l’interfaccia a@esa.

Questo design pa@ern, nel caso di soTware, risulta par:colarmente u:le quando si

ha a che fare con sistemi legacy o librerie di terze par: che forniscono interfacce

diverse rispe@o a quelle a@ese dal codice scri@o per un nuovo sistema e che, di

conseguenza, non possono essere riscri@e perché si sprecherebbe troppo tempo o

addiri@ura potrebbe essere impossibile in quanto non disponibile il codice sorgente.

- 2.1: Class Adapter

In questa versione del pa@ern abbiamo una classe (Adapter) che ada@a

l’interfaccia di un’altra classe da ada@are (Adaptee) ad un codice client, usando

l’interfaccia a@esa di una classe astra@a (Target).

Questo :po di implementazione per a@uare la sua soluzione usa l’ereditarietà

mul:pla, le classi astra@e, i metodi virtuali e l’ereditarietà privata.

(GUARDA DISEGNO UML E ESEMPIO DI CLASS ADAPTER)

- 2.2: Object Adapter

Considerate sempre le stesse classi in questa versione, a differenza del Class Adapter,

al posto dell’ereditarietà mul:pla viene usata la composizione per ada@are la classe

che deve essere usata dal codice client.

Si può notare come la composizione consenta anche una maggior