Lecture 5 Behaviour

1
Lecture 5 Behaviour

• Defining behaviour
• Use cases
• Sequence diagrams
• Collaboration diagrams
• Activity diagrams
• Statechart diagrams

2
Defining operations in object-oriented systems
Definition of an operation A function or a
procedure that may execute on an object instance
of a class.
Person
pnr Integer name String birth_date
Integer address String teaches Course

• Compartment 1 .
• Compartment 2
• class properties
• peer-to-peer relationships
• Compartment 3

name() age() address() change_address(new_address)

• Objects manage their own data using their own
  operations

3
Object collaboration

• An object may communicate with another object
  ONLY via the message-passing mechanism.

4
Coupling
Object 2
Data relevant for object 2 operations relevant
for object 2
message
Object 1
Data relevant for object 1 operations relevant
for object 1
message
message
message
message
Object 4
Data relevant for object 4 operations relevant
for object 4
message
Object 3
Data relevant for object 3 operations relevant
for object 3
Application
5
Cohesion
Object 2
I only conduct computation of a square root
message
Object 1
I only manage equation type y
message
message
message
message
Object 4
I only print out the files
message
Object 3
I only accept user input type x
Application
6
Example of an object
Coffee machine

• Class
• Coffee machine
• Attributes
• ...
• Operations
• Black coffee
• Coffee with sugar
• Coffee with cream
• Coffee with cream and sugar
• ...

• Black coffee
• Coffee with sugar
• Coffee with cream
• Coffee with cream and sugar

7
Encapsulation
Class Person
pnr Integer name String birth_date
Integer address String
name()
data
change_address(new_address)
Operations manipulating data
age()
address()
8
Information Hiding
Class Person
name()
age()
address()
pnr Integer name String birth_date
Integer address String
Change_address (Tjädervägen .)
David Parnas the founder of OO
changes data
change_address(new_address)
Only the objects own code may read and change
its own data values.
9
Operationsgeneralisation

• Student and Teacher subclasses inherit all
  Persons method.
• Student and Teacher objects are operated by all
  the inherited methods plus their own methods.

10
Overloading
Person
pnr Integer name String birth_date
Integer address String
name() age() address() evaluate_skills()
Student
Teacher
IQ-value Integer student_points Integer
Ped_skill Integer experience Integer
take_exam()
examine(student1) examine(student1, student2)

• The method examine is overloaded with multiple
  implementations
• Operation is chosen according the number of
  parameters and their types.

11
Overriding
Person
pnr Integer name String birth_date
Integer address String
name() age() address() evaluate_skills()
Student
Teacher
IQ-value Integer student_points Integer
Ped_skill Integer experience Integer
take_exam()
evaluate_skills() examine(student1) examine(studen
t1, student2)
12
Polymorphism in an inheritance hierarchy
The client object does not need to worry to which
class the agent objects belong. It just sends a
message expecting that the agent object
understands this message.
evaluate_skills()
13
Polymorphism with unrelated objects
Person
Course
pnr Integer name String birth_date
Integer address String
number String name String no_of_students
Integer teacher_name String name()
name() age() address() evaluate_skills()
Classes
Objects
name()
14
Late binding

Person
pnr Integer name String birth_date
Integer address String

• The specific receiver of any given message is not
  known until runtime, so the determination of
  which method to invoke cannot be made until then.
  
• The called object is responsible for executing
  the right code.
• This requires polymorphy.
• Polymorphy requires late binding.
• Late binding in Swedish is called dynamisk
  bindning.

name() age() address() evaluate_skills()
Teacher
Student
Ped_skill Integer experience Integer
IQ-value Integer student_points Integer
take_exam()
evaluate_skills() examine(student1) examine(studen
t1, student2)
Classes
Objects
evaluate_skills()
15
Delegation
16
Documenting
behaviour
1) List events
2) Define collaboration
msg2()
ClassA
ClassB
msg1()
msg3()
msg4()
msg1()
msg5()
ClassA
ClassB
5) Identify activities
Use case
Collaboration diagram
3) Define sequence
4) Identify object states!
Activity diagram
register()
Registered
deregister()
Deregistered
Sequence diagram
Statechart diagram
17
Use Case Diagram, purpose
Class diagrams
Activity diagrams
Requirements document (text in natural language)
Sequence diagrams
Statechart diagrams

• Use case models are developed at different levels
  of abstraction
• system, system component, or a class.
• Use case modelling is an iterative and
  incremental process.
• If user requirements change, the changes should
  be made in all the affected documents.

18
Documenting use cases
message 1
message 1
message 3
message 4
message 5
message 5
message 7

• Use Case Diagram
• Sequence Diagram
• Textual Descriptions

19
Sequence diagrams, example
Student/Course Record
ready Yes/No check if ready(arglist)
Student
Course
.. register(arg1, arg2)
qualif_requirements String register(arg1,
arg2) list qualif requir (arglist) register(arg1)

reads
In this example, the association reads is
redundant. It is fully acceptable to have
redundant associations. But, if we need it, then
we keep it. However, many modellers would claim
that the model is not neat.
20
Sequence diagrams, example
Student/Course Record
Student
Course
register(arglist)
list qualification requirements(arglist)
check if ready(arglist)
ready(arglist)
register(arglist)
confirm registr(arglist)
register(arglist)
21
Sequence diagrams,
example
Student/Course Record
OID 888999
Gudrun/Linguistics Record
ready Yes/No check if ready(arglist)
check if ready (arglist)
ready Yes
Course
Student
qualif_requirements String register(arg1,
arg2) list qualif requir (arglist) register(arg1)

OID 434356
.. register(arg1, arg2)
reads
register(arg1, arg2)
Gudrun Schyman
list qualif requir (arglist)
register(arg1, arg2)
register(arglist)
4309025689 Gudrun Schyman reads
44000122
OID 44000122
Course in Polish
PPP234 Polski students
434356
22
Sequence diagrams, creating new objects
Object name
Object name
message 1
create message2
This object has just got created
23
Sequence diagrams,
example creating new objects
Student/Course Record
ready Yes/No check if ready(arglist)
course record
student record
Student
Course
.. register(arglist)
qualif_requirements String register(arglist) lis
t qualif requir (arglist)
reads
24
Sequence diagrams,
example creating new objects
OID 44000122
OID 434356
Course in Polish
Gudrun Schyman
PPP234 Polski students student record
4309025689 Gudrun Schyman reads course record

25
Sequence diagrams, example
Student/Course Record
Student
Course
Student/Course Record
register(arglist)
list qualification requirements(arglist)
check if ready(arglist)
register(arglist)
create student/course record(arglist)
confirm registr(arglist)
register(arglist)
26
Sequence diagrams,
example creating new objects
OID 45985776
Course in Linguistics
OID 888999
PPP234 Linguistics Students Student record
Gudrun/Linguistics Record
434356
ready Yes check if ready(arglist)
888999
OID 434356
Gudrun Schyman
4309025689 Gudrun Schyman Reads course record
44000122
888999
888955
OID 44000122
Course in Polish
PPP234 Polski Students Student rec
434356
888955
27
Sequence diagrams, object destruction
Object name
Object name
message 1
destroy message
X
This object has just got destroyed
28
Sequence diagrams,
example destroying objects
Student/Course Record
ready Yes/No check if ready(arglist)
course record
student record
Student
Course
.. register(arglist)
qualif_requirements String register(arglist) lis
t qualif requir (arglist) deregister()
reads
29
Sequence diagrams,
example destroying objects
OID 888999
Gurun/Polish Record
ready No Student 434356 Course 44000122
OID 44000122
OID 434356
Course in Polish
Gudrun Schyman
PPP234 Polski students
4309025689 Gudrun Schyman reads
888999
888999
30
Example, object destruction (class level)
Student/Course Record
Student
Course
deregister(arglist)
destroy student record (arglist)
X
confirm dereg(arglist)
31
Example, object destruction (object level)
Gudrun/Polish Student/Course Record
Gudrun Student
Polish Course
deregister(arglist)
destroy student record (arglist)
X
confirm dereg(arglist)
32
Sequence diagrams,
example destroying objects
In reality, this object and its links are
archived. Not in this example.
OID 888999
Gurun/Polish Record
ready Yes check if ready(arglist) Student
434356 Course 44000122
OID 434356
OID 44000122
Gudrun Schyman
Course in Polish
4309025689 Gudrun Schyman Stud record
PPP234 Polski Course record
888999
888999
OID 434356
OID 44000122
Course in Polish
Gudrun Schyman
PPP234 Polski Course record
4309025689 Gudrun Schyman Stud rec
33
Sequence diagrams,
example creating new objects
Student/Course Record
We have forgotten this.
ready Yes/No check if ready(arglist)
course record
student record
Student
Course
.. register(arglist) remove_course
qualif_requirements String register(arglist) lis
t qualif requir (arglist) deregister() remove_stud
ent()
reads
34
Example, object destruction
Student/Course Record
Student
Course
deregister(arglist)
destroy student record (arglist)
X
remove_student()
remove_course()
35
Sequence diagrams,
example destroying objects
OID 888999
Gurun/Polish Record
ready Yes check if ready(arglist) Student
434356 Course 44000122
OID 434356
OID 44000122
Gudrun Schyman
Course in Polish
4309025689 Gudrun Schyman reads
PPP234 Polski students
44000122
434356
OID 434356
OID 44000122
Course in Polish
Gudrun Schyman
PPP234 Polski students
4309025689 Gudrun Schyman reads
36
Sequence diagrams, conditional messages
Class/Object name
Class/Object name
message 1
conditionmessage2
A condition is written in square brackets
placed before the message
37
Sequence diagrams, mutually exclusive conditional
messages
Object 1
Object 2
Object 3
message 1
condition1message2
condition2message3
38
Sequence diagrams, conditional messages
Student
Course
nationality String register(arglist)
.. register(arglist)
reads
LanguageCourse
Other Course
..
..
LanguageCourse for Native Students
LanguageCourse for Non-native Students
..
39
Sequence diagrams, mutually exclusive conditional
messages
Language Course for non-native students
Langugage Course for native students
Student
non-nativeregister(arglist)
nativeregister(arglist)
40
Sequence diagrams, mutually exclusive conditional
messages
Course in Polish for non-native students
Course in Polish for native students
Pelle
non-Polishregister(arglist)
Polishregister(arglist)
41
Sequence diagrams,
example conditional messages
OID 905555
OID 434356
Course in Polish for Native Students
Karol Jaruzelski
4309025689 Karol Jaruzelski Polish reads
PPP234 Polski students
nationality
434356
905555
OID 44000122
Course in Polish for Non-Native Students
OID 434357
Gudrun Schyman
PPP234 Polski students
4309025689 Gudrun Schyman Swedish reads
434357
nationality
44000122
42
Sequence diagrams, iteration of a single message
Object 1
Object 2
message 1
conditionmessage2
The message is iterated till the condition is
fulfilled.
43
Sequence diagrams, example iteration of a single
message
Simulator
Random
runSimulation()
i1..NnumNextInt
44
Sequence diagrams, iteration over a collection
Double box indicates a multi- object (collection)
Object 1
Object 2
Object 3
message 1
conditionmessage2
The message is iterated till the condition is
fulfilled.
45
Sequence diagrams, iteration over a collection
46
HejHär börjar interationer med gammal notation
47
Example, iteration of a single message
Course in Polish
Course
Student
deregister(arglist.)
48
Sequence diagrams, iteration over a collection
ID 434356
Gudrun Schyman
4309025689 Gudrun Schyman 132 reads
49
Sequence diagrams, iteration of a series of
messages
Object 1
Object 2
Object 3
message 1
message2
message3
condition
The messages inside the box are iterated till
the iteration condition is fulfilled.
50
Class diagram
Student/Course Record
ready Yes/No check if ready(arglist)
course record
student record
Student
Course
.. register(arglist) remove_course deregister
qualif_requirements String register(arglist) lis
t qualif requir (arglist) deregister() remove_stud
ent()
reads
51
Sequence diagrams, iteration of a series of
messages
ID 954032
Gudrun/ Polish Record
. .. ..
ID 44000122
Course in Polish
PPP234 Polski 12 Adamski
ID 234384636
Course in Statistics
ABC123 Statistics 25 Persson
ID 664343
Gudrun/ Statistics Record
. .. ..
52
Example, iteration of a series of messages
Student/Course Record
course record
ready Yes/No check if ready(arglist)
student record
Student
Course
.. register(arglist) remove_course deregister
qualif_requirements String register(arglist) lis
t qualif requir (arglist) deregister() remove_stud
ent()
reads
Course in Polish
Gudrun/Polish record
Course
Student/Course Record
Student
deregister(arglist)
destroy student/course record (arglist)
X
deregister(arglist)
records 0
53
Sequence diagrams, iteration of a series of
messages
ID 954032
Gudrun/ Polish Record
. .. ..
ID 44000122
Course in Polish
PPP234 Polski 12 Adamski
ID 234384636
Course in Statistics
ABC123 Statistics 25 Persson
ID 664343
Gudrun/ Statistics Record
. .. ..
54
HejHär kommer samma material fastän med ny
notation
55
Sequence diagrams, iteration of a single message
Object 1
Object 2
message 1
Old notation for iterations
conditionmessage2
The message is iterated till the condition is
fulfilled.
56
Sequence diagrams, iteration of a single message
Object 1
Object 2
message 1
loop
condition
message2
57
Sequence diagrams, example iteration of a single
message
Simulator
Random
runSimulation()
loop
i1..N
numgetNextInt
58
Sequence diagrams, iteration over a collection
59
Example, iteration of a single message
Course
Student
loop
till all deregistered from all courses
deregister(arglist.)
60
Sequence diagrams, iteration over a collection
ID 434356
Gudrun Schyman
4309025689 Gudrun Schyman 132 reads
61
Sequence diagrams, iteration of a series of
messages
Old notation
Object 1
Object 2
Object 3
message 1
message2
message3
condition
The messages inside the box are iterated till
the iteration condition is fulfilled.
62
Sequence diagrams, iteration of a series of
messages
Object 1
Object 2
Object 3
message 1
condition
loop
message2
message3
The messages inside the box are iterated till
the iteration condition is fulfilled.
63
Class diagram
Student/Course Record
ready Yes/No check if ready(arglist)
course record
student record
Student
Course
.. register(arglist) remove_course deregister
qualif_requirements String register(arglist) lis
t qualif requir (arglist) deregister() remove_stud
ent()
reads
64
Sequence diagrams, iteration of a series of
messages
ID 954032
Gudrun/ Polish Record
. .. ..
ID 44000122
Course in Polish
PPP234 Polski 12 Adamski
ID 234384636
Course in Statistics
ABC123 Statistics 25 Persson
ID 664343
Gudrun/ Statistics Record
. .. ..
65
Example, iteration of a series of messages
Student/Course Record
course record
ready Yes/No check if ready(arglist)
student record
Student
Course
.. register(arglist) remove_course deregister
qualif_requirements String register(arglist) lis
t qualif requir (arglist) deregister() remove_stud
ent()
reads
Course in Polish
Gudrun/Polish record
Course
Student
records 0
loop
deregister(arglist)
destroy student/course record (arglist)
X
deregister(arglist)
66
Sequence diagrams, iteration of a series of
messages
ID 954032
Gudrun/ Polish Record
. .. ..
ID 44000122
Course in Polish
PPP234 Polski 12 Adamski
ID 234384636
Course in Statistics
ABC123 Statistics 25 Persson
ID 664343
Gudrun/ Statistics Record
. .. ..
67
HejHär slutar samma material med ny notation
68
Creating sequence diagrams

• The first step is to identify classes
  participating in the sequence being modelled.
• Classes typically can be taken from the use case
  diagram.
• Add messages.
• Place lifeline.

The step of creating classes is intermingled with
adding messages and life lines.
69
Collaboration Diagram, definition
ClassE
Object name
Class name
2msg6()
msg2()
msg1()
msg 1
ClassA
ClassB
msg 2
msg 3
msg3()
msg4()
msg 4
msg 5
msg 5
object msg5()
msg1()
ClassA
ClassB
msg 7

• A collaboration diagram captures two things
• Interactions among objects, and
• Structural relationships among the objects
  involved in the interaction.

• A collaboration diagram looks like a graph or a
  network. There are no rules for how to
  graphically organise them.

70
Collaboration diagrams, notation
The first message is not numbered
message
1 message 1
Class A
Class B
2 message 2
service request
object_name sequence-number condition
message (arglist)
Class name
name Class
Class
71
Collaboration Diagram, alternative ways of
writing messages
Pelle Student
Course in Polish
register(arglist)
Pelle Student
Course in Polish
2 nativecourse_in_Polishregister(arglist)
72
Collaboration diagrams, example
Object diagram
Student
Course
ID 44000122
..
students Array register(arg1, arg2)
Course in Polish
reads
PPP234 Polski students
Class diagram
434356
ID 434356
Gudrun Schyman
register(arglist)
Student
Course
4309025689 Gudrun Schyman
Collaboration diagram
73
Collaboration diagrams, sequence numbering
first
second
1 msg()
msg()
Class A
Class B
third
These messages are nested messages
1.1 msg()
2.1 msg()
fifth
2 msg()
Class C
fourth
sixth
2.2 msg()
Class D
74
Collaboration diagrams, messages to self
message
message
Class A
Class A
message 1
1 message
2 message
75
Collaboration diagrams, self messaging, example
Object diagram
Student
Course
ID 44000122
.. register(arg1, arg2)
students Array register(arg1, arg2)
Course in Polish
reads
PPP234 Polski students
Class diagram
434356
start-reg -process (arglist)
1 register(arglist)
Student
Course
ID 434356
Gudrun Schyman
4309025689 Gudrun Schyman reads
2 register(arglist)
44000122
Collaboration diagram
76
Collaboration diagrams, creation of instances
Create message, with optional initialising
parameters. This will normally be interpreted as
a constructor call
create(arglist)
Class A
Class B
ltltcreategtgt
make(arglist)
Class A
Class B
If an unobvious creation message name is used,
the message may be stereotyped for clarity.
77
Collaboration diagrams, callbacks
1 msg()
Class B
msg()
2 msg()
Class A
callback message
3 msg()
4msg()
Class C
78
Collaboration diagrams, iteration or looping
Iteration is indicated with a and an optional
iteration clause following the sequence number
msg()
1i 1..N num nextInt()
Class A
Class B
79
Collaboration diagrams, iteration over a
collection (multiobject)
1 st getSubtotal()
t getTotal()
Class A
ClassB
Class B

These two symbols used together imply iteration
over the multiobject and sending the getSubtotal
message to each member.
Double box indicates a multiobject (collection)
80
Sequence diagrams, example
Student/Course Record
Student
Course
Student/Course Record
register(arglist)
list qualification requirements(arglist)
check if ready(arglist)
register(arglist)
create student/course record(arglist)
confirm registr(arglist)
register(arglist)
81
Collaboration diagrams,
example creating new objects, sequence
numbering, callbacks, iteration
Student/Course Record
ready Yes/No check if ready(arglist)
course record
student record
Student
Course
.. register(arglist)
qualif_requirements String register(arglist,) li
st qualif requir (arglist) register()
reads
82
Sequence diagrams,
example creating new objects
OID 45985776
Course in Linguistics
OID 888999
PPP234 Linguistics Students Student record
Gudrun/Linguistics Record
434356
ready Yes check if ready(arglist)
888999
OID 434356
Gudrun Schyman
4309025689 Gudrun Schyman Reads course record
44000122
888999
888955
OID 44000122
Course in Polish
PPP234 Polski Students Student rec
434356
888955
83
Collaboration versus sequence diagrams

Student
Course
Student/Course Record
register(arg1, arg2)
list qualification requirements(arglist)
check if ready(arglist)
create(arglist)
register(arglist)
register(arglist)
1 register(arglist)
start-reg -process (arglist)
Student
Course
2 list qualification requirements(arglist)
5 register()
6 register (arglist)
4 create (arglist)
3check if ready(arglist)
Student/Course Record
84
GRASP The Low Coupling pattern

• Pattern Name Low Coupling
• Problem How to reduce the impact of change
• Solution Assign a responsibility so that
  (unnecessary) coupling remains low.

• Coupling describes the degree of
  interconnectedness between design components
• It is reflected by the number of links an object
  has and by the degree of interaction the object
  has with other objects
• Coupling should be kept to a minimum

85
GRASP Low coupling example

• Who should be responsible for creating a Payment
  and associating it with a Sale?

Payment amount
Sale date time
Register
Paid-by
Captures
1
1
1
1
makePayment()
1.create()
pPayment
Register
2addPayment(p)
Sale
Is this the best possible design? How many
objects are related to (coupled with) the
Register object? Can we achieve lower coupling?
86
GRASP Low coupling
Register is now coupled with objects of one class
(Sale). If the class Payment is modified, only
Sale will be affected. This design is preferred
because it provides lower coupling between
classes.
Undesired coupling of Register to Payment
Sale creates Payment, which does not increase the
overall coupling of the model
87
Discussion about Low Coupling

• Common forms of coupling from TypeX to TypeY
  include
• TypeX has an attribute that refers to a TypeY
  instance
• TypeX calls on services of a TypeY object
• TypeX has a method that references an instance of
  TypeY, or TypeY itself
• TypeX is a direct or indirect subclass of TypeY
• ..
• Low coupling supports the design of classes that
  are more independent gt reduces impact of change

88
GRASP The High Cohesion pattern

• Pattern Name High Cohesion
• Solution Assign a responsibility so that
  cohesion remains high.
• Problem It Solves How to keep complexity
  manageable?

• Cohesion is a measure of the degree to which an
  element contributes to a single purpose
• The concepts of coupling and cohesion are not
  mutually exclusive but actually support each other

89
The Cohesion example
playGame()
MonopolyGame

• A class with high cohesion has a relatively small
  number of methods, with highly related
  functionality, and does not do too much work.
• Benefits of high cohesion Easy maintenance.
  Classes easy to understand, Software reuse

playGame()
MonopolyGame
??
??
??
doA
doB
doC
90
GRASP The Controller pattern

• Pattern Name Controller
• Solution Assign the responsibility for
  receiving or handling a system event message to a
  class representing one of the following choices
• Represents the overall system, device, or
  subsystem (facade controller)
• Represents a use case scenario within which the
  system event occurs, often named
  ltUseCasegtHandler, ltUseCasegt Coordinator, or
  ltUseCasegtSession (use-case or session
  controller)
• Problem It Solves Who should be responsible for
  handling an input system event?

91
Controller example

• Who should be responsible of handling external
  system events (e.g. enterItem)? Which of the
  following interaction diagrams is preferred?

enterItem(it, qty)
Sale
enterItem(it, qty)
ProcessSaleHandler
Often, some event is initiated from a source
outside of the system you are building. Your
system will have some class that receives the
event,.
92
Controller

• Often, some event is initiated from a source
  outside of the system you are building.

Which class of object should be responsible for
receiving this system event message?

• There is a tendency to use user interface
  objects, such as windows, frames, and so on, as
  controller objects.
• This is a poor choice because it weakens the
  cohesion of the class, and usually results in
  increased coupling.
• System operations should be handled at the domain
  layer, not at the interface layer by GUI objects.
  But, which object should handle them?

93
Applying Controller

• Your system will have some class that receives
  the event, but that does not necessarily mean
  that it should handle the event.

• These events should be handled by classes
  representing a use case scenario within which the
  system event occurs.

ProcessSaleHandler

• These are often named ltusecasenamegtHandler,
  ltusecase-namegtController, ltusecasenamegtManager,
  ltusecasenamegtSession and so forth.

94
Discussion about the Controller

• Every system should have a controller
• A controller is class whose job it is to
  coordinate the system events.
• It sees to it that the messages are sent to the
  correct expert in the model
• The reason to have a controller is to separate
  domain objects from the view (GUI) objects.
• This is often called a MVC (Model View
  Controller)
• Advantage - is that the changes to the model
  (domain) do not affect the GUI (view) objects
• MVC builds systems that are maintainable
• By using a separate control object, it affords a
  better layering to the architecture.

95
GRASP Pure Fabrication
Pattern Name Pure Fabrication Problem What
objects should have the responsibility, when you
do not want to violate High Cohesion and Low
Coupling, or other goals, but solutions offered
by Expert (for example) are not
appropriate? Solution Assign a highly cohesive
set of responsibilities to an artificial or
convenience class that does not represent a
problem domain concept something made up to
support high cohesion, low coupling, and reuse.
96
Pure Fabrication example

• We need to save Sale instances in a relational
  database.
• By Expert, there is some justification to assign
  this responsibility to Sale class.

• However
• The task requires a relatively large number of
  supporting database-oriented operations and the
  Sale class becomes incohesive.
• The sale class has to be coupled to the
  relational database increasing its coupling.
• Placing these responsibilities in the Sale class
  suggests there is going to be poor reuse or lots
  of duplication in other classes that do the same
  thing.  
•  

97
Pure Fabrication

• Problem
• Not to violate High Cohesion and Low Coupling?
• Solution
• Assign a highly cohesive set of responsibilities
  to an artificial class that does not represent
  anything in the problem domain, in order to
  support high cohesion, low coupling, and reuse.

98
Solution

• Saving objects in a relational database is a very
  general task for which many classes need support.
  
• Make up an arbitrary behavior class, whose name
  is not necessarily inspired by the domain
  vocabulary.
• This is a compromise that often has to be made to
  preserve cohesion and low coupling
• Remember the software is not designed to
  simulate the domain, but operate in it
• The software does not always have to be identical
  to the real world
• High cohesion is supported because
  responsibilities are factored into a class that
  only focuses on a very specific set of related
  tasks.
• Reuse potential is increased because of the
  presence of fine grained Pure Fabrication and
  Sale classes.

99
GRASP Polymorphism pattern

• Pattern Name Polymorphism
• Problem How to handle alternative behaviors
  based on type?
• Solution When related alternatives or behaviors
  vary by type (class), dont use conditional
  logic, but assign the same name to services
  (methods) in different classes.
• The different classes usually implement a common
  interface or are related in an implementation
  hierarchy with a common superclass (this is
  language-dependent)

100
Polymorphism, Solution 1
A bank account that the account holder can draw
checks against without giving prior notice
This account requires funds to be kept on deposit
for a minimum length of time,
Checking Account
Savings Account
getSavAccInterest()
getCheckAccinterest()

• Example
• Consider a bank application with two types of
  accounts CheckingAccount and SavingsAccount.
• Suppose that you want to evaluate for each
  account the interest accumulated over a period.
• The implementation of evaluating interest is
  different for each account type. It uses a
  different set of interest rates.

101
Polymorphism Solution 2
Account
Checking Account
Savings Account
getSavAccInterest()
getCheckAccinterest()

• Solution 2 Same as Solution 1, but
  SavingsAccount and CheckingAccount have the same
  superclass Account.
• Go through all objects of class Account. If an
  object is of subclass SavingsAccount, invoke
  getSavAccInterest(), else invoke
  getChAccInterest()

102
Polymorphism Solution 3
Account
getInterest()
Checking Account
Savings Account

• Solution 3 Class SavingsAccount with method
  getInterest(startDate, endDate), and class
  CheckingAccount with method getInterest(startDate,
  endDate) inherit from a common superclass with
  method getInterest(startDate, endDate).
• Go through all objects of class Account. Invoke
  their method getInterest()

103
Polymorphism

• New variations easy to add without affecting the
  client
• Easier and more reliable then using explicit
  selection logic - If-then-else used to handle
  type variations
• Another typical example draw() for Square,
  Circle, Triangle, etc.
• Easier to add additional behaviours later on
• Increased the number classes in a design
• May make the code less easier to follow