Vending Machine Problemi?

Transcript

1 Università degli Studi di Bologna Facoltà di Ingegneria Fondamenti di Informatica T2 Modulo 2 Corso di Laurea in Ingegneria Informatica Anno accademico 2008/2009 Vending Machine Problemi? La riconfigurabilità della vending machine in termini di componenti usati, è solo parziale È possibile riconfigurare i singoli componenti ma NON sostituirli integralmente Al posto di un SimpleKeyboard non ci si può mettere OtherKeyboard: non c è compatibilità di tipo! Adattare la vending machine e ricompilare tutto! 2

2 Vending Machine Problemi? Un cambiamento completo è possibile solo cambiando il codice dei componenti stessi Ancora: adattare la vending machine e ricompilare tutto! Può essere comodo estendere i componenti attuali piuttosto che averne di completamente nuovi Può essere comodo avere componenti veramente intercambiabili Quindi? 3 Vending Machine Soluzioni Occorre trovare il modo per separare completamente i concetti dalle loro implementazioni Occorre separare la vista esterna dal come è fatto Occorre stabilire un contratto di funzionamento che deve essere rispettato da tutti i componenti che vogliono entrare in gioco Interfacce! 4

3 Astrazione, come!? Tramite interfacce, si definiscono i servizi che ogni componente fornisce Chiunque voglia realizzare un nuovo componente deve implementare l interfaccia corrispondente Naturalmente, dal punto di vista di chi usa l interfaccia (la vending machine il coordinamento), il comportamento deve essere equivalente 5 Comportamento Equivalente Per comportamento equivalente si intende che, a livello di componente, esistono degli invarianti semantici che vanno rispettati Si prenda a riferimento il caso della tastiera (SimpleKeyboard nel vecchio progetto) se si stabilisce che il comportamento del metodo di lettura del componente debba essere bloccante e sincrono (rimane in attesa che sia disponibile un risultato), tutti i componenti dello stesso tipo (che realizzano una tastiera) devono comportarsi nello stesso modo se così non fosse, la vending machine, che suppone un comportamento di quel tipo, non potrebbe più funzionare! 6

4 Soluzione? Partendo dall attuale Vending Machine, quali passi occorre compiere? Ricordare quali azioni/passi sono stati compiuti durante l estensione del Phone Plan con le Opzioni 7 Soluzione Passo 1 Da ogni componente, estrarre l interfaccia (interface) Fare in modo che ogni componente implementi l interfaccia da esso estratta (implements) Fare in modo che il coordinatore del funzionamento (VendingMachine) non usi più riferimenti ad oggetti concreti, ma riferimenti ad interfacce 8

5 Package? Come organizzare i package? Occorre fare in modo che Le classi siano organizzate con dipendenze sensate (astrazioni vs entità concrete) COME?! L estensione (aggiunta di funzionalità/dispositivi) sia semplice COME?! Mettere tutto insieme? Vantaggi, Svantaggi? 9 Package Passo 1 vendingmachine: è il root package contiene classi di uso generale La classe che contiene il main vendingmachine.devices: contiene le definizioni delle interfacce dei dispositivi componenti vendingmachine.devices.standard: contiene le classi che implementano i dispositivi per usare lo standard input e lo standard output per l I/O 10

6 Renaming Le interfacce prendono il nome del dispositivo: Display, Keyboard, CoinScanner, CashRegister, Dispenser Le classi che realizzano le interfacce prendono un nome opportuno con suffisso il nome dell interfaccia (non è sempre vero, dipende dal contesto v. interfacce general purpose come Comparable) 11 Naming In generale Distinguere fra le interfacce che esprimono un abilità (Comparable, Serializable, Iterable ) In questo caso non ha senso includere nel nome della classe che implementa l interfaccia anche il nome dell interfaccia stessa Un Dispenser può essere Comparable ma è pur sempre un Dispenser dalle interfacce che modellano un entità (CoinScanner, Dispenser ) In questo caso, la classe che implementa l interfaccia, realizza l entità, di conseguenza il naming: GraphicalCoinScanner, StandardDispenser, 12

7 Package Diagram Passo 1 13 Class Diagram Passo 1 14

8 Problemi Passo 1 Il diagramma è decisamente troppo connesso In particolare, il main ha troppe responsabilità: creazione, configurazione, esecuzione In generale, occorrerebbe un sistema di creazione e configurazione che fosse flessibile e riusabile Flessibile: configurare diverse vending machine con diversi TIPI di componenti Riusabile: configurare diversi TIPI di vending machine con diversi TIPI di componenti 15 1 Soluzioni configurare diverse vending machine con diversi TIPI di componenti Necessità di una factory FATTA COME? Serve qualcosa di più flessibile rispetto alle factory viste finora 2 configurare diversi TIPI di vending machine con diversi TIPI di componenti Anche VendingMachine deve essere astratta da un interfaccia! 16

9 Soluzioni 1. La creazione dei componenti e la loro configurazione può essere fatta dalla stessa factory che crea VendingMachine a. Le configurazioni possono essere diverse a seconda delle situazioni b. Una factory per configurazione Anche la factory deve essere in qualche modo astratta (interfaccia!) c. Gerarchia di factory d. e la factory della factory? 2. Le vending machine possono essere di tipo diverso a. VendingMachine viene astratta da un interfaccia b. La factory restituisce un oggetto che realizza tale interfaccia 17 Renaming L interfaccia che rappresenta la vending machine, si chiama VendingMachine Le classi che la implementano prendono un nome opportuno con suffisso il nome dell interfaccia (v. precedente considerazione) Nello specifico, la vending machine sequenziale (operazioni solo in ordine preciso) è realizzata dalla classe SequentialVendingMachine e implementa l interfaccia VendingMachine 18

10 La Factory di VendingMachine VendingMachineFactory occupa della creazione di una VendingMachine Quale e come sia configurata lo sa solo la factory! Le uniche dipendenze evidenti sono quelle con le astrazioni Un metodo protetto per ogni dispositivo da creare. La factory si occupa anche della configurazione! 19 Package Passo 2 vendingmachine.control.factories: contiene la (le?) factory concreta della vending machine vendingmachine.control contiene anche l interfaccia VendingMachine 20

11 Package Passo 2 La costruzione di vending machine e dispositivi delegata alla factory 21 Codice Astrazioni package vendingmachine.control; public interface VendingMachine public void run(); 22

12 Codice Astrazioni package vendingmachine.devices; public interface CashRegister public int getcurrentbalance(); public void acceptcredit(int amountin); public int getcredit(); public boolean candotransaction(int cost); public boolean dotransaction(int cost); public void abort(); 23 Codice Astrazioni package vendingmachine.devices; public interface CoinScanner public InputType acceptinput(); public int getlastcoin(); public InputType getlastinputtype(); 24

13 Codice Astrazioni package vendingmachine.devices; public interface Dispenser public int getcode(); public int getcount(); public int getproductcost(); public String getproductname(); public boolean makesale(); 25 Codice Astrazioni package vendingmachine.devices; public interface Display public void show(string s); public void clear(); 26

14 Codice Astrazioni package vendingmachine.devices; public interface Keyboard public int readvalue(); 27 La creazione Come è fatta la factory di vending machine? È una classe contenente soli metodi statici Contiene un metodo pubblico che restituisce una VendingMachine Contiene tanti metodi protetti quanti sono i dispositivi da creare Realizza una costruzione per passi: Costruzione e configurazione dei componenti Costruzione e configurazione della vending machine 28

15 Quale vending machine? VendingMachine è ora un interfaccia SequentialVendingMachine è la vending machine sequenziale La VendingMachineFactory è scritta in modo che venga restituita una SequentialVendingMachine con i componenti di tipo standard che utilizzano la console. 29 VendingMachineFactory package vendingmachine.control.factories; public class VendingMachineFactory public static VendingMachine createvendingmachine() Dispenser[] dispensers = createdispensers(); CashRegister cashregister = createcashregister(); Display display = createdisplay(); Keyboard keyboard = createkeyboard(); CoinScanner coinscanner = createcoinscanner(); return new SequentialVendingMachine(dispensers, cashregister, display, keyboard, coinscanner); 30

16 VendingMachineFactory protected static CashRegister createcashregister() return new StandardCashRegister(); protected static CoinScanner createcoinscanner() return new StandardCoinScanner( new int[] 5, 10, 20, 50, 100 ); 31 VendingMachineFactory protected static Dispenser[] createdispensers() return new Dispenser[] new StandardDispenser(11, 20, 50, "A-Candy"), new StandardDispenser(12, 10, 100, "Mr Bon"), new StandardDispenser(13, 2, 10, "Sugar Fuel"), new StandardDispenser(21, 30, 80, "Gluco Abuse"), new StandardDispenser(22, 20, 60, "Hall of Taste") ; 32

17 VendingMachineFactory protected static Display createdisplay() return new StandardDisplay(); protected static KeyBoard createkeyboard() return new StandardKeyBoard(); 33 Componenti Grafici? Supponiamo entrino in gioco dei componenti grafici funzionalmente equivalenti a quelli standard Dove va cambiata la factory? 34

18 VendingMachineFactory protected static CoinScanner createcoinscanner() return new GraphicCoinScanner( new int[] 5, 10, 20, 50, 100 ); protected static Display createdisplay() return new GraphicDisplay(); protected static Keyboard createkeyboard() return new GraphicKeyboard(); 35 Il diavolo sta nei dettagli Si supponga di inventare un nuovo tipo di vending machine che funzioni ad eventi piuttosto che in maniera sequenziale (EventsVendingMachine) come si colloca rispetto al resto del mondo? I componenti adatti alla macchina sequenziale (quelli studiati finora), sono anche adatti alla macchina ad eventi? Per la sola configurazione dei dispenser per una certa vending machine, deve essere per forza necessario cambiare il codice della factory? Per supportare la configurazione, come deve cambiare la factory? 36

19 Morale della favola Meccanismi Interfacce e classi astratte Ereditarietà e polimorfismo Sostituibilità in generale Package 37 Politiche Pratiche Morale della favola L interfaccia è l astrazione di più alto livello: in generale, è bene astrarre le entità riusabili tramite un interfaccia, concentrare la creazione in una factory e fare in modo che quest ultima sia l unica a dipendere dalle classi concrete piuttosto che sparpagliare creazioni e dipendenze per tutto il sistema Organizzazione dei package, in generale: Insieme le astrazioni correlate (dispositivi astratti, vending machine, ) Insieme le classi correlate (dispositivi concreti di un certo tipo) Suddividere in ulteriori package quando la complessità aumenta USARE IL BUON SENSO! 38