cnesan ha scritto:
OSSERVAZIONE: Il codice relativo alla "gestione delle responsabilità" ossia generazione degli oggetti e relativa definizione della sequenza, non andrebbe messa in una classe separata (ad esempio: ChainManager) al fine di nascondere la sequenza all'utente ?
Il Chain of Responsibility, così come altri pattern, non ha un solo ed unico modo di implementazione. Ci possono essere differenze e varianti più o meno fini. Quello che importa è "intravedere" il pattern.
Se ti capita di vedere una cosa del tipo:
public interface Handler {
void setNextHandler(Handler handler);
void execute();
}
e una classe concreta per uno "step" specifico nella catena del tipo:
public class MyHandler implements Handler {
private Handler next;
// ... implementazione metodi
}
Vuol dire (già solo osservando la interfaccia) che ciascun handler ha il riferimento
diretto al prossimo handler. Ma non è detto che debba per forza essere così.
Una variante è fare in modo che un handler NON riceva il riferimento diretto al prossimo handler ma riceva un oggetto di tipo X (fornito dal "manager" della catena) che "sa" come invocare il prossimo handler. Il vantaggio di quest'ultima variante è che quell'oggetto X può fare della logica in mezzo (es. logging o altro) prima di invocare il "prossimo" handler. Mentre invece con il Handler detto prima, una volta che sono stati "incatenati" insieme tutti gli handler ... è fatta, in mezzo non si può fare più nulla, per dire.
Un'altra variante ancora possibile è fare in modo che ciascun handler NON riceva e NON abbia alcuna riferimento da invocare per il successivo. Invece il metodo "execute" (o come lo si chiama) potrebbe restituire un true/false per dire se continuare o no nella catena (o il contrario: true=è stato gestito, non andare oltre).
La "catena" degli handler ovviamente la avrà un altro oggetto "manager" della catena, che terrà una lista di handler e invocherà ciascuno proseguendo o no a seconda di come risponde ciascun handler. In questo caso, ciascun handler è addirittura assolutamente ignaro della catena.
Bene, in tutti questi che ho detto è SEMPRE il Chain of Responsibility. Il concetto è lo stesso: avere una catena di responsabilità dove ci possono essere più oggetti che sarebbero in grado di gestire una certa richiesta, dando a ciascuno la possibilità di gestirla oppure no.
E' questo che deve essere "intravisto".
Riguardo la questione se questo (e i pattern in generale) sia utile o sia una c....ta, queste cose POSSONO essere utili. Se fatte in modo sensato, possono rendere una architettura più facilmente manutenibile ma anche più comprensibile. Se chi ci mette mano ha le idee chiare su OOP/design-pattern "intravede" sicuramente quel tal pattern per cui riesce subito a farsi innanzitutto una idea generale del progetto.
Secondo me le c....te nell'informatica sono ben altre. Mi è capitato e mi capita di vedere spesso in progetti "importanti" (di banche, assicurazioni ecc..) delle scemenze totali assolutamente inutili.
Del tipo: qualcuno è riuscito (pensate!) a fare un catch con logging del tipo:
try {
.....
} catch (Exception e) {
logger.error(e.getStackTrace().toString());
}
getStackTrace() restituisce un array. E il toString() sugli array non è significativo (rimane il toString() di Object). Quindi quel logging non serve a un piffero.
Non so dire chi l'ha scritto. Fosse solo per me, lo rimanderei a casa a studiare Java ....