Patterns in
Software Engineering
Software
Engineering
Lecturer: Raman Ramsin
Lecturer:
Raman
Ramsin
Lt 3
L
ec
t
ure
3
GoF Desi
g
n Patterns
–
Structural
Department of Computer Engineering 1Sharif University of Technology
g
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Patterns in Software Engineering-Lecture 3 Slides-Computer Engineering, Slides of Software Engineering
GoF Structural Patterns, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Raman Ramsin, Lecture Slides, Patterns in Software Engineering, Department of Computer Engineering, Sharif University of Technology, Iran.
Typology: Slides
2011/2012
1 / 39
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Patterns in Software Engineering-Lecture 3 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity!
Patterns inSoftware EngineeringSoftware Engineering Lecturer: Raman RamsinLecturer:
Raman Ramsin
L
t^
Lecture 3 GoF Design Patterns – Structural
1
g
Patterns in Software Engineering – Lecture 3 GoF Structural Patterns Class/Object
Adapter:
Convert the interface of a class into another interface
clients expect
Adapter lets classes work together that couldn't
clients expect. Adapter lets classes work together that couldn totherwise because of incompatible interfaces.
^
Object
Bridge:
Decouple an abstraction from its implementation so that the
Bridge:
Decouple
an abstraction from its implementation so that the
two can vary independently.
Composite:
Compose objects into tree structures to represent whole-
part hierarchies. Composite lets clients treat individual objects andcompositions of objects uniformlycompositions of objects uniformly.
Decorator:
Attach additional responsibilities to an object dynamically.
Façade:
Provide a unified interface to a set of interfaces in a
subsystemsubsystem.
Flyweight:
Use sharing to support large numbers of fine-grained
objects efficiently.
Proxy:
Provide a surrogate or placeholder for another object to
2
Proxy:
Provide
a surrogate or placeholder for another object to
control access to it.
Patterns in Software Engineering – Lecture 3 Adapter: Applicability Use the Adapter pattern when
^
you want to use an existing class, and its interface does not match theone you need.one you need.
^
you want to create a reusable class that cooperates with unrelated orunforeseen classes
that is
classes that don't necessarily have
unforeseen classes, that is, classes that don t necessarily havecompatible interfaces.( bj
t
d
t^
l )
d t
l^
i ti
b l
b t
(object adapter only) you need to use several existing subclasses, butit's impractical to adapt their interface by subclassing every one. Anobject adapter can adapt the interface of its parent class.
4
Sharif University of Technology
Patterns in Software Engineering – Lecture 3 Adapter (Class): Structure
5
Patterns in Software Engineering – Lecture 3 Adapter (Class): Consequences 9 lets Adapter override some of Adaptee's behavior, since Adapter is asubclass of Adaptee. 9 introduces only one object, and no additional pointer indirection isneeded to get to the adaptee. 8 adapts Adaptee to Target by committing to a concrete Adapterclass. As a consequence, a class adapter won't work when we want
q^
,^
p
to adapt a class and all its subclasses.
7
Patterns in Software Engineering – Lecture 3 Adapter (Object): Consequences 9 lets a single Adapter work with many Adaptees—that is, the Adapteeitself and all of its subclasses (if any). The Adapter can also addfunctionality to all Adaptees at oncefunctionality to all Adaptees at once. 8 makes it harder to override Adaptee behavior
It will require
makes it harder to override Adaptee behavior. It will requiresubclassing Adaptee and making Adapter refer to the subclass ratherthan the Adaptee itself.
8
Sharif University of Technology
Patterns in Software Engineering – Lecture 3 Bridge: Applicability Use the Bridge pattern when
t t
id^
t bi di
b t
b t
ti
^
you want to avoid a permanent binding between an abstractionand its implementation; for example, when the implementationmust be selected or switched at run-time.
^
both the abstractions and their implementations should be
^
both the abstractions and their implementations should beextensible by subclassing; combine different abstractions andimplementations and extend them independently.
^
changes in the implementation of an abstraction should have
^
changes in the implementation of an abstraction should haveno impact on clients; that is, their code should not have to berecompiled.
^
(C++) you want to hide the implementation of an abstraction
^
(C++) you want to hide the implementation of an abstractioncompletely from clients. In C++ the representation of a class isvisible in the class interface.
^
you want to share an implementation among multiple objects
10
Sharif University of Technology
^
you
want to share an implementation among multiple objects and this fact should be hidden from the client.
Patterns in Software Engineering – Lecture 3 Bridge: Structure
11
Patterns in Software Engineering – Lecture 3 Composite Intent:
^
Compose objects into tree structures to represent part-whole
^
Compose objects into tree structures to represent part wholehierarchies. Composite lets clients treat individual objects andcompositions of objects uniformly.
13
Patterns in Software Engineering – Lecture 3 Composite: Applicability Use the Composite pattern when
^
you want to represent whole-part- hierarchies of objects.
^
you want clients to be able to ignore the difference betweencompositions of objects and individual objects. Clients will treatall objects in the composite structure uniformly.all objects in the composite structure uniformly.
14
Patterns in Software Engineering – Lecture 3 Composite: Typical Object Structure
16
Patterns in Software Engineering – Lecture 3 Composite: Consequences 9
h
li^
t^
d
t^
i^
iti^
bj^
t^
it^
l^
t k
wherever client code expects a primitive object, it can also take acomposite object.
makes the client simple. Clients can treat composite structures andindividual objects uniformly
and this simplifies their code
individual objects uniformly, and this simplifies their code. 9
makes it easier to add new kinds of components. Clients don't haveto be changed for new Component classes.
can make your design overly general. It makes it harder to restrictthe components of a composite.^8
If you want a composite to have only certain components, you can'trely on the type system to enforce those constraints for you. You'llhave to use run-time checks instead.
17
Sharif University of Technology
Patterns in Software Engineering – Lecture 3 Decorator: Class Hierarchy
19
Patterns in Software Engineering – Lecture 3 Decorator: Applicability Use the Decorator pattern
^
to add responsibilities to individual objects dynamically andtransparently
that is
without affecting other objects
transparently, that is, without affecting other objects.
^
for responsibilities that can be withdrawn
^
for responsibilities that can be withdrawn.h
t^
i^
b^
b l
i^
i^
i^
ti^
l^ S
ti
^
when extension by subclassing is impractical. Sometimes alarge number of independent extensions are possible andwould produce an explosion of subclasses.
20
Sharif University of Technology