Pubblicato il Lascia un commento

Patterns

Esistono vari modelli comuni per strutturare il codice.

Design pattern

Cosa NON è una libreria, un componente software riusabile, un algoritmo o in generale tutto ciò che risolve “problemi computazionali”.
Cosa è una descrizione, un modello o in generale una soluzione per risolvere un “problema progettuale” generica ad un problema ricorrente.

D.P. STRUTTURALI

Riutilizza oggetti fornendo interfaccia più adatta alle esigenze

  1. Adapter “adattatore” converte interfaccia di classe in interfaccia diversa
  2. Bridge “ponte” separa astrazione di classe da sua implementazione, permettendogli di variare in modo indipendente.
  3. Composite “composto” possibilità di manipolare oggetti in modo uniforme, organizzandoli in una struttura ad albero.
  4. Container “contenitore” soluzione alla rottura incapsulamento causata dall’ereditarietà.
  5. Decorator “decoratore” aggiunge metodi a classi esistenti durante il run-time (svolgimento del programma), più flessibile aggiungere funzionalità agli oggetti.
  6. Extensibility “estendibilità”
  7. Façade “facciata” tramite interfaccia semplice, accesso a sottosistemi che espongono interfacce complesse e diverse tra loro.
  8. Flyweight “peso piuma” separa parti variabili da riutilizzabili di una classe
  9. Proxy posticipa accesso/creazione oggetto al momento in cui serve
  10. Pipes and filters “condotti e filtri”
  11. Private class data “dati di classe privati”

D.P. CREAZIONALI

Creano un’interfaccia sostituendo con dei metodi i costruttori di classe, perciò utilizzabili senza sapere come sono implementate

  1. Abstract factory “fabbrica astratta” fornisce interfaccia per creare famiglie di oggetti connessi o dipendenti tra loro, in modo che non ci sia necessità da parte degli utilizzatori di specificare i nomi delle classi concrete all’interno del proprio codice.
  2. Builder “costruttore” separa la costruzione di un oggetto complesso dalla sua rappresentazione, così il processo di costruzione può creare diverse rappresentazioni.
  3. Factory method “metodo fabbrica” interfaccia per creare un oggetto, lasciando decidere le sottoclassi quale oggetto istanziare.
  4. Lazy initialization “inizializzazione pigra” istanzia oggetto solo quando deve essere usato la prima volta. Spesso usato col factory method.
  5. Prototype “prototipo” crea oggetti clonando un oggetto iniziale, cioè prototipo.
  6. Singleton “singoletto” assicura possa essere creata una sola istanza per classe.

D.P. COMPORTAMENTALI

Soluzione alle interazione più comuni tra oggetti

  1. Chain of Responsibility “catena di responsabilità” riduce accoppiamento fra oggetto che fa richiesta e quello che la soddisfa, dando a più oggetti la possibilità di soddisfarla
  2. Command “comando” isola porzione codice che effettua azione da codice che ne richiede l’esecuzione
  3. Event listener “ascoltatore di eventi”
  4. Hierarchical Visitor “visitatore di gerarchia”
  5. Interpreter “interprete” definisce rappresentazione grammatica linguaggio insieme ad un interprete che utilizza questa rappresentazione per l’interpretazione delle espressioni in quel determinato linguaggio.
  6. Iterator “iteratore” risolve problemi accesso/navigazione elementi struttura dati, senza esporre dettagli implementazione/struttura interna contenitore
  7. Mediator “mediatore” nelle comunicazioni tra oggetti, aggiorna lo stato del sistema quando uno di essi comunica un cambiamento del proprio stato
  8. Memento “promemoria” senza violarne l’incapsulazione estrae e memorizza lo stato interno di un oggetto, diventando così successivamente ripristinabile
  9. Observer “osservatore” dipendenza uno a molti fra oggetti diversi, così che se un oggetto cambia stato, gli oggetti dipendenti vengono notificati del cambiamento avvenuto e possono aggiornarsi
  10. Single-serving Visitor
  11. State “stato” permette ad un oggetto di cambiare il suo comportamento al cambiare di un suo stato interno
  12. Strategy “strategia” quando necessario modificare dinamicamente algoritmi
  13. Template method “metodo schema” definire struttura algoritmo permettendo alle sottoclassi di implementarne alcuni passi custom
  14. Visitor “visitatore” separa algoritmo da struttura oggetti composti a cui è applicato, potendo così aggiungere comportamenti senza modificare la struttura stessa
  15. Null object “oggetto nullo” sostituire riferimento nullo con oggetto che non fa nulla

 

Pattern architetturali

Differenti da design pattern perché non operano a livello di design del sistema ma a livello diverso e più ampio ed esprimono schemi di base per impostare l’organizzazione strutturale di un sistema software, dove si descrivono sottosistemi predefiniti insieme con i ruoli che essi assumono e le relazioni reciproche.

  • Blackboard, architettura per applicazioni di intelligenza artificiale
  • Broker
  • Client-server, rappresenta un tipo di applicazione di rete nel quale un computer client istanzia l’interfaccia utente di un’applicazione connettendosi ad una server application o ad un sistema di database.
  • Layers, architettura basata su layer
  • Microkernel
  • Model-View-Controller (abbreviato spesso in MVC), che consiste nel separare i componenti software che implementano il modello delle funzionalità di business (model), dai componenti che implementano la logica di presentazione (view) e da quelli di controllo che tali funzionalità utilizzano (controller).
  • Model-View-ViewModel (spesso abbreviato in MVVM)
  • Naked objects
  • Pipes and Filters
  • Presentation Abstraction Control
  • Reflection
  • Repository, pattern architetturale legato ad aspetti di persistenza
  • Front Controller, pattern architetturale che prevede l’utilizzo di un singolo file per gestire tutte le richieste
  • Data Access Object
  • Data Transfer Object

Pattern di metodologia

  • Responsibility, ossia “identificare chiaramente e dividere la responsabilità” assegnata a ciascun oggetto o componente del sistema, è il pattern metodologico basilare indicato nel libro Design Patterns.
  • Make it run, make it right, make it fast, make it small

Pattern di concorrenza

Nel caso di processi che eseguono contemporaneamente delle attività su dati condivisi si parla di concorrenza. Alcuni design pattern sono stati sviluppati per mantenere sincronizzato lo stato dei dati in tali situazioni:

  • Active Object
  • Balking pattern
  • Double checked locking pattern
  • Guarded suspension
  • Leaders/followers pattern
  • Monitor Object, che consente soltanto un processo attivo al suo interno, al contempo non necessita di una codifica esplicita della mutua esclusione.
  • Read-write lock pattern
  • Scheduler pattern
  • Thread pool pattern
  • Thread-Specific Storage
  • Token passing synchronization
  • Reactor pattern

 

Fonti

http://www.codeproject.com/Articles/66585/Comparison-of-Architecture-presentation-patterns-M
https://it.wikipedia.org/wiki/Design_pattern
https://sites.google.com/site/omnibuscience/informatica/design-pattern
http://it.phptherightway.com/pages/Design-Patterns.html
http://jream.com/lab

 

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.