Introduzione base ai Design Pattern in Java.

1. Design Pattern in Java
Un modo di fare qualcosa,
di perseguire un intento usando
la tecnologia a oggetti

2. HELLO!
Io sono Antonio Musarra
Sono qui per cercare di trasmettere come i
design pattern possano diventare i nostri migliori
amici.
Puoi trovarmi con un tweet a @antonio_musarra

3. Categorie di pattern
» Pattern architetturali (stili architetturali):
descrivono lo schema organizzativo della struttura
che caratterizza un sistema software.
⋄ In genere individuano le parti del sistema a cui
sono associate responsabilità omogenee e le
relazioni che esistono tra i diversi sottosistemi.

4. Categorie di pattern
» Pattern di disegno (design pattern): sono i pattern
che si riferiscono alle problematiche legate al
disegno object-oriented
⋄ forniscono uno schema per raffinare gli elementi
di un sistema software o le relazioni tra di essi
⋄ descrive una struttura che ricorre comunemente
di elementi di progetto interconnessi, che
risolvono un problema di progettazione generale
in un contesto particolare

5. Categorie di pattern
» Pattern di implementazione (idiomi): sono pattern
di basso livello specifici per una particolare
tecnologia (per esempio, il .NET Framework, J2EE).
⋄ descrivono le modalità implementative da
utilizzare per risolvere problematiche di sviluppo
sfruttando in modo mirato le caratteristiche
peculiari di una particolare piattaforma.

6. Categorie di pattern
Ciascuna categoria è caratterizzata da un grado di astrazione
differente.
» I pattern architetturali sono troppo generici per essere
orientati a risolvere problematiche di disegno
» I pattern idiomatici, molto legati alla tecnologia a cui si
riferiscono e all’implementazione vera e propria.

7. Categorie di pattern
Ciascuna categoria è caratterizzata da un grado di
astrazione differente.
» I design pattern descrivono soluzioni che
lasciano sempre e comunque un certo grado di
libertà nella loro adozione e implementazione
⋄ non descrivono mai soluzioni che sono valide
per una piattaforma specifica
⋄ hanno una validità più generale e trasversale
rispetto alla tecnologia

8. Introduzione ai design pattern
» Pattern di interfaccia
» Pattern di responsabilità
» Pattern di costruzione
» Pattern di operazione
» Pattern di estensione
La maggior parte delle implementazioni dei design pattern in java
sono disponibili sul repository GitHub java-design-patterns
all’indirizzo https://github.com/amusarra/java-design-patterns

9. 1.
Perchè i design pattern
Un modo comune per risolvere problemi
ricorrenti

10. A quale scopo usare i pattern?
» Un pattern è un metodo ben preciso di
svolgere un determinato lavoro, di
perseguire un intento.
» E’ possibile identificare metodi efficaci d’uso
comune per raggiungere obiettivi e risolvere
problemi in vari contesti.
» Un design pattern, letteralmente “pattern di
progettazione”, è un pattern che utilizza le
classi e i metodi di un linguaggio orientato
agli oggetti.

11. I Design Pattern
» Fanno parte dell’ingegneria del software
» Introdotti perchè ci si accorse che c’erano
problemi ricorrenti e le soluzioni adottate
erano pressoché simili
» Introdotti per fornire uno schema di
partenza dal quale definire poi i propri
progetti
» L’adozione dei pattern rende più flessibili e
robusti i sistemi sw e il tempo dedicato alla
ricerca di una soluzione diminuisce.

12. Struttura dei Design Pattern
» Nome: deve essere univoco, composto da una o due parole,
cercando di rendere chiara la tipologia di pattern
» Problema Affrontato: descrizione del contesto in cui
applicare il pattern
» Soluzione: descrizione delle classi, delle relazioni e
implicazioni. La soluzione deve essere espressa in forma
generica, visto che si offre come risoluzione di un problema
astratto
» Conseguenze: sono tutti i vincoli e risultati che derivano
dall’applicazione del pattern

13. Problema da
risolvere
Design Pattern
Pattern Prescelto Implementazione

14. 2.
Pattern di interfaccia
L’importanza del costrutto interface di java

15. Oltre le interfacce Java
» Con l’applicazione appropriata delle interfacce Java è
possibile semplificare e rendere più robusto il codice. Andare
oltre l’uso ordinario delle interfacce se:
⋄ Vogliamo adattare l’interfaccia di una classe per farla
corrispondere alle esigenze di un client allora
applicheremo il pattern Adapter
⋄ Vogliamo fornire una semplice interfaccia che racchiuda
una collezioni di classi allora applicheremo il pattern
Facade

16. Oltre le interfacce Java
» Con l’applicazione appropriata delle interfacce Java è
possibile semplificare e rendere più robusto il codice. Andare
oltre l’uso ordinario delle interfacce se:
⋄ Vogliamo definire un’interfaccia che si applichi sia a
singoli oggetti che a gruppi di oggetti allora applicheremo
il pattern Composite
⋄ Vogliamo rendere indipendente un’astrazione dalla sua
implementazione in modo che le due possano variare
indipendentemente allora applicheremo il pattern Bridge

17. 3.
Pattern di responsabilità
Centralizzare, delegare e limitare la
responsabilità degli oggetti

18. Oltre la normale distribuzione di responsabilità
» In quei contesti in cui bisogna deviare dalla regola normale
secondo cui la responsabilità deve essere distribuita il più
ampiamente possibile, se:
⋄ Vogliamo centralizzare tutta la responsabilità di una
classe in una sua singola istanza, allora applicheremo il
pattern Singleton
⋄ Vogliamo permettere ad un oggetto di non tenere conto di
quali altri oggetti dipendono dal suo stato, allora
applicheremo il pattern Observer

19. Oltre la normale distribuzione di responsabilità
» In quei contesti in cui bisogna deviare dalla regola normale
secondo cui la responsabilità deve essere distribuita il più
ampiamente possibile, se:
⋄ Vogliamo centralizzare la responsabilità in una classe che
supervisioni le interazioni di un insiemi di oggetti, allora
applicheremo il pattern Mediator
⋄ Vogliamo consentire a un oggetto di agire in vece di un
altro oggetto, allora applicheremo il pattern Proxy

20. Oltre la normale distribuzione di responsabilità
» In quei contesti in cui bisogna deviare dalla regola normale
secondo cui la responsabilità deve essere distribuita il più
ampiamente possibile, se:
⋄ Vogliamo permettere a una chiamata di percorrere una
catena di oggetti finché non trova quello in grado di
gestirla, allora applicheremo il pattern Chain of
Responsibility
⋄ Vogliamo centralizzare la responsabilità in oggetti
condivisi di granularità fine, allora applicheremo il
pattern Flyweight

21. 4.
Pattern di costruzione
La strada per costruire oggetti in modo adeguato

22. Oltre i costruttori Java
» I pattern orientati alla costruzione permettono a un client di
costruire un nuovo oggetto senza chiamare direttamente il
costruttore di una classe, quindi, se:
⋄ Vogliamo ottenere gradualmente informazione su un
oggetto prima di richiedere la costruzione, allora
applicheremo il pattern Builder
⋄ Vogliamo rimandare la decisione su quale classe
istanziare, allora applicheremo il pattern Factory Method

23. Oltre i costruttori Java
» I pattern orientati alla costruzione permettono a un client di
costruire un nuovo oggetto senza chiamare direttamente il
costruttore di una classe, quindi, se:
⋄ Vogliamo costruire una famiglia di oggetti che
condividono qualche caratteristica, allora applicheremo il
pattern Abstract Factory
⋄ Vogliamo specificare l’oggetto da creare fornendo un
esempio, allora applicheremo il pattern Prototype
⋄ Vogliamo ricostruire un oggetto a partire da una versione
inattiva che contiene solo il suo stato interno, allora
applicheremo il pattern Memento

24. 5.
Pattern di operazione
Il polimorfismo: classi differenti che
implementano un’operazione in modi diversi

25. Oltre le normali operazioni
» Le potenzialità del polimorfismo si manifestano in molti
pattern, quindi, se:
⋄ Vogliamo implementare un algoritmo con un metodo,
rimandano la definizione di alcuni passaggi in modo che
possano essere ridefiniti nelle sottoclassi, allora
applicheremo il pattern Template Method
⋄ Vogliamo distribuire un’operazione in modo che ogni
classe rappresenti uno stato differente, allora
applicheremo il pattern State

26. Oltre le normali operazioni
» Le potenzialità del polimorfismo si manifestano in molti
pattern, quindi, se:
⋄ Vogliamo incapsulare un’operazione, rendendo diverse le
sue implementazioni intercambiabili, allora applicheremo
il pattern Strategy
⋄ Vogliamo incapsulare la chiamata di un metodo
all’interno di un oggetto, allora applicheremo il pattern
Command
⋄ Vogliamo distribuire un’operazione in modo che ogni sua
implementazione si applichi a un tipo diverso di
composizione, allora applicheremo il pattern Interpreter

27. 6.
Pattern di estensione
Come aggiungere nuovi comportamenti a un
oggetto senza alterare la sua classe

28. Oltre le normali estensioni
» Le potenzialità del polimorfismo si manifestano in molti
pattern, quindi, se:
⋄ Vogliamo associare dinamicamente responsabilità
aggiuntive a un oggetto, allora applicheremo il pattern
Decorator
⋄ Vogliamo fornire un metodo per accedere a una
collezione di istanze di una classe creata da noi, allora
applicheremo il pattern Iterator
⋄ Vogliamo permettere l’aggiunta di nuove operazioni a una
classe senza doverla cambiare, allora applicheremo il
pattern Visitor

29. THANKS!
Per qualunque domanda?
Puoi trovarmi
» @antonio_musarra
» antonio.musarra@gmail.com
» https://www.dontesta.it