This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam. http://www.ivanomalavolta.com

1. 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

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

3. 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

4. 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

5. 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

6. 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

7. VRIJE
UNIVERSITEIT
AMSTERDAM
Creational design patterns
7

8. 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

9. 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
• …

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

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

12. 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

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

14. VRIJE
UNIVERSITEIT
AMSTERDAM
Factory method - implementation
14
https://www.tutorialspoint.com/design_pattern

15. VRIJE
UNIVERSITEIT
AMSTERDAM
Factory method - implementation
15
https://www.tutorialspoint.com/design_pattern

16. VRIJE
UNIVERSITEIT
AMSTERDAM
Factory method - implementation
16
https://www.tutorialspoint.com/design_pattern

17. VRIJE
UNIVERSITEIT
AMSTERDAM
Structural design patterns
17

18. 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
studied in this course

19. 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
Solution [see next slide]
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

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

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

22. 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;
}
}

23. VRIJE
UNIVERSITEIT
AMSTERDAM
Behavioural design patterns
23

24. 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
studied in this course

25. 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

26. 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
Solution [see next slide]
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.

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

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

29. VRIJE
UNIVERSITEIT
AMSTERDAM
Observer – implementation (2/5)
29

30. VRIJE
UNIVERSITEIT
AMSTERDAM
Observer – implementation (3/5)
30

31. VRIJE
UNIVERSITEIT
AMSTERDAM
Observer – implementation (4/5)
31

32. VRIJE
UNIVERSITEIT
AMSTERDAM
Observer – implementation (5/5)
32

33. 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)
Solution [see next slide]
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

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

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

36. VRIJE
UNIVERSITEIT
AMSTERDAM
Chain of responsibility – implementation (2/4)
36

37. VRIJE
UNIVERSITEIT
AMSTERDAM
Chain of responsibility – implementation (3/4)
37

38. VRIJE
UNIVERSITEIT
AMSTERDAM
Chain of responsibility – implementation (3/4)
38

39. VRIJE
UNIVERSITEIT
AMSTERDAM
Chain of responsibility – implementation (4/4)
39

40. 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

41. 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

42. 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