Appunti completi di Programmazione a oggetti e Design patterns

Introduzione

Lunedì 2 marzo 2015 23:11

Il programma

Programmazione a Oggetti

• Object-Oriented paradigmo
• Unified Modeling Language
• Limitations of O-O
• Design Patterns

• Facade pattern
• Adapter pattern
• Strategy pattern
• Bridge pattern
• Abstract Factory pattern
• Decorator pattern
• Observer pattern
• Template method pattern
• Singleton pattern
• Object Pool pattern
• Factory Method pattern

Programmazione Object-Oriented

Venerdì 17 luglio 2015 14:43

I Design Pattern

Venerdì 17 luglio 2015 14:43

Generale

Il termine "design pattern" è il corrispettivo inglese di "schema di progettazione" e definisce un protocollo, un insieme di regole progettuali, da adottare per risolvere un problema ricorrente. I pattern più noti, quelli studiati in questo corso, offrono agli sviluppatori l'opportunità di approfittare delle esperienze e ricerche passate su problemi noti e ricorrenti, offrendo una soluzione già teorizzata e il risolutivo modello più efficiente possibile.

È possibile individuare ogni pattern secondo una struttura comune:

L'uso dei pattern offre inoltre il vantaggio dell'adozione di una terminologia comune, che si rivela molto utile nel caso di grandi team di sviluppo.

Anti-Pattern

Sono dei design pattern, o più in generale delle procedure o modi di fare, usati durante il processo di sviluppo del software, che pur essendo lecitamente utilizzabili, si rivelano successivamente inadatti o controproduttivi nella pratica. Il termine fu coniato nel 1995 da Andrew Koenig. Secondo l'autore, devono presentarsi almeno due elementi chiave per poter distinguere un anti-pattern da un semplice errore logico o cattiva pratica:

• Qualche schema ricorrente di azioni, processi o strutture che inizialmente appaiono di beneficio, ma successivamente producono più problemi che benefici.
• Esiste una soluzione alternativa che è chiaramente documentata, collaudata nella pratica e ripetibile.

Molti anti-pattern sono poco più che errori, problemi irrisolvibili o cattive pratiche da evitare quando possibile. A volte chiamati "pitfalls" (tranelli) o dark pattern (pattern oscuri), si riferiscono a classi di soluzioni di problemi reinventate in modo sbagliato.

Gang of Four

In ingegneria del software il termine inglese Gang of Four ("banda dei quattro"), spesso abbreviato in GoF, è usato per riferirsi agli autori del libro Design Patterns: Elements of Reusable Object-Oriented Software

Elenco Patterns

Sabato 18 luglio 2015 16:36

Nome Facade Pattern

Obiettivo: Semplificare l'utilizzo di un sistema esistente. Definire una propria interfaccia personalizzata.

Problema: Necessità di interagire solo con un sottoinsieme del sistema complessivo. Necessità di interagire con il sistema esistente in un modo particolare.

Soluzione: Presenta una nuova interfaccia per il client del sistema esistente.

Participants & Collaborators: Una nuova classe specializzata nell'interazione con il client per rendere l'utilizzo più semplice.

Conseguenze: Poiché il client può interagire solo con l'interfaccia di facciata, finché quest'ultima non è completa, certe funzionalità del sistema complessivo potrebbero non essere disponibili.

Implementazione: Definire una nuova classe che implementa l'interfaccia richiesta.

Nome Adapter Pattern

Obiettivo: Rende compatibile un oggetto esistente attraverso il controllo di una specifica interfaccia.

Problema: Un sistema ha il giusto comportamento e set di dati, ma presenta un'interfaccia non compatibile. Tipicamente usato quando si deve rendere, una classe, derivata di una classe astratta già definita.

Soluzione: L'adapter pattern fornisce un contenitore con l'interfaccia desiderata.

Participants & Collaborators: L'adapter adatta l'interfaccia di un "adaptee" per essere compatibile con il "Target" dell'"adapter" (la classe da cui deriva). Ciò permette al Client di usare "adaptee" come se fosse di tipo "target".

Conseguenze: L'adapter pattern permette a oggetti già esistenti di adattarsi alla struttura di una nuova classe senza essere limitata dalla loro interfaccia.

Implementazione: Contenere la classe esistente all'interno di una nuova classe. Rendere compatibile con l'interfaccia e i metodi della classe contenuta.

Nome Bridge Pattern

Obiettivo: Disaccoppia un set di implementazioni dal set di oggetti che le utilizzano.

Problema: La derivazione di una classe astratta deve poter utilizzare implementazioni multiple senza causare un'esplosione del numero di casi da trattare.

Soluzione: Definisce un'interfaccia per tutte le implementazioni da usare e derivano la classe astratta che la utilizzano.

Participants & Collaborators: L'abstraction definisce l'interfaccia per gli oggetti implementati. L'implementor definisce l'interfaccia per l'implementazione della specifica classe. Le classi che derivano l'abstraction utilizzano le classi derivate dall'implementor senza conoscere quale sia la particolare ConcreteImplementor che sarà usata.

Conseguenze: Disaccoppiare le implementazioni in classi astratte.

Implementazione: Incapsulare le implementazioni in classi astratte e contenere l'implementazione del comportamento da adottare nella classe astratta di base.

Nome Abstract Factory Pattern

Obiettivo: Creare famiglie di oggetti che si adattino a client particolari.

Problema: Necessità di istanziare famiglie di oggetti o oggetti dipendenti.

Soluzione: Coordina la creazione di famiglie di oggetti. Offre l'opportunità di definire le regole riguardo all'istanziamento, fuori dall'oggetto client.

Participants & Collaborators: L'AbstractFactory definisce l'interfaccia per la creazione di ciascun membro della famiglia di oggetti richiesti. In genere, ogni famiglia è creata mediante un proprio ConcreteFactory unico.

Conseguenze: Il modello isola le regole degli oggetti da utilizzare dalla logica di come utilizzare questi oggetti.

Implementazione: Definire una classe astratta che specifica quale oggetto deve essere creato, poi implementare una classe per ogni famiglia.

Nome Strategy Pattern

Obiettivo: Permettere di utilizzare algoritmi diversi dipendentemente dal contesto in cui si opera.

Problema: Selezionare uno specifico algoritmo che deve essere utilizzato secondo la richiesta fatta dal client.

Soluzione: Separa la scelta dell'algoritmo di cui si necessita dalla sua implementazione, permettendo che la decisione possa essere presa in base al contesto.

Participants & Collaborators: Strategy: specifica come i diversi algoritmi saranno usati. ConcreteStrategies: implementa i differenti algoritmi. Context: usa lo specifico ConcreteStrategies riferito al tipo Strategy. Lo Strategy e il Context concorrono ad implementare l'algoritmo richiesto (solitamente lo Strategy chiama il Context). Il Context inoltra la richiesta dal suo Client allo Strategy.

Conseguenze: Il modello isola le regole degli oggetti da utilizzare dalla logica di come utilizzare questi oggetti.

Implementazione: Definire una classe astratta che utilizza l'algoritmo (Context) contenente l'implementazione di una classe astratta (Strategy) che possiede un metodo astratto che definisce come chiamare l'algoritmo.

Nome Decorator Pattern

Obiettivo: Attribuire dinamicamente responsabilità aggiuntive a un oggetto.

Problema: L'oggetto che si vuole utilizzare fornisce le funzionalità di base necessarie, ma si potrebbe aver bisogno di aggiungere alcune funzionalità aggiuntive all'oggetto.

Soluzione: Permette di aggiungere funzionalità senza dover ricorrere a una sottoclasse.

Participants & Collaborators:

• Component: definisce l'interfaccia dell'oggetto a cui verranno aggiunte nuove funzionalità.
• ConcreteComponent: definisce l'oggetto concreto al quale aggiungere le funzionalità.
• Decorator: mantiene un riferimento all'oggetto Component e definisce un'interfaccia conforme all'interfaccia Component.
• ConcreteDecorator: aggiunge le funzionalità al Component.

Conseguenze: Le funzionalità che possono essere aggiunte risiedono in piccoli oggetti, il vantaggio è rappresentato dalla possibilità di aggiungere dinamicamente le funzionalità nel ConcreteComponent.

Implementazione: Creazione di una classe astratta che rappresenta la classe originaria e le nuove funzioni da aggiungere. Nel decorator si implementano le chiamate alle nuove funzioni prima o dopo le chiamate esistenti, per ottenere il giusto ordine.

Nome Singleton Pattern

Obiettivo: Avere una sola istanza di un oggetto senza che questo sia dichiarato globalmente.

Problema: Client diversi necessitano di riferirsi a un solito oggetto e si vuol essere sicuri di avere una sola istanza di esso.

Soluzione: Garantire una sola istanza.

Participants & Collaborators: I Clients creano un'istanza del Singleton soltanto attraverso il metodo getInstance.

Conseguenze: I Clients non devono occuparsi autonomamente di verificare che il Singleton esista, ciò è controllato dall'istanza del Singleton.

Implementazione: Aggiungere un metodo privato statico della classe che si riferisce all'oggetto desiderato (inizialmente nullo). Aggiungere metodo pubblico statico che istanzi la classe se non lo è stato fatto e ritorna l'oggetto istanziato.