In base alla decisione suggerita da Controller, il progetto si trova ora al punto mostrato nella figura sotto.

Ovvero che dall'UI arriva la richiesta di giocare una partita (playGame), tale richiesta giunge al controller MonopolyGame, e adesso?

La discussione dettagliata di progetto su che cosa viene dopo applicando i pattern GRASP sarà esaminata successivamente. Ora vale la pena di prendere in considerazione due approcci contrapposti alla progettazione.

Nella figura sopra, sono rappresentate due diagrammi di sequenza differenti, uno a sinistra e uno a destra, separati da una linea leggermente ondulata.

Nella struttura a sinistra, il controller è responsabile di effettuare alcune operazioni, chiamate nel disegno A, B, C. In questo contesto possiamo dire che il controller "fa tutto da solo", senza "farsi aiutare" da altri oggetti/moduli software.

Nella struttura a destra, invece, il controller incarica altri oggetti/moduli di eseguire le stesse operazioni A, B, C.

Ora, in questo caso, le operazioni considerate sono solamente tre, quindi può sembrare non esserci alcuna differenza tra i due schemi di progettazione, ma consideriamo il caso in cui abbiamo due oggetti: Big e Small.
Big ha:

• 100 metodi;
• 2000 linee di codice sorgente (che chiameremo d'ora in poi SLOC: Source Lines Of Code)

Small ha:

• 10 metodi
• 200 SLOC

L'oggetto Big esegue più lavoro dell'oggetto Small. Nel caso in cui i metodi di Big riguardano diverse aree di responsabilità (come l'accesso alla base di dati e la generazione di numeri casuali) possiamo dire che l'oggetto Big non ha un buon focus, non è focalizzato su un compito ben specifico, il che vuol dire che Big non è coeso a livello funzionale, tanto quanto Small.

Per precisare: una coesione cattiva (bassa) non è data solamente dal fatto che un oggetto esegue diversi compiti in autonomia.