GRASP
GRASP (General Responsibility Assignment Software Patterns) è una collezione di pattern, usata nella progettazione object-oriented, che fornisce delle linee guida per l'assegnazione di responsabilità alle classi e agli oggetti.
GRASP comprende principalmente i seguenti pattern: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations. Tutti questi pattern rispondono ad alcune problematiche del software, nella maggior parte dei casi relativi a progetti di sviluppo software; pertanto, non servono per creare nuove informazioni, ma per migliorare la documentazione del software e standardizzare i vecchi modelli di programmazione.
Come dichiarato da Craig Larman nella prefazione del suo libro Applying UML and Patterns[1], GRASP è una sorta di strumento "mentale", un aiuto didattico per la progettazione del software orientato agli oggetti.
GRASP Patterns
[modifica | modifica wikitesto]Information Expert
[modifica | modifica wikitesto]Il pattern Information Expert fornisce i modelli generali associati all'assegnazione delle responsabilità agli oggetti e stabilisce che la responsabilità deve essere assegnata all'Information Expert (la classe che possiede tutte le informazioni essenziali).
Questa linea guida favorisce la decentralizzazione delle responsabilità e delle decisioni nel sistema software, migliorando l'incapsulamento e riducendo così l'accoppiamento di altre classi per l'implementazione della classe Information Expert. I sistemi che usano in maniera appropriata il pattern Information Expert sono più facili da capire, mantenere ed espandere; inoltre aumentano la possibilità che un elemento possa essere riusato per sviluppi futuri[2].
Creator
[modifica | modifica wikitesto]Il pattern Creator risolve il problema di chi debba essere responsabile per la creazione di una nuova istanza di una classe. Questo pattern è importante, perché la creazione di oggetti è una delle attività più onnipresenti in un sistema orientato agli oggetti. Un sistema che impiega il pattern Creator può ottenere anche basso accoppiamento, migliore intelligibilità, incapsulamento e la sensazione che l'oggetto in esame sarà in grado di sostenere il riuso. Date due classi A e B, B potrebbe essere responsabile per la creazione di A nel caso in cui B contenga (o nel complesso aggreghi, registri, usi strettamente e contenga) le informazioni iniziali per A. In tal caso si può anche affermare che B è l'oggetto naturale per divenire creatore degli oggetti di A.
Il pattern Factory è un'alternativa a Creator, usata in casi particolari, ad esempio logiche di creazione complesse, che vengono realizzate creando un oggetto Pure Fabrication, chiamato Factory, che gestisce la creazione.
Controller
[modifica | modifica wikitesto]Il pattern Controller assegna la responsabilità di eventi di chiamata a sistema a una classe (che non sia a interfaccia utente) che rappresenta l'intero sistema in uno scenario di caso d'uso. Un controllore di casi d'uso potrebbe essere impiegato per comunicare con tutti gli eventi di sistema di uno o più casi d'uso (ad esempio, per i casi d'uso Crea Utente ed Elimina Utente, si può usare un solo controllore ControlloreUtente, anziché due separati per ciascun caso d'uso). Il pattern è definito come il primo oggetto che riceve e coordina un'operazione di sistema. Il controllore dovrebbe delegare ad altri oggetti il lavoro necessario da svolgere. Esso non dovrebbe svolgere molto lavoro, in quanto coordina o controlla l'attività.
GRASP Controller può essere considerato anche come parte dell'Application/Service Layer [3] (nell'ipotesi che l'applicazione abbia compiuto una distinzione esplicita tra Application/Service Layer e Domain Layer) in un sistema orientato agli oggetti con layer comuni.
Low Coupling
[modifica | modifica wikitesto]Low Coupling (o basso accoppiamento) è un pattern valutativo, che stabilisce come assegnare le responsabilità per supportare:
- bassa dipendenza tra classi;
- basso impatto in una classe dei cambiamenti in altre classi;
- alto potenziale di riuso;
High Cohesion
[modifica | modifica wikitesto]High Cohesion (o alta coesione) è un pattern valutativo che cerca di mantenere gli oggetti focalizzati, gestibili e intelligibili in maniera appropriata. L'alta coesione viene in generale usata a supporto del basso accoppiamento. Un'alta coesione significa che le responsabilità di un dato elemento sono fortemente correlate ed altamente focalizzate. I programmi d'interruzione nelle classi e nei sottosistemi sono un esempio di attività che aumentano le proprietà di coesione del sistema. Viceversa, una bassa coesione è una situazione in cui un dato elemento possiede troppe responsabilità slegate. Spesso gli elementi con bassa coesione soffrono di bassa comprensione, difficile riuso e manutenzione e forte avversità ai cambiamenti.
Polymorphism
[modifica | modifica wikitesto]Secondo il pattern Polymorphism, la responsabilità di definizione delle variazioni dei comportamenti basati sul tipo viene assegnata ai tipi per i quali avviene tale variazione. Ciò viene ottenuto usando le operazioni di polimorfismo.
Pure Fabrication
[modifica | modifica wikitesto]Pure Fabrication è una classe che non rappresenta un concetto nel dominio del problema, creato specialmente per ottenere basso accoppiamento, alta coesione e potenziale di riuso da esso derivante (quando non vi è una soluzione presentata dal pattern Information Expert). Questo tipo di classe è chiamato "Service" nella progettazione guidata dal dominio.
Indirection
[modifica | modifica wikitesto]Il pattern Indirection supporta il basso accoppiamento (e il potenziale di riuso) tra due elementi attraverso l'assegnazione di responsabilità di mediazione tra di loro a un oggetto intermedio. Un esempio è l'introduzione di un componente controllore per la mediazione tra i dati (modello) e la loro rappresentazione (vista) nel pattern Model-View-Controller.
Protected Variations
[modifica | modifica wikitesto]Il pattern Protected Variations protegge gli elementi dalle variazioni compiute in altri elementi (oggetti, sistemi, sottosistemi) mascherandoli con un'interfaccia ed usando il polimorfismo per creare diverse implementazioni di quest'interfaccia.
Note
[modifica | modifica wikitesto]- ^ Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design
- ^ GetterEradicator
- ^ Comparazione/discussione tra il GRASP Controller Layer e Application/Service Layer, su tech.groups.yahoo.com. URL consultato il 19 gennaio 2009 (archiviato dall'url originale il 15 luglio 2012).
Bibliografia
[modifica | modifica wikitesto]- Craig Larman, Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development (3ª edizione), Prentice Hall PTR (2005) ISBN 0-13-148906-2