{"id":2898,"date":"2017-09-18T09:56:40","date_gmt":"2017-09-18T07:56:40","guid":{"rendered":"http:\/\/ardea.srl\/?p=2898"},"modified":"2019-02-06T17:36:52","modified_gmt":"2019-02-06T16:36:52","slug":"command-design-pattern","status":"publish","type":"post","link":"https:\/\/ardea.srl\/it\/command-design-pattern\/","title":{"rendered":"Command Design Pattern: un esempio di applicazione"},"content":{"rendered":"

Sai usare un Command Design Pattern<\/em>?\u00a0Ti sei mai chiesto cos\u2019\u00e8 un Abstract Factory<\/em>? O com\u2019\u00e8 fatto un Proxy<\/em>? In questo articolo introduciamo i Design Pattern<\/em> raccontandoti un caso reale di applicazione.<\/p>\n

<\/p>\n

Il problema<\/h2>\n

Qualche anno\u00a0fa un cliente ci ha chiesto di rifare un componente di un’applicazione<\/strong> scritta con Java.<\/p>\n

Il\u00a0componente riceveva informazioni (o messaggi) dall\u2019interfaccia utente e da altri\u00a0dispositivi fisici esterni: tastiera dedicata, lettori di carte, scanner\u2026 e trasformava\u00a0i messaggi ricevuti in azioni dell\u2019applicazione. Non c’era\u00a0un ordine predefinito con cui le fonti inviavano i messaggi e i passi che l\u2019applicazione doveva eseguire dipendevano sia dalle informazioni, sia dall\u2019esito della loro elaborazione.<\/p>\n

L\u2019implementazione<\/strong> esistente era fragile<\/strong>: qualche volta\u00a0si bloccava\u00a0e\u00a0l\u2019applicazione doveva essere chiusa e riavviata.<\/p>\n

L\u2019approccio semplice<\/i><\/h2>\n

Per mostrarti la differenza tra l\u2019approccio procedurale e quello a oggetti basato sul Design Pattern<\/em>\u00a0‘Command’<\/em>, cominciamo a vedere\u00a0una soluzione procedurale<\/strong>.<\/p>\n

Cominciamo a costruire un ciclo principale che serve per ricevere ed elaborare tutti i messaggi dalle varie fonti.<\/p>\n

Potrebbe assumere questo aspetto:<\/p>\n

while (true) {\r\n  Object message = readNextMessage();\r\n  \/\/ fai qualcosa con il messaggio\r\n}<\/pre>\n
Il primo problema \u00e8: come gestiamo il messaggio?<\/strong>\u00a0Ogni fonte manda messaggi con struttura differente che devono essere elaborati in modi diversi.<\/p>\n
Per riconoscere il tipo di messaggio potremmo aggiungergli un attributo\u00a0che lo qualifica (type)<\/code>e sulla base del suo valore decidere come procedere:<\/p>\n
switch (message.type) {\r\n  case INPUT_FROM_KEYBOARD:\r\n    \/\/Elabora messaggio da tastiera\r\n  case INPUT_FROM_SCANNER:\r\n    \/\/Elabora messaggio da scanner\r\n  \u2026\r\n}<\/pre>\n
Le diverse\u00a0informazioni che accompagnano il messaggio possono essere registrate in una mappa. Ad esempio, per leggere il valore del tasto premuto dall\u2019utente sulla tastiera, potremmo scrivere:<\/p>\n
value = message.get(\u201ckey\u201d);<\/pre>\n
Il secondo problema \u00e8: come facciamo l\u2019elaborazione dei messaggi?<\/strong> Possiamo\u00a0pensare a un metodo dedicato per ogni tipo di messaggio.<\/p>\n
Bene. Ma c\u2019\u00e8 un altro problema: ogni elaborazione produce un risultato che pu\u00f2 richiedere ulteriori passaggi, dipendenti dal risultato stesso e dal tipo di messaggio.<\/p>\n
Ora puoi ben immaginare il codice che deriva\u00a0da questa soluzione:<\/p>\n