Object-oriented design patterns in UML [Software Modeling] [Computer Science] [Vrije Universiteit...
-
Upload
ivano-malavolta -
Category
Technology
-
view
567 -
download
0
Transcript of Object-oriented design patterns in UML [Software Modeling] [Computer Science] [Vrije Universiteit...
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 [email protected]
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