Software and Services research group (S2)

Department of Computer Science, Faculty of SciencesVrije Universiteit Amsterdam

VRIJEUNIVERSITEITAMSTERDAM

Object-oriented design patterns in UML

Software modeling (401016) – 2016/2017

Ivano Malavoltai.malavolta@vu.nl

VRIJEUNIVERSITEITAMSTERDAM

Roadmap

• Object-oriented design patterns• Creational design patterns• Structural design patterns• Behavioural design patterns

2

VRIJEUNIVERSITEITAMSTERDAM

What is a design pattern?

• a ”template” for how to solve a problem that 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

VRIJEUNIVERSITEITAMSTERDAM

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

VRIJEUNIVERSITEITAMSTERDAM

• 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

VRIJEUNIVERSITEITAMSTERDAM

Essential parts of a design patterns

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

VRIJEUNIVERSITEITAMSTERDAM

Example: the Singleton design pattern

7

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• Permits a variable number of instances• …

Examples • Logging utility• An entity representing the whole system• Central station within a robotic system• …

VRIJEUNIVERSITEITAMSTERDAM

Creational design patterns

8

VRIJEUNIVERSITEITAMSTERDAM

Creational design patterns

• Singleton• A class for which only a one single instance can exist in the

system

• 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

9

studied in this course

VRIJEUNIVERSITEITAMSTERDAM

Singleton

1010

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• Permits a variable number of instances• …

Examples • Logging utility• An entity representing the whole system• Central station within a robotic system• …

VRIJEUNIVERSITEITAMSTERDAM

Singleton – implementation (1/2)

11

https://www.tutorialspoint.com/design_pattern

VRIJEUNIVERSITEITAMSTERDAM

Singleton – implementation (2/2)

12

https://www.tutorialspoint.com/design_pattern

VRIJEUNIVERSITEITAMSTERDAM

Factory method

13

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 it will be required to create at runtime, but just wants to get a class that will do the job

VRIJEUNIVERSITEITAMSTERDAM

Factory method – solution by example

14

<<abstract>>

VRIJEUNIVERSITEITAMSTERDAM

Factory method - implementation

15

https://www.tutorialspoint.com/design_pattern

VRIJEUNIVERSITEITAMSTERDAM

Factory method - implementation

16

https://www.tutorialspoint.com/design_pattern

VRIJEUNIVERSITEITAMSTERDAM

Factory method - implementation

17

https://www.tutorialspoint.com/design_pattern

VRIJEUNIVERSITEITAMSTERDAM

Structural design patterns

18

VRIJEUNIVERSITEITAMSTERDAM

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

19

studied in this course

VRIJEUNIVERSITEITAMSTERDAM

Adapter

20

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

VRIJEUNIVERSITEITAMSTERDAM

Adapter - solution

21

<<abstract>>

MethodB()

MethodA()

http://www.blackwasp.co.uk/Adapter.aspxhttps://dzone.com/articles/design-patterns-uncovered-0

VRIJEUNIVERSITEITAMSTERDAM

Adapter - example

22

https://sourcemaking.com/design_patterns/adapter

VRIJEUNIVERSITEITAMSTERDAM

Adapter - implementation

23

public class Wrapper {

// this is the wrapped objectprivate LegacyComponent legacyComponent;

// constructorpublic Wrapper (LegacyComponent instance) {

this.legacyComponent = instance;}

// call to the wrapped methodpublic int doThis() {

int result = 0;float value = this.legacyComponent.doThat();// ...here you transform value into an integer...return result;

}}

VRIJEUNIVERSITEITAMSTERDAM

Behavioural design patterns

24

VRIJEUNIVERSITEITAMSTERDAM

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

25

studied in this course

VRIJEUNIVERSITEITAMSTERDAM

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

26

VRIJEUNIVERSITEITAMSTERDAM

Observer

27

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.

VRIJEUNIVERSITEITAMSTERDAM

Observer - solution

28

VRIJEUNIVERSITEITAMSTERDAM

Observer – implementation (1/5)

29

VRIJEUNIVERSITEITAMSTERDAM

Observer – implementation (2/5)

30

VRIJEUNIVERSITEITAMSTERDAM

Observer – implementation (3/5)

31

VRIJEUNIVERSITEITAMSTERDAM

Observer – implementation (4/5)

32

VRIJEUNIVERSITEITAMSTERDAM

Observer – implementation (5/5)

33

VRIJEUNIVERSITEITAMSTERDAM

Chain of responsibility

34

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 assign tasks without knowing the exact number of available robots

VRIJEUNIVERSITEITAMSTERDAM

Chain of responsibility - solution

35this chain goes on until the request is handled

VRIJEUNIVERSITEITAMSTERDAM

Chain of responsibility – implementation (1/4)

36

VRIJEUNIVERSITEITAMSTERDAM

Chain of responsibility – implementation (2/4)

37

VRIJEUNIVERSITEITAMSTERDAM

Chain of responsibility – implementation (3/4)

38

VRIJEUNIVERSITEITAMSTERDAM

Chain of responsibility – implementation (3/4)

39

VRIJEUNIVERSITEITAMSTERDAM

Chain of responsibility – implementation (4/4)

40

VRIJEUNIVERSITEITAMSTERDAM

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

41

VRIJEUNIVERSITEITAMSTERDAM

Take-home exercise

42

VRIJEUNIVERSITEITAMSTERDAM

Exercise

1. Reconsider the FB class diagram2. Identify a potential issue3. Apply a design pattern for solving it

43

Exercise inspired by prof. Lago’s lecture at the VU

VRIJEUNIVERSITEITAMSTERDAM

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

44