Marco Faella » 10.Il paradigma Model-View-Controller. Il pattern Strategy

Il paradigma Model-View-Controller

Il paradigma MVC consiste nel distinguere, all’interno di un sistema informatico, tre tipologie di componenti:

• quelle che rappresentano i dati in oggetto (Model);
• quelle che si occupano di presentare i dati all’utente (View);
• e quelle che si occupano dell’interazione con l’utente (Controller).

Tale paradigma trova la sua applicazione principale nei programmi con interfaccia grafica (GUI) e nei sistemi con interfaccia web.
Il paradigma detta la distinzione di responsabilità tra le tre categorie e il flusso di informazioni tra di esse.

Il paradigma Model-View-Controller (segue)

In particolare:

• il modello rappresenta i dati in sé, indipendentemente dal modo in cui questi saranno visualizzati;
• il modello non deve dipendere né dalle viste né dai controller con cui interagirà;
• tuttavia, il modello deve offrire le seguenti funzionalità:
  • per le viste, deve offrire metodi che espongano i dati in sola lettura;
  • per i controller, deve offrire metodi che permettano di modificare i dati in risposta a delle richieste dell’utente;
  • infine, in caso di cambiamento dei dati, deve avvisare le viste, affinché queste possano rispecchiare il cambiamento;
  • quest’ultima funzionalità viene tipicamente realizzata seguendo il pattern OBSERVER, oggetto della lezione precedente.

Il pattern STRATEGY

Il pattern STRATEGY si occupa essenzialmente di quelle situazioni in cui una classe prende una procedura come argomento.
In un linguaggio orientato agli oggetti, questa procedura deve presentarsi sotto forma di oggetto di una apposita classe.

Contesto:

• Una classe (Context) può sfruttare diverse varianti di un algoritmo;
• I clienti della classe vogliono fornire versioni particolari dell’algoritmo.

Soluzione:

• Definire un’interfaccia (Strategy) che rappresenti un’astrazione dell’algoritmo;
• Per fornire una variante dell’algoritmo, un cliente costruisce un oggetto di una classe (ConcreteStrategy) che implementa l’interfaccia Strategy e lo passa alla classe Context;
• Ogni volta che deve eseguire l’algoritmo, la classe Context invoca il corrispondente metodo dell’oggetto che concretizza la strategia.

Applicazione del pattern STRATEGY

Abbiamo già incontrato un esempio di applicazione del pattern STRATEGY: nella scelta del layout di un componente grafico Swing/AWT.
Dalla lezione precedente, ricordiamo che per impostare la disposizione degli elementi grafici all’interno di un contenitore, si utilizza una chiamata del tipo:

contentPane.setLayout(new GridLayout(2,2));

L’oggetto anonimo di tipo GridLayout rappresenta proprio la disposizione che si intende dare a questo pannello: in questo caso, una griglia di due righe e due colonne.
Oltre a GridLayout, la libreria standard fornisce altre classi di layout, come BoxLayout e FlowLayout:

• BoxLayout dispone il contenuto su un’unica riga, o colonna;
• FlowLayout dispone il contenuto su più righe, modificando dinamicamente la disposizione quando il contenitore in questione viene ridimensionato.

Applicazione del pattern STRATEGY (segue)

Tutte le classi di layout implementano l’interfaccia LayoutManager, i cui metodi principali sono i seguenti:

• Dimension minimumLayoutSize(Container parent): restituisce le dimensioni minime richieste da questo layout;
• Dimension preferredLayoutSize(Container parent): restituisce le dimensioni ideali secondo questo layout;
• void layoutContainer(Container parent): dispone gli elementi secondo questo layout.

A questo punto, è facile vedere che siamo in presenza di un’applicazione del pattern Strategy, come evidenziato dalla slide successiva.

Altra applicazione del pattern STRATEGY

Esaminiamo un’altra applicazione di STRATEGY che ritroviamo nella libreria standard.
La classe java.util.Collections contiene alcuni metodi di utilità, tra cui uno che permette di ordinare una lista di oggetti.

static void sort(List l, Comparator c)

Questo metodo ordina la lista l, con il mergesort, utilizzando l’oggetto di tipo Comparator per effettuare i confronti tra gli oggetti presenti nella lista.
Quindi, l’interfaccia Comparator ricopre il ruolo di Strategy e sort è l’algoritmo che la utilizza.

Mini-progetto: studio di funzioni (segue)

Seguire il più possibile il framework MVC ed il pattern Observer.

In questo caso, il framework MVC si coniuga così:

• Model: la funzione;
• View: il suo grafico, o una tabella di valori;
• Controller: le classi che rispondono allo spostamento degli slider e modificano i parametri della funzione.

Progettare l’applicazione in modo che possa funzionare con diverse tipologie di funzioni parametriche.

Mini-progetto: studio di funzioni (segue)

Ad esempio, basare l’applicazione su un’interfaccia che rappresenta una generica funzione parametrica:

Le classi che gestiscono le viste e i controller manipolano generici oggetti di tipo PFunction.
L'applicazione istanzia oggetti (un oggetto?) di tipo Parabola, che è una classe che implementa PFunction.