Teoria Pattern Grasp - Domanda teorica all'esame

Pattern GRASP

Cosa sono i pattern GRASP?

I pattern GRASP sono 9 pattern generali che ci guidano nella scelta per l'assegnazione delle responsabilità del software, poiché noi facciamo una progettazione guidata dalle responsabilità. Questi propongono soluzioni esemplari generali a problemi di progettazione comuni. Nello sviluppo iterativo, per garantire la modificabilità e comprensibilità, bisogna organizzare il codice in moduli debolmente accoppiati e fortemente coesi (* principio di progettazione fondamentale della modularità) . Questo perché necessitiamo di un meccanismo iterativo. (Flessibile e facilmente modificabile ---> caratteristica del codice).

Per sostenere la modificabilità e la comprensibilità del codice è bene fare progetti moduliabili, altamente coesi e debolmente accoppiati. Oltre a questi pattern valutativi che permangono comunque i principi base per una buona progettazione per responsabilità degli oggetti, abbiamo bisogno di altre pattern.

CONTROLLER

Problema: qual è il primo oggetto oltre lo strato UI, dove può esserci o lo strato applicazione(che si occupa di gestire lo stato delle sessioni) o lo strato del dominio, che riceve e coordina le operazioni di sistema?

Soluzione: o scegliere un controller specifico per il caso d'uso entro cui avviene quella specifica operazione di sistema, quindi si chiamerà control di caso d'uso o di sessione, oppure un controller unico per tutti i casi d'uso e si chiama faccafe controller e infine la terza scelta che prevede che se abbiamo un'applicazione utilizzata da più tipologie di utente, ciascuno ha un proprio controller. Un oggetto della presentazione(il controller MVC) chiede al controller dello strato del dominio(controller GRASP) di eseguire le operazioni.

CREATOR

Problema: chi crea l’oggetto A? (attività comune e necessaria, svolgerla con un basso accoppiamento)

Soluzione: assegna alla classe B la responsabilità di creare un'istanza della classe A se una delle seguenti condizioni è vera(più sono vere e meglio è)

• B 'contiene' o aggrega una composizione oggetti di tipo A
• B registra A
• B utilizza strettamente A:
• B deve ripetutamente parlare con tale oggetto, nel corso del caso d'uso l'oggetto di tipo B chiede di eseguire operazioni più volte
• B possiede i dati per l'inizializzazione di A

In questo modo troviamo diversi candidati per la creazione di A. Solitamente ha la meglio quello che è legato tramite composizione (di tipo concettuale che poi può essere rispecchiata in una composizione di tipo software) all'elemento B. Si avranno più oggetti candidati a cui aggiungere una nuova categoria.

Un oggetto che crea un elemento non deve avere ne un oggetto già creato, ne ha quel perché utilizza una conoscenza per riferirmento all’oggetto creato, ovvero ha un bisogno forte di conoscere e interagire con esso.

Il creatore alla fine del ragionamento eredita un oggetto A già creato.

INFORMATION EXPERT

Problema: qual è il principio di base per assegnare responsabilità agli oggetti?

Esempio: chi avrà l’oggetto dell’informazione? Chi è il più esperto a conoscere una certa cosa? Problemi generici di progettazione.

Soluzione: si assegna responsabilità alla classe per dotare di informazioni e risolvere uno specifico problema di progettazione, gli esperti delle informazioni possono cambiare dinamicamente.

Un esempio di pattern Information Expert alla sua prima applicazione. Si tratta di: Un sistema di vendita iniziale. Si hanno degli oggetti: Sale, SalesLinettem e Product Description (più esperti parziali delle info). La linea guida dice assegna responsabilità alla classe che ha le informazioni neccessarie per capire o indrettamente tutte le informazioni. In questo caso scelta la classe Sale, creata una nuova classe SalesLinenitem per il calcolo del totale parziale di ciascuna riga di articolo.