Progettazione object-oriented: utilizzo dei pattern GRASP

Una della più importanti tappe è stata quella della programmazione object-oriented che ha definitivamente messo in soffitta quella cosiddetta lineare.

Anche la progettazione, quindi, si è dovuta adattare tenendo presente un assioma, ovvero che i problemi non sono unici ma tendono sempre a ripresentarsi, anche se in modi e forme diverse.

Proprio per questo motivo sono stati creati dei modelli che potessero essere riutilizzati in modo da poter avere una programmazione molto più semplice a cui è stato assegnato il nome “Pattern“.

Che cosa è il Pattern GRASP

Nel 1997 Craig Larman pubblicò un libro intitolato “Appling UML and Pattern” dove andava per la prima volta ad elaborare il concetto che la descrizione di un singolo problema (il Pattern) può essere identificato da un nome e questa può essere applicata anche in contesti diversi da quello originario.

La “General Responsibility Assignment Software Pattern” (abbreviato in GRASP) è una specifica collezione di Pattern che viene utilizzata all’interno della progettazione e dello sviluppo Object Oriented; le linee guida relative all’assegnazione di responsabilità sia agli oggetti che alle classi sono stabilite da questa collezione che non serve a creare delle nuove informazioni ma è invece un continuo miglioramento nell’ambito della documentazione del software stesso.

Quali sono i Pattern GRASP

I 9 Pattern GRASP identificati da Larman sono i seguenti:

• Information Expert: la responsabilità deve essere data alla classe che detiene tutte le informazioni essenziali e basilari fornendo tutti i modelli che sono generalmente associati alla cosiddetta “assegnazione delle responsabilità” ad ogni oggetto o classe.

• Creator: nel momento in cui compare il problema di assegnazione di responsabilità nella creazione di una nuova istanza all’interno di una classe, questo pattern risolve le problematiche inerenti ad una delle attività più utilizzate ovvero quella della creazioni di oggetti.

• Controller: la responsabilità degli elementi che generano chiamate ad una specifica classe, che non sia una User Interface, che comunica tutti gli eventi associati al sistema all’interno di diversi casi d’uso.

• Lower Coupling: permette la valutazione riguardo all’assegnazione delle responsabilità in modo che possa supportare tre diverse condizioni: 1) che abbia un’alta capacità di riutilizzo 2) che si di impatto basso all’interno di una classe di “cambiamenti in altre classi” 3) vi sia una bassa dipendenza tra le varie classi.

• High Cohesion: anche questo permette la valutazione ma sugli oggetti che sono gestibili, evidenti e focalizzati e generalmente viene utilizzato come supporto per il Lower Coupling. Le responsabilità relative agli oggetti ad alta coesione son quindi molto correlate tra loro e soprattutto intensamente focalizzate

• Polymorphism: nelle variazioni dei comportamenti che sono basati sul “tipo” la responsabilità della definizione viene assegnata ai “tipi per i quali avviene tale variazione” mediante delle operazioni di “polimorfismo”

• Pure Fabrication: classe che non raffigura un’astrazione del problema nel dominio, ideata in modo da avere contestualmente: “basso accoppiamento, alta coesione” e vi sia un notevole potenziale di riuso che possa derivare da esso nel momento in cui “Information Expert” non presenti adeguata soluzione.

• Protected Variations: pattern di protezione degli elementi dalle variazioni che sono effettuate all’interno di qualsiasi altro elemento ovvero oggetto, sistema e sottosistema. L’oggetto viene mascherato mediante una specifica interfaccia e viene usato il polimorfismo in modo da creare diverse implementazioni dell’interfaccia stessa

• Indirection: permette il “Lower Coupling” tra due elementi con il relativo il potenziale di riuso mediante l’assegnazione di “responsabilità di mediazione” tra questi ad un oggetto che possa considerarsi intermedio.