Concetto di responsabilità nella progettazione guidata dalle responsabilità (RRD) si pensa in termini di responsabilità del software. Le responsabilità vengono assegnate agli oggetti durante la progettazione. Due tipi di responsabilità: r. di fare: (le stabilisco dal modello di dominio) fare cioè creare un oggetto o eseguire un calcolo dare inizio ad un'azione in altri oggetti controllare e coordinare le attività di altri oggetti r. di conoscere: (le stabilisco nell'ssd, nei contratti o nei Casi d'uso) conoscere i propri dati privati conoscere oggetti correlati conoscere cose che può derivare o calcolare RRD: porta a considerare un progetto OO come una comunità di oggetti sw con responsabilità che collaborano Pattern Grasp: codificano criteri per l'assegnazione di responsabilità di base: Creator, Information Expert, Low Coupling, High Coesion, Controller altri: Polymorphism, Pure Fabrication, Indirection, Protected Variations i pattern di base guidano all'assegnazione di responsabilità a oggetti sw ispirati al modello di dominio scopo è sostenere un salto rappresentazionale basso salto rappresentazionale è distanza tra modello mentale del dominio e la rappresentazione del dominio mediante SW. LRG (Low Representational Gap): assegno responsabilità basandomi sul modello mentale di dominio importante è la comprensibilità del codice perchè ciò sostiene la modificabilità durante l'ood il disegno di un diagramma UML mostra le scelte fatte nell'assegnazione di responsabilità e non viceversa cos'è un pattern? Nome problema risolto soluzione Pattern Grasp di base: Creator Chi crea un oggetto A? Assegna alle classe B la responsabilità di creare un'istanza della classe A se: B contiene o aggrega con una composizione oggetti di tipo A B registra A B utilizza strettamente A B possiede i dati per l'inizializzazione di A Attenzione: B e A sono oggetti software. Prima si cercano oggetti SW in grado di soddisfare questo ruolo, ma se non sono state ancora definite classi SW bisogna trarre spunto dal modello di dominio. Information Expert qual'è un principio base per assegnare responsabilità agli oggetti? Assegna una responsabilità alla classe che possiede informazioni necessarie per soddisfarla Se un oggetto A aggrega oggetti B allora avrà informazioni su di loro
Expert è utile, ce lo spiega il Low Coupling : l'accoppiamento è la misura di quanto un elemento è connesso agli altri, li conosce o dipende da essi. Quando c'è accoppiamento e avviene una modifica questa può ripercuotersi sull'oggetto accoppiato. Low Coupling Come ridurre l'impatto dei cambiamenti? Assegna le responsabilità in modo tale che l'accoppiamento non necessario rimanga basso. Utile per valutare alternative. Il low coupling tende a ridurre il tempo, i costi e i difetti nella modifica del Software. Non usare I.E. Aumenta l'accoppiamento e quindi viola il Low Coupling. In base al principio di separazione Modello-Vista si sa che gli oggetti della UI non devono contenere logica applicativa quindi devono delegare la richiesta a oggetti dello strato di dominio. Controller Qual'è il primo oggetto oltre lo stato UI a ricevere e coordinare un'operazione di sistema? Assegna le responsabilità a un oggetto che rappresenta una delle seguenti scelte rappresenta il sistema complessivo, un oggetto radice, un dispositivo all'interno del quale viene eseguito il software o un sottosistema principale rappresenta uno scenario di un caso d'uso all'interno del quale si verifica l'operazione di sistema Coesione: misura quanto sono correlate le operazioni di un elemento SW da un punto di vista funzionale e misura anche quanto lavoro sta eseguendo un elemento SW. Quindi è sbagliato far eseguire tutto il lavoro ad un oggetto anziché delegare e distribuire lavoro agli oggetti High Coesion come mantenere gli oggetti focalizzati, comprensibili e gestibili e, con effetto collaterale sostenere il Low Coupling? Assegna le responsabilità in modo tale che la coesione rimanga alta. Usa questo principio per valutare le alternative. Polimorfismo come gestire alternative basate sul tipo? Come creare componenti SW inseribili? Alternative basate sul tipo se progetto usando la logica delle istruzioni condizionali (if-then-else o case) nel caso in cui si presenti una variazione, dovrò modificare la logica condizionale. Componenti SW inseribili considerando i componenti in una relazione client-server, come è possibile sostituire un componente server con un altro senza ripercussioni sul client?
Esempio: Problema NextGen (sistema POS) in questa applicazione devono essere supportati diversi calcolatori. Quali oggetti devono essere responsabili della gestione delle interfacce che servono per comunicare con questi 3 diversi apparecchi per calcolare le imposte? La responsabilità dell'adattamento deve essere assegnata a diversi oggetti calcolatore (*) implementando la responsabilità con un operazione gettaxes polimorfa (*): questi oggetti sono oggetti sw locali che rappresentano calcolatori esterni. Le richieste vengono girate al calcolatore esterno nella sua API nativa Usa operazioni polimorfe (dai stesso nome a servizi in oggetti diversi quando essi sono correlati) Un modo per risolvere il problema dei comportamenti che variano col tipo si può adottare la tecnica dell' abstract. Ad esempio nel Monopoly il comportamento cambia in base alla casella sulla quale si finisce. Ma non conviene fare il case relativo al comportamento da attuare. La soluzione migliore è implementare una classe Square {abstract} e le diverse caselle che la implementano. Il metodo landedon sarà astratto e implementato in modo diverso da ogni casella. Nei diagrammi di interazione chi invia il messaggio landedon alla casella su cui finisce il giocatore? Sarà proprio il Player (per Low Coupling e I.E.) che già conosce la casella sulla quale si trova. Pure Fabrication quale oggetto deve avere la responsabilità quando non si vogliono violare High Coesion e Low Coupling, o altri obiettivi, ma le soluzioni suggerite da Expert (per esempio) non sono appropriate? I progetti orientati agli oggetti sono talvolta caratterizzati dall'implementare, come classi SW, delle rappresentazioni dei concetti del dominio del mondo reale per abbassare il salto rappresentazionale. Tuttavia ci sono molte situazioni in cui l'assegnare responsabilità solo a classi SW dello strato del dominio provoca
problemi in termini di coesione o accoppiamento mediocri, o basso potenziale di riuso. Assegna un insieme altamente coeso di responsabilità a una classe artificiale che non rappresenta un concetto del dominio del problema, ma è qualcosa di inventato. Indirection dove assegnare una responsabilità, per evitare l'accoppiamento diretto tra due elementi? Come disaccoppiare elementi in modo da sostenere low coupling e avere alto potenziale di riuso? Assegna la responsabilità a un oggetto intermediario Protected variation come progettare oggetti, sottosistemi e sistemi in modo tale che le variazioni o l'instabilità in questi elementi non abbiano un impatto indesiderato su altri elementi? Identifica i punti in cui sono previste variazioni o instabilità; assegna delle responsabilità per creare attorno ad essi un'interfaccia stabile Visibilità: capacità di un oggetto di vedere o avere un riferimento ad un altro oggetto visibilità per attributo: B è attributo di A visibilità per parametro: B è un parametro di un metodo di A visibilità locale: B è un oggetto locale in un metodo di A si ottiene creando una nuova istanza locale e assegnandola a una variabile locale oppure assegnando l'oggetto che viene restituito da un'invocazione di metodo a una variabile locale visibilità globale: B è in qualche modo visibile globalmente Raffinamento modello di Dominio elenco di categorie di classi concettuali: oggetti fisici o tangibili transazioni altri sistemi informatici o elettromeccanici esterni al sistema concetti con nomi astratti organizzazioni registrazione di questioni finanziarie, di lavoro, contrattuali e legali Generalizzazione E' possibile organizzare concetti simili in una gerarchia di generalizzazionespecializzazione di classi in cui la superclasse rappresenta un concetto generale, mentre le sottoclassi rappresentano concetti più specializzati regola del 100% il 100% delle definizioni della superclasse concettuale devono essere applicabili alla
Nel Includere dominio il nome POS del ad esempio Pattern nella un Payment creazione può è effettivamente dell'oggetto avere 2 diversi che membro esso stati: esplicita. autorizzato di una sottoclasse. Ad esempio non autorizzato. Quindi nel creare è una classe un Ma oggetto essi concettuale non adattatore sono sottoclassi astratta. usare il del termine Payment, Adapter. bensì del PaymentState sottoclasse. La sottoclasse deve essere conforme al 100% per gli attributi e per le associazioni regola Is-a tutti i membri dell'insieme di una sottoclasse devono essere membri dell'insieme della relativa superclasse. Quando definire una sottoclasse una partizione di una classe concettuale è una divisione di una classe concettuale in sottoclassi disgiunte crearla quando: la sottoclasse ha attributi aggiuntivi di interesse la sottoclasse ha associazioni aggiuntivi di interesse il concetto della sottoclasse viene fatto funzionare, viene gestito, reagisce o viene manipolato in modo diverso dalla superclasse o dalle altre sottoclassi il concetto della sottoclasse rappresenta qualcosa di animato che si comporta in modo diverso dalla superclasse Classi concettuali astratte se ciascun membro di una classe C deve essere anche un membro di una sottoclasse C, la classe C è detta una classe concettuale astratta modellare stati che cambiano non modellare gli stati di un concetto X come sottoclassi di X definire una gerarchia di stati e associare gli stati a X Design Pattern Gang-of-Four (GoF) Adapter come gestire interfacce incompatibili, o fornire un'interfaccia stabile a componenti simili con interfacce diverse? Converti l'interfaccia originale di un componente in un'altra interfaccia, attraverso un oggetto adattatore intermedio in questo modo classi diverse possono operare insieme quando ciò non sarebbe altrimenti possibile
Chi Ad Mi ricollego esempio crea la factory nel al caso sistema e del come POS: vi con si accede? il ITaxCalculatorAdapter: Intanto va detto che con ne serve questa una interfaccia, sola istanza. usando Per quanto il polimorfismo riguarda nel la sistema visibilità ottengo di il determinazione la problema protezione si risolve nel del sistema prezzo grazie in si al modo creando pattern che Singleton diverse pur variando classi SalePricingStrategy i sistemi con i quali l'applicazione ciascuna si interfaccia, con un metodo il nocciolo polimorfo del gettotal codice passando rimane lo per stesso parametro la Sale il metodo verrà implementato diversamente a seconda del tipo di sconto da effettuare un oggetto strategia è associato a un oggetto contesto. In questo caso l'oggetto di contesto è la Sale quando viene inviato il messaggio gettotal ad una Sale esso delega parte della lavoro al suo oggetto strategia è importante che l'oggetto strategia veda per parametro l'oggetto contesto Chi crea un oggetto Strategy? Si può applicare il pattern Factory usando una Factory specifica in modo da sostenere High Coesion Factory chi deve essere responsabile della creazione di oggetti quando ci sono delle considerazioni speciali, come una logica di creazione complessa, quando si desidera separare le responsabilità di creazione per una coesione migliore, e così via crea un oggetto Pure Fabrication chiamato Factory che gestisce la creazione lo scopo è di fornire un'interfaccia per la creazione di un oggetto senza specificare quale sia la sua classe concreta Singleton è consentita esattamente una sola istanza di una classe, ovvero un singleton. Gli oggetti hanno bisogno di un punto di accesso globale e singolo definisci un metodo statico della classe che restituisce il singleton Proxy l'accesso diretto a un componente è spesso inappropriato per motivi di accoppiamento, efficienza, sicurezza... il client viene fatto comunicare con un rappresentante del componente, il proxy il proxy non fa solo da intermediario, ma esegue delle ulteriori pre e post elaborazioni Strategy come progettare per gestire un insieme di algoritmi o politiche variabili ma correlati? Come progettare per consentire di modificare questi algoritmi o politiche? Definisci ciascun algoritmo/politica/strategia in una classe separata, con un'interfaccia comune Facade è richiesta un'interfaccia comune e unificata per un insieme disparato di implementazioni
o interfacce, come per definire un sottosistema. Può verificarsi un accoppiamento indesiderato a molti oggetti nel sottosistema, oppure l'implementazione del sottosistema può cambiare. Definisce un punto di contatto singolo con il sottosistema, ovvero un oggetto Facade che copre il sottosistema. Questo oggetto Facade presenta un'interfaccia singola e unificata ed è responsabile della collaborazione con i componenti del sottosistema. Observer diversi tipi di oggetti subsciber (abbonato) sono interessati ai cambiamenti di stato o agli eventi di un oggetto publisher (editore) ciascun subscriber vuole reagire in un modo proprio quando un publisher genera un evento il publisher vuole mantenere un accoppiamento basso verso i suoi subscriber definisci un interfaccia subscriber o listener i subscriber implementano questa interfaccia il publisher può registrare dinamicamente i subscriber che sono interessati ai suoi eventi e avvisarli quando si verifica un evento quindi un oggetto pubblica eventi zero o più oggetti possono abbonarsi agli eventi pubblicati da un oggetto (con una registrazione)