GRASP

Da Wikipedia, l'enciclopedia libera.

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 relative ai 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 sorgente]

Information Expert[modifica | modifica sorgente]

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 sorgente]

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 se 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 sorgente]

Il pattern Controller assegna la responsabilità di eventi di chiamata a sistema ad una classe (che non sia ad 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 sorgente]

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 sorgente]

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 sorgente]

Secondo il pattern Polymorphism, la responsabilità di definizione delle variazioni dei comportamenti basati su tipo viene assegnata ai tipi per i quali avviene tale variazione. Ciò viene ottenuto usando le operazioni di polimorfismo.

Pure Fabrication[modifica | modifica sorgente]

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 sorgente]

Il pattern Indirection supporta il basso accoppiamento (ed il potenziale di riuso) tra due elementi attraverso l'assegnazione di responsabilità di mediazione tra di loro ad 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 sorgente]

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 sorgente]

  1. ^ Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design
  2. ^ GetterEradicator
  3. ^ Comparazione/discussione tra il GRASP Controller Layer e Application/Service Layer

Bibliografia[modifica | modifica sorgente]

  • 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

Voci correlate[modifica | modifica sorgente]