Object-oriented design patterns in UML [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]

Software and Services research group (S2)
Department of Computer Science, Faculty of Sciences
Vrije Universiteit Amsterdam
VRIJE
UNIVERSITEIT
AMSTERDAM
Object-oriented design patterns
in UML
Software design (400170) – 2017/2018
Ivano Malavolta
i.malavolta@vu.nl

VRIJE
UNIVERSITEIT
AMSTERDAM
Roadmap
• Object-oriented design patterns
• Creational design patterns
• Structural design patterns
• Behavioural design patterns
2

VRIJE
UNIVERSITEIT
AMSTERDAM
What is a design pattern?
• a ”template” for how to solve a problem
• it can be used in many different situations
• not a finished design
• it cannot be transformed directly into source code
• helps the designer in getting to the right design faster
3
A reusable form of a solution
to a common design problem

VRIJE
UNIVERSITEIT
AMSTERDAM
The “gang of four”
• Erich Gamma
• Richard Helm
• Ralph Johnson
• John Vlissides
1994: 4 IBM programmers observed and
documented 23 common problems and
their best accepted solutions
4

VRIJE
UNIVERSITEIT
AMSTERDAM
• how objects can be created
• maintainability
• control
• extensibility
• how to form larger structures
• management of complexity
• efficiency
• how responsibilities can be assigned to
objects
• objects decoupling
• flexibility
• better communication
Types of design patterns
5
CREATIONAL
STRUCTURAL
BEHAVIOURAL

VRIJE
UNIVERSITEIT
AMSTERDAM
Essential parts of a design pattern
6
Pattern name Provides a common vocabulary for software
designers
Intent What does the design pattern do?
What is its rationale and intent?
What particular design issue or problem does
it address?
Solution The basic elements providing the solution to
the problem in terms of: structure, participants,
collaborations
Consequences What are the results and trade offs by applying
the design pattern

VRIJE
UNIVERSITEIT
AMSTERDAM
Creational design patterns
7

VRIJE
UNIVERSITEIT
AMSTERDAM
Creational design patterns
• Singleton
• A class for which only a single instance can exist in the
system at any time
• Factory Method
• Creates an object without hardcoding its type in the code
• Abstract Factory
• Creates groups of related objects without specifying the
exact concrete classes
• Object Pool
• Allows to recycle objects that are no longer in use
• Prototype
• Allows to instantiate a class by copying or cloning the
properties of an existing object
8
studied in this course

VRIJE
UNIVERSITEIT
AMSTERDAM
Singleton
99
Name Singleton
Intent • To ensure that only one instance of a class is allowed
within a system
• Controlled access to a single object is necessary
Solution
Consequences • Controlled access to sole instance
• Reduced name space à less “global variables”
• Permits also a variable number of instances
• …
Examples • Logging utility
• An entity representing the whole system
• Central station within a robotic system
• …

VRIJE
UNIVERSITEIT
AMSTERDAM
Singleton – implementation (1/2)
10
https://www.tutorialspoint.com/design_pattern

VRIJE
UNIVERSITEIT
AMSTERDAM
Singleton – implementation (2/2)
11

VRIJE
UNIVERSITEIT
AMSTERDAM
Factory method
12
Name Factory method
Intent • to abstract the process of object creation so that the type
of the created object can be determined at run-time
• to make a design more customizable in terms of which
objects can be created
• you want to avoid the new operator because you do not
want to hard code which class you want to instantiate
Solution [see next slide]
Consequences • You have a dedicated class for creating instances of
objects
• You can pass arguments to that class for controlling the
features of the objects you want to create
Examples • A central entity for creating rovers, but you really do not
want to know exactly how a rover is created
• All the cases in which an object does not know what
concrete classes will be required to create objects at
runtime, but just wants to get a class that will do the job

VRIJE
UNIVERSITEIT
AMSTERDAM
Factory method – solution by example
13
<<abstract>>

VRIJE
UNIVERSITEIT
AMSTERDAM
Factory method - implementation
14

VRIJE
UNIVERSITEIT
AMSTERDAM
15

VRIJE
UNIVERSITEIT
AMSTERDAM
16

VRIJE
UNIVERSITEIT
AMSTERDAM
Structural design patterns
17

VRIJE
UNIVERSITEIT
AMSTERDAM
Structural design patterns
• Adapter
• For gluing together incompatible classes
• Proxy
• An object representing another object
• Bridge
• Separates an object’s interface from its implementation
• Decorator
• Add responsibilities to objects dynamically
• Façade
• A single class that represents an entire subsystem/library
• Flyweight, Composite , Private Class Data
• …
18

VRIJE
UNIVERSITEIT
AMSTERDAM
Adapter
19
Name Adapter
Intent • To convert the interface of a class into another interface
• To let two or more classes with incompatible interfaces
work together
• To wrap an existing class with a new one
• To have a sort of homogenous interface that masks the
diversity of some set of various objects
Consequences • You have a single class which is responsible to join
functionalities of independent or incompatible classes
Examples • A wrapper of a complex Java library in order to expose
only the APIs that you need in your system
• A class uses a naïve coordinate reference system, but
you want to mask it and show a more straightforward one
to the rest of your system

VRIJE
UNIVERSITEIT
AMSTERDAM
Adapter - solution
20
<<abstract>>
MethodB()
MethodA()
http://www.blackwasp.co.uk/Adapter.aspx
https://dzone.com/articles/design-patterns-uncovered-0

VRIJE
UNIVERSITEIT
AMSTERDAM
Adapter - example
21
https://sourcemaking.com/design_patterns/adapter

VRIJE
UNIVERSITEIT
AMSTERDAM
Adapter - implementation
22
public class Wrapper {
// this is the wrapped object
private LegacyComponent legacyComponent;
// constructor
public Wrapper (LegacyComponent instance) {
this.legacyComponent = instance;
}
// call to the wrapped method
public int doThis() {
int result = 0;
float value = this.legacyComponent.doThat();
// ...here you transform value into an integer...
return result;
}
}

VRIJE
UNIVERSITEIT
AMSTERDAM
Behavioural design patterns
23

VRIJE
UNIVERSITEIT
AMSTERDAM
Behavioural design patterns (1/2)
• Observer
• A way of notifying change to a number of classes
• Chain of responsibility
• A way of passing a request between a chain of objects
• Command
• Encapsulate a command request as an object
• Interpreter
• A way to include language elements in a program
• Iterator
• Sequentially access the elements of a collection
• Mediator
• Defines simplified communication between classes
24

VRIJE
UNIVERSITEIT
AMSTERDAM
Behavioural design patterns (2/2)
• Memento
• Capture and restore an object's internal state
• Null Object
• Designed to act as a default value of an object
• State
• Alter an object's behavior when its state changes
• Strategy
• Encapsulates an algorithm inside a class
• Template method
• Defer the exact steps of an algorithm to a subclass
• Visitor
• Defines a new operation to a class without change
25

VRIJE
UNIVERSITEIT
AMSTERDAM
Observer
26
Name Observer
Intent • To let one or more objects be notified of state changes in
other objects within the system
• When one object changes state, all its dependents are
notified and updated automatically
Consequences • Support for broadcast communication
• State changes in one or more objects should trigger
behavior in other objects
• You can reuse subjects without reusing their observers,
and vice versa
• You can add or remove observers without modifying the
subjects
Examples • A central station can issue commands to a subset of
rovers moving in the environment
• When a rover finishes its tasks it can notify the central
station
• etc.

VRIJE
UNIVERSITEIT
AMSTERDAM
Observer - solution
27
these classes are
generic and fixed

VRIJE
UNIVERSITEIT
AMSTERDAM
Observer – implementation (1/5)
28

VRIJE
UNIVERSITEIT
AMSTERDAM
29

VRIJE
UNIVERSITEIT
AMSTERDAM
30

VRIJE
UNIVERSITEIT
AMSTERDAM
31

VRIJE
UNIVERSITEIT
AMSTERDAM
32

VRIJE
UNIVERSITEIT
AMSTERDAM
Chain of responsibility
33
Name Chain of responsibility
Intent • Avoid coupling the sender of a request to its receiver by
giving more than one object a chance to handle the
request
• Chain the receiving objects and pass the request along
the chain until an object handles it
• à it is sequential (Observer is in parallel)
Consequences • Reduced coupling between objects
• every objects just needs to know its successor
• More than one object may handle a request, and the
handler is not known a priori
• You can change responsibilities by changing the chain at
run-time
• A request can also go unhandled
Examples • A central station keeps a pool of idle robots and assigns
tasks without knowing the exact number of available
robots

VRIJE
UNIVERSITEIT
AMSTERDAM
Chain of responsibility - solution
34this chain goes on until
the request is handled
this class is
generic and
fixed

VRIJE
UNIVERSITEIT
AMSTERDAM
Chain of responsibility – implementation (1/4)
35

VRIJE
UNIVERSITEIT
AMSTERDAM
36

VRIJE
UNIVERSITEIT
AMSTERDAM
37

VRIJE
UNIVERSITEIT
AMSTERDAM
38

VRIJE
UNIVERSITEIT
AMSTERDAM
39

VRIJE
UNIVERSITEIT
AMSTERDAM
What this lecture means to you?
• Design patterns = solutions to common software design
problems
• They are not prescriptive specifications for software
• Do not memorize them à it is more important that you
understand when they are needed and why
• They are not always needed
• Do not apply design patterns to a trivial solution à you will
overcomplicate your code and lead to maintainability issues
40

VRIJE
UNIVERSITEIT
AMSTERDAM
Take-home exercise
1. Reconsider the FB class diagram
2. Identify a potential issue
3. Apply a design pattern for solving it
41
Exercise inspired by prof. Lago’s lecture at the VU

VRIJE
UNIVERSITEIT
AMSTERDAM
Readings
• https://en.wikipedia.org/wiki/Design_Patterns
• https://sourcemaking.com/design_patterns
• http://www.blackwasp.co.uk/gofpatterns.aspx
• [optional] Detailed info on the GoF book
42

Object-oriented design patterns in UML [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]

More Related Content

Similar to Object-oriented design patterns in UML [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]

More from Ivano Malavolta

Recently uploaded

Object-oriented design patterns in UML [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]