Descrizione dei design pattern Observer, Composite, Strategy e Command.
Observer
L'observer è un design pattern comportamentale.
Definisce una dipendenza di tipo uno-a-molti tra oggetti in modo che quando un oggetto cambia lo stato, tutti i suoi oggetti dipendenti vengono notificati e aggiornati automaticamente.
Problema e soluzione
- Notificare le modifiche ogni volta che un oggetto cambia il proprio stato
- Le notifiche dovrebbero coinvolgere solo gli oggetti interessati
- Deve essere possibile aggiungere o rimuovere gli osservatori in qualsiasi momento
- Integrare un meccanismo di iscrizione nel subject
- Il subject si occupa di notificare tutti gli oggetti iscritti quando cambia lo stato
- L'accoppiamento tra subject e observer deve essere lasco
UML
Loading diagram...
Diagramma di sequenza
Loading diagram...
Codice Subject
public abstract class Subject {
protected Set<Observer> observers;
public void attach(Observer observer) { observers.put(observer); }
public void detach(Observer observer) { observers.remove(observer); }
protected void notify(Object state) {
for (Observer observer : observers)
observer.update(this, state);
}
}
public class BookStore extends Subject {
List<Book> books;
public List<Book> getBooks() { return books; }
public void addBook(Book book) {
books.add(book);
notify(books);
}
}
Codice Observer
public interface Observer {
public void update(Subject subject, Object state);
}
public class Reader implements Observer {
List<String> bookWishlist;
@Override
public void update(Subject subject, Object state){
if (state instanceof List<Book> books){
for (Book book : books) {
if (wishlist.contains(book))
book.buy();
}
}
}
}
Implementazione in Java
Data l'importanza del pattern, Java ne fornisce una implementazione nativa, con le interfacce Observer e Observable.
Tuttavia il loro utilizzo è stato deprecato a partire dalla versione 9.
L'alternativa nativa è rappresentata da java.util.concurrent.Flow, che fornisce un'interfaccia per la pubblicazione e sottoscrizione di eventi in maniera asincrona.
Possibili applicazioni
- Gestione di un'architettura distribuita
- Sistema di notifiche
- Attesa di input esterni
Pro e contro
- La lista di oggetti da notificare è dinamica
- Approccio push invece che pull
- Associazione lasca fra Subject e Observers
- Non c'è garanzia nell'ordine delle notifiche
- L'interfaccia dell'Observer tende a essere generica e necessitare cast
Composite
Il composite è un design pattern strutturale.
Consente di rappresentare oggetti composti da altri oggetti in modo da trattarli come se fossero oggetti semplici.
Problema e soluzione
- Necessità di gestire una gerarchia di oggetti ad albero
- Evitare che il client si preoccupi di gestire interfacce diverse per oggetti semplici e composti
- Le chiamate devono essere riportate a tutti gli oggetti della struttura
- Implementare una singola interfaccia per tutti gli oggetti della gerarchia
- Permettere una specializzazione, trasparente per il client, di oggetti semplici e composti
- I metodi possono essere richiamati ricorsivamente
UML
Loading diagram...
Codice
public interface Item {
public float getCost();
}
public class Book implements Item {
private float price;
public float getCost() { return price; }
}
public class Box implements Item {
private List<Item> items;
public void add(Item item) { items.add(item); }
public void remove(Item item) { items.remove(item); }
public float getCost() {
float cost = 0;
for (Item item : items)
cost += item.getCost();
return cost;
}
}
Possibili applicazioni
- Strutture ad alberi
- Gestione di file e cartelle
- Organizzazione di oggetti in una gerarchia
Pro e contro
- Il client non deve conoscere la gerarchia
- È possibile interagire con gli oggetti utilizzando la medesima interfaccia
- Non è applicabile se le differenze fra le categorie di oggetti iniziano a diventare troppo evidenti
Strategy
Il strategy è un design pattern comportamentale.
Consente di definire una famiglia di algoritmi, rendendoli intercambiabili e indipendenti dagli altri.
Problema e soluzione
- Necessità di utilizzare diversi algoritmi per lo stesso scopo
- Fare in modo che l'implementazione sia trasparente al client
- Poter cambiare l'algoritmo a runtime
- Definire una interfaccia comune per tutti gli algoritmi
- Separare l'algoritmo dalla classe che lo utilizzerà
- Applicare dependency injection
UML e diagramma di sequenza
Loading diagram...
Loading diagram...
Codice
public class Graph {
// ...
SPAlgorithm algorithm;
public void setShortestPathAlgorithm(SPAlgorithm algorithm) {
this.algorithm = algorithm;
}
public List<Node> shortestPath(Node source, Node destination) {
return algorithm.shortestPath(source, destination);
}
}
public class Dijkstra implements SPAlgorithm {
public List<Node> shortestPath(Node source, Node destination) {
// ...
}
}
public class BellmanFord implements SPAlgorithm {
public List<Node> shortestPath(Node source, Node destination) {
// ...
}
}
Possibili applicazioni
- Gestione di algoritmi di ordinamento
- Diverse metodologie di calcolo di un percorso
- Possibilità di selezione fra algoritmi più o meno efficienti a seconda delle circostanze
Pro e contro
- Possibilità di cambiare l'algoritmo a runtime
- Separazione di responsabilità fra classe e algoritmo
- I client potrebbero avere la necessità di conoscere gli algoritmi
- Potrebbe essere sostituito da un approccio funzionale
Command
Il command è un design pattern comportamentale.
Prevede di incapsulare una richiesta in un oggetto, permettendo di parametrizzare uno stesso invoker con richieste diverse, impostando arbitrariamente il receiver della determinata richiesta.
Problema e soluzione
- Mantenere separata la logica di presentazione da quella di business
- Permettere ad uno stesso invoker di lanciare richieste diverse senza preoccuparsi della loro implementazione
- Riutilizzare l'implementazione di una richiesta in più contesti
- Incapsulare la richiesta stessa in un oggetto
- Parametrizzare l'invoker con un oggetto che implementa l'interfaccia della richiesta
- Far conoscere alla richiesta il receiver in grado di eseguirla
UML
Loading diagram...
Diagramma di sequenza
Loading diagram...
Invoker e receiver
// Invoker
public class Button {
Command command;
public void setCommand(Command command) {
this.command = command;
}
public void click() {
command.execute();
}
}
// Receiver
public class DeathStar {
private int x, y;
public void selfDestroy() {
System.out.println("La Death Star si è autodistrutta. But why?");
}
public void fireLaser() {
System.out.println("Si spara il laser nel punto (" + x + ", " + y + ")");
}
public void aim(int x, int y) {
this.x = x; this.y = y;
}
}
Command
public interface Command {
void execute();
}
public class SelfDestructCommand implements Command {
private DeathStar deathStar;
public SelfDestructCommand(DeathStar deathStar) {
this.deathStar = deathStar;
}
public void execute() { deathStar.selfDestroy(); }
}
public class ShootCommand implements Command {
private DeathStar deathStar;
private int x, y;
public ShootCommand(DeathStar deathStar, int x, int y) {
this.deathStar = deathStar;
this.x = x;
this.y = y;
}
public void execute() { deathStar.aim(x, y); deathStar.fireLaser(); }
}
Possibili applicazioni
- Comandi invocati da più sorgenti (GUI, CLI, etc.)
- Trasferimento di un comando su un altro thread
- Implementazione di un undo/redo
- Scheduling dei comandi
Pro e contro
- I comandi possono essere facilmente riutilizzati da più sender (invoker)
- Separazione di responsabilità fra sender e receiver
- Possibilità di comporre una sequenza di comandi
- Aggiunta di un layer in più fra sender (invoker) e receiver
Challenge
- (Observer) Implementare un sistema di notifiche per un sistema di messaggistica istantanea
- (Composite) Simulare un file system con la possibilità di ottenere informazioni come la memoria occupata
- (Strategy) Implementare un sistema di ordinamento di array di interi con diverse strategie (Bubble Sort, Merge Sort, Quick Sort, etc.)