Laboratorio di Sistemi Software Design Patterns 1

Transcript

1 TITLE Laboratorio di Sistemi Software Design Patterns 1 Luca Padovani (A-L) Riccardo Solmi (M-Z) 1 Indice degli argomenti Tipi di Design Patterns Creazionali, strutturali, comportamentali Design Patterns Factory Method, Strategy, State, Decorator Composite, Iterator, Visitor Template Method, Abstract Factory, Builder, Singleton Proxy, Adapter, Bridge, Facade Mediator, Observer, Chain of Responsibility Command, Prototype 2

2 Bibliografia UML Linguaggio per modellare un Sistema Software. Design Patterns Elements of Reusable Object-Oriented Software Catalogo di patterns di progettazione Refactoring Improving the Design of Existing Code Catalogo di operazioni di Refactoring Eclipse IDE + UML Plugin Ambiente di programmazione che supporta refactoring e UML. Trovate tutto nelle pagine web relative a questo corso: Ricevimento Metodo 1: il newsgroup Avete a disposizione un newsgroup: unibo.cs.informatica.paradigmiprogrammazione Utilizzatelo il più possibile; se nessuno risponde in due-tre giorni, risponderà uno dei docenti Valuteremo anche la partecipazione al newsgroup Metodo 2: subito dopo le lezioni siamo a vostra disposizione per chiarimenti in aula e alla lavagna, in modo da rispondere a tutti Metodo 3: ricevimento su appuntamento Scrivete a lpadovan@cs.unibo.it (A-L) o a solmi@cs.unibo.it (M-Z) 4

3 Alcuni concetti Incapsulare Racchiudere in modo da mostrare all esterno solo quello che voglio. Gioco su package, classi e visibilità. Delegare Si dice che un metodo delega un altro NB. In Java si può solo inoltrare una chiamata this resta legato all oggetto chiamato. Inoltrare (forwards) Indirezione Ogni volta che prima di fare la cosa richiesta ne faccio un altra (che in genere mi serve per capire come farla). Esempi: delega e codice condizionale 5 Alcuni concetti /2 Staticamente/dinamicamente Dinamicamente significa che si verifica durante l esecuzione (runtime) altrimentiè statico (compile time o initialization time). Statefull/stateless class(object) Con o senza campi. Accoppiato Una classe/interfaccia è accoppiata ad un altra quando contiene un suo riferimento. Esempio: chiamata con parametro di un tipo non primitivo. 6

4 Design Patterns Definizione Un Design Pattern descrive un problema ricorrente di progettazione e uno schema di soluzione per risolverlo. NB Il termine Design nel nome non significa che riguardano solo la progettazione Serve a Progettare e implementare il Software in modo che abbia la flessibilità e le capacità di evolvere desiderate Dominare la complessità di un Sistema Software Catalogo Ogni Design Pattern ha un nome, un campo di applicabilità, uno schema di soluzione e una descrizione delle conseguenze della sua applicazione. 7 Esempi di Design Patterns 8

5 Design Patterns Design Patterns: progettare anticipando i cambiamenti Prima si progetta il Software poi lo si implementa. Massimizzare il riuso (senza ricompilazione) La compatibilità all indietro è spesso un obiettivo. Assumo di poter controllare solo una parte del codice sorgente. Progettare il Sistema in modo da anticipare i nuovi requisiti e i cambiamenti a quelli esistenti. 9 Design Patterns Uso Design Patterns per le esigenze attuali Si riduce enfasi sulla progettazione iniziale Mi basta progettare una soluzione ragionevole non la migliore soluzione. Continuo a chiedermi come evolverà il sistema ma mi basta sapere di poter aggiungere un certo tipo di flessibilità con il Refactoring Incorporare Design nei sorgenti Le scelte progettuali e le dipendenze devono essere il più possibile espresse nei sorgenti I commenti non sono un deodorante per rendere accettabile un codice illeggibile 10

6 Rischi e limiti dei Design Patterns Esistono dei trade -off Non esiste una combinazione di Patterns che mi dà il massimo di flessibilità e di facilità di evolvere. Un Design Pattern facilita alcuni sviluppi futuri a scapito di altri. Cambiare una scelta progettuale è costoso Rischio di sovra-ingegnerizzare Il codice diventa più flessibile e sofisticato di quanto serve. Quando scelgo i Patterns prima di iniziare ad implementare. Quando introduco i Patterns troppo presto. Costo computazionale La flessibilità di una soluzione costa ed è accompagnata da una maggiore complessità. Usare un Design Pattern per esigenze future è un costo 11 Limiti OO evidenziati dai Design Patterns Identità degli oggetti (Object Schizophrenia) Spesso una entità del dominio viene rappresentata da un insieme di classi dell applicazione Problema del significato di this. Incapsulamento dei dati La scomposizione di una entità in più classi mi obbliga a ridurre l incapsulamento dei dati. Rappresentazione indiretta Dato un programma, non è facile stabilire quali Design Pattern sono stati applicati. Parte delle informazioni di progettazione sono perse. 12

7 Dipendenze nel codice Scrivere un programma introduce dipendenze Comprendere le dipendenze che si introducono in modo da scegliere consapevolmente i Design Pattern. Le dipendenze contenute in una classe/interfaccia consistono nell insieme dei riferimenti (statici) ad altre classi/interfacce. I design pattern vengono classificati in base al tipo di dipendenze su cui agiscono in: creazionali, strutturali, comportamentali. Esempi di dipendenze: istanziazione oggetti, campi e metodi, variabili e parametri di tipi non primitivi 13 Design Patterns Creazionali Astraggono il processo di istanziazione Nascondo i costruttori e introduco dei metodi al loro posto Conseguenze: Incapsulano la conoscenza delle classi concrete usate Nascondono il modo in cui le istanze di queste classi vengono create e assemblate Espongono interfacce al posto di tipi concreti 14

8 Design Patterns Strutturali Descrivono come comporre classi e oggetti in strutture più grandi Si dividono in: basati su classi e su oggetti I primi usano l ereditarietà (statica) I secondi la composizione (anche dinamica) Conseguenze Aggiungono un livello di indirezione per disaccoppiare le due interfacce. 15 Design Patterns comportamentali Riguardano algoritmi e l assegnamento di responsabilità tra oggetti Descrivono pattern di comunicazione tra oggetti. Per distribuire il comportamento usano l ereditarietà o la composizione. Conseguenze Alcuni incapsulano il comportamento in modo da poterlo variare anche dinamicamente Disaccoppiano il chiamante e il chiamato aggiungendo un livello di indirezione. 16

9 Factory Method Intent Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. Applicability a class can't anticipate the class of objects it must create. a class wants its subclasses to specify the objects it creates. classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. 17 Factory Method /2 Structure Participants Product (Document) defines the interface of objects the factory method creates. ConcreteProduct (MyDocument) implements the Product interface. Creator (Application) declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object. may call the factory method to create a Product object. ConcreteCreator (MyApplication) overrides the factory method to return an instance of a ConcreteProduct 18

10 FactoryMethod /3 Collaborations Creator relies on its subclasses to define the factory method so that it returns an instance of the appropriate ConcreteProduct. Consequences The code only deals with the interface; therefore it can work with any user-defined concrete classes. Provides hooks for subclasses Connects parallel class hierarchies 19 Factory Method example 1 JComponent 20

11 Factory Method example 2 The code only deals with the interface; therefore it can work wi th any user-defined concrete classes. 21 Factory Method example 3 Connects parallel class hierarchies 22

12 Factory Method questions How does Factory Method promote loosely coupled code? 23 Strategy Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Applicability Many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. You need different variants of an algorithm. An algorithm uses data that clients shouldn't know about. Instead of many conditionals. 24

13 Strategy /2 Structure Participants Strategy declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy. ConcreteStrategy implements the algorithm using the Strategy interface Context is configured with a ConcreteStrategy object. maintains a reference to a Strategy object. may define an interface that lets Strategy access its data 25 Strategy /3 Collaborations Strategy and Context interact to implement the chosen algorithm. A context may pass data or itself to the Strategy. A context forwards requests from its clients to its strategy. Clients usually create and pass a ConcreteStrategy to the context; thereafter, they interact with the context exclusively. Consequences Families of related algorithms. An alternative to subclassing. Vary the algorithm independently of its context even dynamically. Strategies eliminate conditional statements. A choice of implementations (space/time trade-offs). Clients must be aware of different Strategies. Communication overhead between Strategy and Context. Increased number of objects (stateless option). 26

14 Strategy example 1 Sorting Strategy 27 Strategy example 2 To define different algorithms 28

15 Strategy questions What happens when a system has an explosion of Strategy objects? Is there some way to better manage these strategies? Is it possible that the data required by the strategy will not be available from the context's interface? How could you remedy this potential problem? 29 State Intent Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. Applicability An object's behaviordepends on its state, and it must change its behavior at run-time depending on that state. Operations have large, multipartconditionalstatements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditionalstructure. 30

16 State /2 Structure Participants Context defines the interface of interest to clients. maintainsan instance of a ConcreteState subclass that defines the current state. State defines an interface for encapsulatingthe behavior associated with a particular state of the Context. ConcreteState subclasses each subclass implements a behavior associated with a state of the Context. 31 State /3 Collaborations Context delegates state-specific requests to the current ConcreteState object. A context maypass itself as an argument to the State object handling the request. Context is the primary interface for clients. Either Context or the ConcreteState subclasses can decide whichstate succeeds another and under what circumstances. 32

17 State /4 Consequences It localizes state-specific behavior and partitions behavior for different states. It makesstate transitions explicit. State objects can be shared. Implementation Who defines the state transitions? Creating and destroying State objects A table-based alternative 33 State example 1 Queue 34

18 State example 2 Network connection 35 State example 3 Drawing tool 36

19 Decorator or Wrapper Intent Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Applicability to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects. for responsibilities that can be withdrawn. when extension by subclassing is impractical or not allowed 37 Decorator /2 Structure Participants Component defines the interface for objects that can have responsibilities added to them dynamically ConcreteComponent defines an object to which additional responsibilities can be attached Decorator maintainsa reference to a Component object and defines an interface that conformsto Component's interface ConcreteDecorator adds responsibilities to the component 38

20 Decorator /3 Collaborations Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request Consequences More flexibility than static inheritance. Avoids feature-laden classes high up in the hierarchy. A decorator and its component aren t identical. Lots of little objects. Implementation Keeping Component classes lightweight. Changing the skin of an object versus changing its guts. 39 Decorator example 1 String Decorator 40

21 Decorator example 2 To decorate an individual objects 41 Decorator example 3 Adding responsibilities to streams 42

22 Decorator questions Now consider an object A, that is decorated with an object B. Since object B "decorates" object A, object B shares an interface with object A. If some client is then passedan instance of this decoratedobject, and that method attempts to call a method in B that is not part of A's interface, does this mean that the object is no longera Decorator, in the strict sense of the pattern? Furthermore, why is it important that a decoratorobject's interface conforms to the interface of the component it decorates? 43