Esercizi Design pattern

1. EserciziDesign pattern

2. Singleton • Permette la creazione di una sola istanzadellaclasseall’internodell’applicazione • Fornisce un metodo con cui ottenerel’istanza • Il costruttoredellaclasse non deveessereaccessibile

3. Singleton UML

4. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • vediamo

5. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • ATTENZIONE: NON THREAD-SAFE

6. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • ATTENZIONE: NON THREAD-SAFE • SynchronizedLazySingleton • vediamo

7. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • ATTENZIONE: NON THREAD-SAFE • SynchronizedLazySingleton • Puòessereinefficientenelle performance

8. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • ATTENZIONE: NON THREAD-SAFE • SynchronizedLazySingleton • Puòessereinefficientenelle performance • EagerSingleton • Eager inizialization: creal’oggettosubito

9. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • ATTENZIONE: NON THREAD-SAFE • SynchronizedLazySingleton • Puòessereinefficientenelle performance • EagerSingleton • Eager inizialization: creal’oggettosubito • Puòoccuparememoriainnecessaria

10. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • ATTENZIONE: NON THREAD-SAFE • SynchronizedLazySingleton • Puòessereinefficientenelle performance • EagerSingleton • Eager inizialization: creal’oggettosubito • Puòoccuparememoriainnecessaria • EnumSingleton • vediamo

11. Singleton: Implementazioni • LazySingleton: • Crearel’istanza solo quando serve • ATTENZIONE: NON THREAD-SAFE • SynchronizedLazySingleton • Puòessereinefficientenelle performance • EagerSingleton • Eager inizialization: creal’oggettosubito • Puòoccuparememoriainnecessaria • EnumSingleton • Non puòereditare da altreclassi

12. Factory Method Pattern • Definisceun’interfaccia per la creazione di un oggetto. • Lascia le sottoclassideciderequalioggettiistanziare

13. Factory Method UML

14. Esercizio: Pizzerie • Progettareil software per la preparazione e ordinazione di pizze. • Installato in diverse pizzerie. • Vediamo

15. Abstract Factory • Fornireun’interfaccia per la creazione di famiglie di oggetticollegati. • A differenza del Factory Method, unaclassedelega la responsabilitàdellacreazione di un oggettotramitecomposizione. • Modifichiamol’esercizioprecedente. • Gestioneuniformedegliingredienti.

16. Abstract Factory UML

17. Adapter • Convertel’interfaccia di unaclasse in un’altracheil client siaspetta. • Permettel’interazionetraclassi con interfacceincompatibili.

18. Adapter UML

19. Esempio: Iterator e Enumeration • Le anticheversionidelle collections in Java nonavevanol’interfacciaiteratorcon I metodi: • hasNext() • next() • remove • Esisteva solo l’interfaccia Enumeration con imetodi: • hasMoreElements() • nextElement()

20. Esercizio1 • Utilizzarecodicenuovoneivecchisistemi legacy. • Implementare un adapter IteratorToEnumerationAdapter da Iterator a Enumeration. • Implementare un LegacyClientcheusaIteratorToEnumerationAdapter

21. Esercizio 2 • Utilizzarecodice legacy neinuovisistemi • Implementare un adapter EnumerationToIteratorAdapterda Enumeration a Iterator. • Implementare un NewClientcheusaEnumerationToIteratorAdapter

22. Proxy • Il proxy pattern espone un oggetto in rappresentanzadi un altro. • Ne controllal’accesso: • Ad es. per motivi di sicurezza

23. Proxy UML

24. Esercizio 3 • Aggiungereallalogicaapplicativauna cache per migliorarel’efficienzanellarispostaallerichiestedegliutenti • L’interfacciadella cache non cambia rispetto a quelladellalogicavera e propria

25. Note • L’utilizzo del proxy non richiedenessunamodificanel client che lo deveutilizzare • Altriesempi di proxy sono le versioniunmodifiabledelle collections • In quelcasoimetodisono re-implementati per inibire le operazioni di modifica

26. Decorator • Permettedi aggiungerefunzionalità ad un oggetto • Il nuovocomportamentopuò essereaggiunto a run time • Non richiede la creazione di nuovesottoclassi

27. Decorator UML

28. Esercizio 4 • Scrivereunaapplicazione per rappresentarediversi tipi di caffè con diversiingredienti • Potremmo fare diverse sottoclassi, ma ne dovremmo fare troppe • La soluzionedellesottoclassi non permetterebbe di aggiungerenuoviingredienti a run time

29. Note • Un approccio simile è usatonelleclassi per l’input/output di Java: stream, writer, reader • Oltre a modificareilcomportamento è possibileancheaggiungerenuovicomportamenti • Decorator è simile a Proxy, ma permette di comporrediversicomportamenti

30. Pattern comportamentali

31. Strategy • Permettedi variareglialgoritmiutilizzatinell’implementazionedellaclasse • La classe base richiedeunastrategiaesterna per portare a terminecorrettamenteilsuocompito • L’abbiamovisto con l’ordinamentocherichiede la suastrategia di comparazionetraunacoppia di elementi

32. Strategy UML

33. Esercizio • Scrivereilcodice per rappresentare un robot chepuò avere diverse strategie per gestireilsuocomportamento • Vogliamo fare sì cheicomportamentipossanocambiarementre la nostra applicazione è in esecuzione

34. Observer • Definisceunadipendenza 1  moltitraoggetti. • Quando un oggetto cambia stato, tuttiglioggettidipendentisononotificati e aggiornatiautomaticamente.

35. Observer UML

36. Esercizio: StazioneMeteo • Progettare un sistema per ilmonitoraggiodel Meteo. • Si ha a disposizionel’oggettoWeatherDatacheforniscetemperatura, umidità, pressione. • Implementaretrediversi display (condizioneattuale, previsioni, e statistiche). • Il sistemadeveessereespandibileper supportarenuovi display.