SFWRENG 2AA4
Software Design I – Introduction to Software Development
Object-oriented design patterns
Part 1
Dr. Istvan David
Department of Computing and Software (CAS)
Faculty of Engineering
[Link]@[Link]
[Link]
The following slides have been adopted from the 2020/2021 edition of the Software design (40007)
course of the Vrije Universiteit (VU) Amsterdam, The Netherlands.
All rights reserved by Dr. Ivano Malavolta and Dr. Istvan David.
Roadmap
• Introduction to object-oriented design patterns
• Design patterns: Singleton, Factory Method, Iterator
• Principles: Interface segregation, Overloading
2
Object-oriented design patterns
3
What is a design pattern?
A reusable form of a solution
to a common design problem
• 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
4
What is a design pattern?
A reusable form of a solution
to a common design problem
• 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
5
What is a design pattern?
A reusable form of a solution
to a common design problem
• 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
6
Gang of Four (GOF)
• Erich Gamma
• Richard Helm
• Ralph Johnson
• John Vlissides
1994: 4 IBM programmers observed and
documented 23 common problems and
their best accepted solutions
7
Types of design patterns
CREATIONAL • how objects can be created
• maintainability
• control
• extensibility
STRUCTURAL • how to form larger structures
• management of complexity
• efficiency
BEHAVIORAL • how responsibilities can be assigned to
objects
• objects decoupling
• flexibility 8
• better communication
Creational design patterns
• Singleton studied in this course
• 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
11
Structural design patterns
• Adapter studied in this course
• For gluing together incompatible classes
• Decorator
• Add responsibilities to objects dynamically
• Flyweight
• Ensure uniqueness of immutable objects + performance
• Proxy
• An object representing another object
• Bridge
• Separates an object’s interface from its implementation
• Façade
• A single class that represents an entire subsystem/library
• ...
12
Behavioural design patterns (1/2)
• Iterator studied in this course
• Sequentially access the elements of a collection
• Command
• Encapsulate a command request as an object
• 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
• Template method
• Defer the exact steps of an algorithm to a subclass
• Visitor
• Defines a new operation to a class without change
13
Behavioral 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
• Interpreter
• A way to include language elements in a program
• Mediator
• Defines simplified communication between classes
14
Essential parts of a design pattern
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
15
Singleton
Creational design pattern
16
Singleton
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 • Session object in a browser
• Logging utility
• A class for representing a configuration file which is 17
read only at startup time
Singleton – implementation (1/2)
18
[Link]
Singleton – implementation (2/2)
19
[Link]
Factory method
Creational design pattern
20
Problem
PROBLEM
The creation of subtype
instances is hard-coded,
21
resulting in poor
maintainability.
Factory method
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 • 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
• A central entity for creating virtual items (e.g., a blue cup),
but you really do not want to know exactly how an item is
created 22
Factory method – solution by example
<<abstract>>
asks
23
Factory method - implementation
24
[Link]
Factory method - implementation
25
[Link]
Factory method - implementation
26
[Link]
Abstract solution
27
Wrap-up
Singleton Factory method
28
Iterator
Behavioral design pattern
29
The Iterator design pattern
Name Iterator
Intent • Need to "abstract" the traversal of wildly different data
structures from client code
• Provide a way to access the elements of an aggregate
object sequentially without exposing its underlying
representation
• Polymorphic traversal of collections
Solution [see next slides]
Consequences • You have encapsulated the internal representation of your
attributes with cardinality >1
• If you change their internal representation, you do not
need to change their client code
• You can use the “for each” construct over them
Examples • You need to iterate over the objects present in a room of
your videogame
• You need to iterate over code snippets of different types
30
• ...
The problem
If you will change the way you internally represent cards,
then you may risk to change also all its client codes!
31
Meet the Iterator interface
<<interface>>
Iterator
+ hasNext()
+ next()
...
• It formally defines what “iterating” means
• Once you implement such interface, your client code can
iterate over your elements always in the same way
32
[Link]
How to use it?
33
How to use it?
Problem: The name of the method for getting an
iterator is not standard (can change for every class
in your system)
34
Meet the Iterable interface
<<interface>>
Iterable
+ Iterator<T> iterator()
...
• Now, to iterate over an object (polymorphically) we can
simply iterate over its returned iterator
35
[Link]
How to use it?
Now an instance of Deck can be used in any place you need an
Iterable
36
How to use it?
The for loop
Now an instance works
of Deck because
can be usedit in
always expects
any place youaneed an
Iterable class implementing the Iterable interface
37
Final representation of the Iterator design pattern
In Java:
• The Aggregate role is covered by the Iterable interface
• The Iterator role is covered by Iterator interface
In the previous example:
• The ConcreteAggregate is Deck
• The concreteIterator is the specific instance of Iterator we
are using 38
• eg, the JVM-specific type returned by [Link]()