TITLE
Laboratorio di Sistemi Software
Design Patterns 2
Luca Padovani (A-L)
Riccardo Solmi (M-Z)
© 2002-2003 Luca Padovani, Riccardo Solmi
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
© 2002-2003 Luca Padovani, Riccardo Solmi
2
1
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:
• http://www.cs.unibo.it/~solmi/teaching/labss_2002-2003.html
• http://www.cs.unibo.it/~lpadovan/didattica.html
© 2002-2003 Luca Padovani, Riccardo Solmi
3
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 [email protected] (A-L)
o a [email protected] (M-Z)
© 2002-2003 Luca Padovani, Riccardo Solmi
4
2
Composite
§ Intent
• Compose objects into tree structures to represent part-whole
hierarchies. Composite lets clients treat individual objects and
compositions of objects uniformly
§ Applicability
• you want to represent part-whole hierarchies of objects.
• you want clients to be able to ignore the difference between
compositions of objects and individual objects. Clients will
treat all objects in the composite structure uniformly
5
© 2002-2003 Luca Padovani, Riccardo Solmi
Composite /2
§
Structure
§
Participants
§
Component
•
declares the interface for objects in the
composition.
•
implements default behavior for the
interface common to all classes.
•
declares an interface for accessing and
managing its child components.
•
(optional) defines an interface for
accessing a component's parent in the
recursive structure, and implements it if
that's appropriate.
•
Leaf
• represents leaf objects in the composition.
• defines behavior for primitive objects
•
Composite
• defines behavior for components having children.
• stores child components.
• Implements child-related operations in the
Component interface.
•
Client
• manipulates objects in the composition through
the Component interface.
© 2002-2003 Luca Padovani, Riccardo Solmi
6
3
Composite /3
§ Collaborations
•
Clients use the Component class interface to interact with objects in the
composite structure. If the recipient is a Leaf, then the request is handled
directly. If the recipient is a Composite, then it usually forwa rds requests
to its child components, possibly performing additional operations
before and/or after forwarding.
§ Consequences
• defines class hierarchies consisting of primitive objects and
composite objects
• makes the client simple
• makes it easier to add new kinds of components
• can make your design overly general
© 2002-2003 Luca Padovani, Riccardo Solmi
7
Composite example 1
© 2002-2003 Luca Padovani, Riccardo Solmi
8
4
Composite example 2
§
Graphics applications like drawing editors and schematic capture systems
let users build complex diagrams out of simple components
© 2002-2003 Luca Padovani, Riccardo Solmi
9
Composite Questions
§ Part 1: How does the Composite pattern help to consolidate
system-wide conditional logic?
§ Part 2: Would you use the composite pattern if you did not
have a part-whole hierarchy? In other words, if only a few
objects have children and almost everything else in your
collection is a leaf (a leaf can have no children), would you
still use the composite pattern to model these objects?
© 2002-2003 Luca Padovani, Riccardo Solmi
10
5
Iterator
§ Intent
• Provide a way to access the elements of an aggregate object
sequentially without exposing its underlying representation
§ Applicability
• to access an aggregate object's contents without exposing its
internal representation.
• to support multiple traversals of aggregate objects.
• to provide a uniform interface for traversing different
aggregate structures (that is, to support polymorphic
iteration).
11
© 2002-2003 Luca Padovani, Riccardo Solmi
Iterator /2
§
§
Structure
Participants
•
Iterator
•
• defines an interface for accessing and
traversing elements.
•
ConcreteIterator
• implements the Iterator interface.
• keeps track of the current position in the
traversal of the aggregate.
© 2002-2003 Luca Padovani, Riccardo Solmi
Aggregate
• defines an interface for creating an
Iterator object.
•
ConcreteAggregate
• implements the Iterator creation
interface to return an instance of the
proper ConcreteIterator.
12
6
Iterator /3
§ Collaborations
• A ConcreteIterator keeps track of the current object in the
aggregate and can compute the succeeding object in the
traversal
§ Consequences
• It supports variations in the traversal of an aggregate
• Iterators simplify the Aggregate interface
• More than one traversal can be pending on an aggregate
© 2002-2003 Luca Padovani, Riccardo Solmi
13
Iterator example 1
© 2002-2003 Luca Padovani, Riccardo Solmi
14
7
Iterator example 2
§
An aggregate object such as a list should give you a way to access its
elements without exposing its internal structure
© 2002-2003 Luca Padovani, Riccardo Solmi
15
Iterator questions
§ Consider a composite that contains loan objects. The loan
object interface contains a method called
"AmountOfLoan()", which returns the current market value
of a loan. Given a requirement to extract all loans above,
below or in between a certain amount, would you write or
use an Iterator to do this?
© 2002-2003 Luca Padovani, Riccardo Solmi
16
8
Visitor
§ Intent
•
Represent an operation to be performed on the elements of an object
structure. Visitor lets you define a new operation without changing the
classes of the elements on which it operates
§ Applicability
•
an object structure contains many classes of objects with differing
interfaces, and you want to perform operations on these objects that
depend on their concrete classes
•
many distinct and unrelated operations need to be performed on objects
in an object structure, and you want to avoid "polluting" their classes
with these operations
•
the classes defining the object structure rarely change, but you often
want to define new operations over the structure
© 2002-2003 Luca Padovani, Riccardo Solmi
17
Visitor /2
§
Structure
© 2002-2003 Luca Padovani, Riccardo Solmi
18
9
Visitor /3
§ Collaborations
• A client that uses the Visitor pattern must create a
ConcreteVisitor object and then traverse the object
structure, visiting each element with the visitor
• When an element is visited, it calls the Visitor operation that
corresponds to its class. The element supplies itself as an
argument to this operation to let the visitor access its state, if
necessary
© 2002-2003 Luca Padovani, Riccardo Solmi
19
Visitor /4
§
The following interaction diagram illustrates the collaborations between
an object structure, a visitor, and two elements
© 2002-2003 Luca Padovani, Riccardo Solmi
20
10
Visitor /4
§ Consequences
• Visitor makes adding new operations easy
• A visitor gathers related operations and separates unrelated
ones
• Adding new ConcreteElement classes is hard
• Visiting across class hierarchies
• Accumulating state
• Breaking encapsulation
© 2002-2003 Luca Padovani, Riccardo Solmi
21
Visitor example 1
© 2002-2003 Luca Padovani, Riccardo Solmi
22
11
Visitor example 2
§
Compiler that represents
programs as abstract syntax
trees
© 2002-2003 Luca Padovani, Riccardo Solmi
23
Visitor Questions
§ One issue with the Visitor pattern involces cyclicality. When
you add a new Visitor, you must make changes to existing
code. How would you work around this possible problem?
© 2002-2003 Luca Padovani, Riccardo Solmi
24
12