41
Programmazione a Oggetti Modulo B Lezione 6 Dott. Alessandro Roncato 10/11/2011

Programmazione a Oggetti Modulo B - dsi.unive.itpo/2011/SlidesB/Lezione6.pdfLezione 6 Dott. Alessandro Roncato 10/11/2011. Riassunto • Pure Fabrication • Simple Factory • Abstract

Embed Size (px)

Citation preview

Programmazione a OggettiModulo B

Lezione 6

Dott. Alessandro Roncato

10/11/2011

Riassunto

• Pure Fabrication• Simple Factory• Abstract Factory• Protect Variations• Reflection

Dall'idea al codice

• Brainstorming• Separare oggetti da azioni• Oggetti => Concetti• Azioni => Casi d'uso• (Casi d'uso => Prototipo)• Diagramma Classi• Diagramma di sequenza• Implementazione

Brainstorming

• Buttare giù le idee così come vengono riguardo all'applicazione che stiamo studiando.

Separare oggetti da azioni

Oggetti• Negozio• Prodotto• Alimentare• Scontrino• Elettrodomestico• Magazzino• ...

Azioni• Pagare• Comprare• Cercare• Inserire• ...

Scadenza

Oggetti=>Classi

• Prodotto: codice, prezzo, collocazione ...• Negozio: nome, …• Scontrino: totale, elenco prodotti,...• Magazzino: scaffali

Azione => Casi d'uso

• Comprare: nell'applicazione quali ruoli degli utenti possono fare questa operazione

• Cercare: chi, cosa e come può ricercare?• Comprare: chi gestisce questa funzionalità (cassiere

o cliente?)• Inserire: Prodotti, Lotti etc.

Casi d'uso

• Come l'utente interagisce con l'applicazione.• Rappresentano la cosa più importante che

l'utente “vede” dell'applicazione.• Nel caso del nostro progetto ci dicono quali

sono le funzionalità che l'utente può usare

Casi d'uso

• Di solito si disegna il diagramma dei casi d'uso.• Ripetiamo: i casi d'uso devono essere tutte e

le sole interazioni dell'utente con l'applicazione

User Friendly?

Prototipo Applicazione

• Aiuta a capire se i casi d'uso esaudiscono tutti i desideri dell'utente.

• E' una delle cose più importanti

Diagramma classi

Parziale, completare

Diagramma delle classi

Prodotto

-codice: String-prezzo: double-collocazione: Scaffale

+getCodice(): String+getCollocazione(): Scaffale+ritorna(): boolean

Diagrammi di sequenza

• Un diagramma di sequenza aiuta a capire come gli oggetti collaborano per implementare un singolo caso d'uso

• Molto spesso può accadere che un caso d'uso semplice non abbia bisogno di un diagramma di sequenza

• Può anche accadere che un caso d'uso abbia bisogno di più diagrammi di sequenza (es. se ci sono molte condizioni)

DS Caso d'uso Storna Scontrino

Diagrammi di sequenza

• Fate tutti i diagrammi di sequenza• I diagrammi di sequenza potrebbero

richiedere modifiche al diagramma delle classi• Modifiche al diagramma delle classi,

potrebbero richiedere modifiche ai diagrammi di sequenza

Implementazione

• L'implementazione segue quasi direttamente dai diagrammi delle classi e di sequenza

• Dal diagramma delle classi completo è possibile produrre in automatico le “interfacce” delle classi. Cioè esistono dei Tool che dal diagramma generano codice Java con gli attributi e le firme dei metodi.

Da che oggetto iniziare?

D: di che oggetto è il primo metodo chiamato?R: gli oggetti sono “passivi” e quindi ci vuole “qualcuno” che invoca i loro metodiNelle applicazioni a riga di comando, c'è il metodo statico main che inizia la computazioneNelle applicazioni a finestre o Web?

Controller

D: Qual è il primo oggetto (oltre lo strato delle librerie di sistema) a ricevere e coordinare un'operazione di sistemaR: ad un oggetto di invenzione che:1) rappresenta il sistema2) rappresenta uno scenario di un singolo caso d'uso

Opzioni

• Caso 1 (Sistema) ha senso se ci sono poche operazioni di sistema

• Caso 2 ha senso se ci sono molte operazioni di sistema– Ci sono due versioni:

1) controller di caso d'uso: lo stesso oggetto gestisce un solo caso d'uso di tutti gli utenti <casoduso>Handler2) controller di sessione: ogni attore ha il suo oggetto controller (autenticazione)<casoduso>Session

Controller

• Il controller si occupa di collegare le nostre classi del modello con il resto dell'applicazione.

• Per le applicazioni con interfaccia grafica e Web esiste uno “strato” software che gestisce (per il programmatore) gli aspetti di interazione con l'utente e/o mondo esterno

Cos'è il Modello?

• In generale tutte le classi che hanno a che fare con il campo di utilizzo dell'applicazione e che NON dipendono dal tipo di interazione dell'applicazione (cioè Applicazione Web, con interfaccia grafica, a linea di comando)

• Esempio del Negozio: tutte le classi viste: Prodotto, Scontrino, Scaffale, etc.

Controller e basta?• Il Controller risponde ai comandi dell'utente,

ma i comandi vengono visualizzati su una interfaccia grafica.

• Chi si occupa della visualizzazione dell'interfaccia grafica?

• Nelle applicazioni a linea di comando, non è un grosso problema in quanto la visualizzazione si riduce a dei print e quindi può essere fatta dal main.

Model View Controller

D: come evitare di duplicare codice in base alle differenti modalità di presentazione (visualizzazione)Esempio:Gli stessi dati devo essere usati via Web, applicazione stand alone e tramite servizi esportazione/importazione (XML?)

MVC

• Si separano:1) Modello2) Logica di presentazione (View)3) Logica di controllo (Controller)

Questo permette a “viste” diverse di utilizzare lo stesso modelloIl modello è indipendente da V e C!

Indipendenza?

ControllerView

• Sia indipendenza concettuale che indipendenza con la definizione che abbiamo già dato: il Modello non usa oggetti della View e del Controller

Model

Invia ComandiLegge Stato

Seleziona Vista

Aggiornamento

D: come informare la View dei cambiamenti del Modello senza creare una dipendenza del modello dalla Vista?

ControllerView

Model

Esempio

• Come fare in modo che un cambiamento dello stato del Modello visualizzato sulla “finestra” dell'applicazione?

• Se il modello richiama un metodo della View per “comunicare” il cambio di stato si crea una dipendenza del modello dalla View.

Esempio codicepublic class Prodotto { ScadutoJComponent jScaduto; ... public boolean isScaduto(){ ... if (scaduto){ jScaduto.setScaduto(true); jScaduto.invalidate(); } return scaduto;

}

Esempio codicepublic class ScadutoJComponent extends JComponent { boolean scaduto; public void setScaduto(boolean v){ scaduto=v;} public void paintComponent(Graphics g){ Graphics2D g2= (Graphics2D)g; if (scaduto) g2.drawString(“scaduto”,50,100); }}

View Controller

Model

Svantaggi

• Abbiamo detto che non ci preoccupano le dipendenze con le classi delle librerie standard. Però in questo caso non vogliamo dipendere da JComponent perché in un'applicazione a linea di comando o in un'applicazione Web non è disponibile JComponent e quindi non sarebbe possibile riusare la classe Prodotto.

Alternativa

Fare in modo che sia il controller a gestire tutto:• Bassa coesione• Complessità codice• Funziona solo se il controller conosce

esattamente quando il modello cambia stato

Esempio alternativapublic class Controller { ScadutoJComponent jComponent; Prodotto prodotto=...; … public void doAction(){ … jComponent.setScaduto(prodotto.isScaduto()); jComponent.invalidate();

}} View Controller

Model

Pattern Observer

• Uno o più oggetti (detti Subscribers) sono interessati agli eventi (o cambi di stato) di un altro oggetto (detto Publisher).

• Il Publisher vuole essere quanto più indipendente dai Subscribers

Pattern Observer

Soluzione:1) si definisce un'interfaccia Listener2) i Subscriber implementano Listener3) il Publisher registra dinamicamente i subscribers 4) il Publisher avvisa i Subscribers registrati quando si verifica l'evento

Diagramma

View Controller

Model

Listener

<<implements>>

Observer in Java

• Già definite varie interfacce Listener (a seconda del tipo di evento che si vuole “ascoltare”)

• Già definite e implementate varie classi di supporto (ChangeSupport) per implementarle

• Stabile

Diagramma in Java

View Controller

Model

Listener

<<implements>>

Support

Esempiopublic class Prodotto { private PropertyChangeSupport listeners = new PropertyChangeSupport(this); … public void addPropertyChangeListener(PropertyChangeListener l){ listners.addPropertyChangeListener(l); } public void removePropertyChangeListener(PropertyChangeListener l){ listeners.removePropertyChangeListener(l); } public boolean isScaduto(){ ... listeners.firePropertyChange(“scaduto”,oldValue,value); }}

Esempiopublic class ProdottoJComponent extends JComponent implements PropertyChangeListner{ boolean scaduto; … public propertyChange(PropertyChangeEvent evt){ scaduto=evt.getNewValue(); invalidate(); } public void paintComponent(Graphics g){ Graphics2D g2= (Graphics2D)g; if(scaduto) (g2.drawString(“Scaduto”,50,100); }}

Esempiopublic class Controller { PrestitoJComponent jComponent; Prodotto prodotto=...;

public Controller(){ prodotto.addPropertyChangeListener(jComponent); } …}

Diagramma parziale

Controller Prodotto Support Listener

isScaduto()firePropertyChange

*propertyChange

Event

getNewValue

invalidate