3. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
3
1
4. Changes Request : flexible solution
Productive
Initial Request programmer
1 Day
After
Unproductive
programmer
1 Week
After
31/03/03
4
5. Changes Request : flexible solution
Productive
Initial Request Evolution
programmer
Request
1 Day
After
Unproductive
programmer
1 Week
After
31/03/03
5
6. Changes Request : flexible solution
Productive
Initial Request Evolution
programmer
Request
1 Day
After
Unproductive
programmer
1 Week 1 Day
After After
31/03/03
6
7. Changes Request : flexible solution
Productive
Initial Request Evolution
programmer
Request
1 Day
After
Few Weeks Later
Unproductive
programmer
1 Week 1 Day
After After
31/03/03
7
8. Changes Request : flexible solution
Productive
Unproductive
Initial Request Evolution
programmer
programmer
Request
1 Day
After
Few Weeks Later
1 Week 1 Day
After After
31/03/03
8
9. Changes Request : flexible solution
Unproductive
Initial Request Evolution
programmer
Request
1 Day
After
Few Weeks Later
Productive
programmer
1 Week 1 Day
After After
31/03/03
9
10. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
10
1
11. Changes Sources During Development
Requirements :
Customers Discover What they Really Want During or at the
End of Developments
Technology
Performances Are Increasing With Time
Skill
We Learn and Understand the Problem and We Discover
the Right Solution on the Job
Short Term Politic
No Comments
31/03/03
11
12. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
12
1
13. program in the future tense.
Initial Request
Present tense 1 Day
programming After Short term
1 Week Medium to long term
Future tense
programming After
31/03/03
13
14. program in the future tense.
Initial Request Evolution Request
Present tense 1 Day
programming After
Few Weeks Later
Future tense 1 Week 1 Day
programming After After
31/03/03
14
15. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
15
1
16. Object VS Procedural
Procedural
The code solution “structure” is the problem
“structure”.
When problems “changes” the code structure
changes.
Object
The solution is based on integration and
collaboration of independent entities (component).
An entity is a code subset.
Integration and Collaboration are managed by tools
(compiler).
When the problems “changes” the collaboration
31/03/03
scheme changes not entity’s code.
16
17. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
17
1
18. User Input
Operation:
A: Addition
B: Subtraction
C: Division
E: Multiplication
Enter a choice =>
31/03/03
18
19. User Input
Operation: Addition
A: First Integer
B: Second Integer
Enter a choice =>
31/03/03
19
20. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
20
1
21. Procedural Programming
Character
Imput CH
case
CH = A CH = B CH = C
Procedure A () Procedure B () Procedure C()
case
Proc A1() Proc A2() Proc A3() Character Character
Input CH Input CH
case case
Character CH = 1 CH = 2 CH = 3 CH = 1 CH = 2
Input CH
case
CH = 1 CH = 2 CH = 3 Proc d () Proc e () Proc f () Proc g () Proc h ()
Proc a () Proc b () Proc c ()
31/03/03
21
22. Hierarchical Programming
Tapez un nom ici
Tapez un titre de fonction ici
Tapez un nom ici Tapez un nom ici Tapez un nom ici
Tapez un titre de fonction ici Tapez un titre de fonction ici Tapez un titre de fonction ici
31/03/03
22
23. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
23
1
24. User Input : Operation in R and C
Operation:
A: Real
B: Complex
Enter a choice =>
31/03/03
24
25. User Input
Operation: Complex Addition
A: First Number real part
B: First Number imaginary part
C: Second Number real part
D: Second Number imaginary part
Enter a choice =>
31/03/03
25
26. Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
26
27. Changes Request : flexible solution
Initial Request Evolution Request
1 Day Few Weeks Later
After
1 Week 1 Day
After After
31/03/03
27
31. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
31
1
35. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
35
1
36. Object Paradigm
GOF definition for object: A run-time entity that packages both data and the
procedures that operate on that data.
Object
Object
Data Operation
Operation
Operation
Operation
Operation
Operation
Operation
Operation
Attribute Interfaces
31/03/03
GoF stand for Gang of Four. It refers to the famous books of Vlisside and Co.
36 Design Patterns: Elements of Reusable Object-Oriented Software.
37. Object Paradigm
GOF definition for object: A run-time entity that packages both data and the
procedures that operate on that data.
UML class
Object
Object
Name
Data Operation
Operation Operation
Operation
Operation
Operation Operation
Operation
Operation
Operation Attribute
Operation
Operation
Attribute Interfaces
UML:
31/03/03
Unified Modelling Language
GoF stand for Gang of Four. It refers to the famous books of Vlisside and Co.
37 Design Patterns: Elements of Reusable Object-Oriented Software.
38. Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
38
39. Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
39
40. Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
40
46. OOD hides the problem space
With OOD likely to change aspects are encapsulated
and hidden to other objects.
How and What are separated
The problem : What
The solution : How
31/03/03
46
47. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
47
1
48. The problem is in the User Input
Colour
A: Black,
B: Brown,
C: Red,
D: Orange,
E: Yellow,
F: Green,
G: Blue,
Enter a colour =>
31/03/03
48
49. Replace case and enum by object .
enum Color {
Black,
Brown,
Red,
Orange,
Yellow,
Green,
Blue,
}
31/03/03
49
50. structural switch
static void printsColor(int Value) {
switch(Value) {
case Black :
processing 1
case Brown:
processing 2
case Red:
processing 3
case Orange:
processing 4
case Yellow:
processing 5
case Green:
processing 6
case Blue:
processing 7
31/03/03
}
}
50
51. structural switch
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE:
processing 1
case FLIGHT_ACTIVATION_PROPOSAL:
static void flightUpdate(int status) { processing 2
case FLIGHT_ACTIVATION_ALARM:
switch(status) { processing 3 static void flightUpdate(int status) {
case FLIGHT_ACTIVATION_CONFIRMED:
case NIL_EXIT_STATE : processing 4 switch(status) {
processing 1 case HANDOVER_TRANSFERED,
case FLIGHT_ACTIVATION_PROPOSAL: processing 5 case NIL_EXIT_STATE :
processing 2 case COORDINATION_TERMINATED, processing 1
case FLIGHT_ACTIVATION_ALARM: processing 6 case FLIGHT_ACTIVATION_PROPOSAL:
processing 3 case UNKNOWN_EXIT_STATE processing 2
case FLIGHT_ACTIVATION_CONFIRMED: processing 7 case FLIGHT_ACTIVATION_ALARM:
processing 4 } processing 3
case HANDOVER_TRANSFERED, } case FLIGHT_ACTIVATION_CONFIRMED:
processing 5 processing 4
case COORDINATION_TERMINATED, case HANDOVER_TRANSFERED,
processing 6 processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
Software
}
}
Software Module B
Module A Software
Module D
static void flightUpdate(int status) {
Software Software
switch(status) {
case NIL_EXIT_STATE :
processing 1
Module C Module E static void flightUpdate(int status) {
switch(status) {
case FLIGHT_ACTIVATION_PROPOSAL:
processing 2 case NIL_EXIT_STATE :
case FLIGHT_ACTIVATION_ALARM: processing 1
processing 3 case FLIGHT_ACTIVATION_PROPOSAL:
case FLIGHT_ACTIVATION_CONFIRMED: processing 2
processing 4 case FLIGHT_ACTIVATION_ALARM:
case HANDOVER_TRANSFERED, processing 3
processing 5 case FLIGHT_ACTIVATION_CONFIRMED:
case COORDINATION_TERMINATED, processing 4
case HANDOVER_TRANSFERED,
processing 6
processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
31/03/03
}
}
51
52. The problem space and the solution space.
If the switch value reflects the problem for example user
inputs.
When the user request new case you have to change
everywhere you use the switch value.
31/03/03
52
53. Example 3: The problem is in the User Input
Colour
A: Black,
B: Brown,
C: Red,
D: Orange,
E: Yellow,
F: Green,
G: Blue,
H: NewColor,
Enter a colour =>
31/03/03
53
54. Replace case and enum by object .
enum Color {
Black,
Brown,
Red,
Orange,
Yellow,
Green,
Blue,
NewColor,
}
31/03/03
54
55. structural switch
static void printsColor(int Value) {
switch(Value) {
case Black :
processing 1
case Brown:
processing 2
case Red:
processing 3
case Orange:
processing 4
case Yellow:
processing 5
case Green:
processing 6
case Blue:
processing 7
case NewColor,
31/03/03
processing 7
}
55 }
56. structural switch
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE:
processing 1
case FLIGHT_ACTIVATION_PROPOSAL:
static void flightUpdate(int status) { processing 2
case FLIGHT_ACTIVATION_ALARM:
switch(status) { processing 3
case FLIGHT_ACTIVATION_CONFIRMED:
case NIL_EXIT_STATE : processing 4
processing 1 case HANDOVER_TRANSFERED,
case FLIGHT_ACTIVATION_PROPOSAL: processing 5
processing 2 case COORDINATION_TERMINATED, static void flightUpdate(int status) {
case FLIGHT_ACTIVATION_ALARM: processing 6
processing 3 case UNKNOWN_EXIT_STATE switch(status) {
case FLIGHT_ACTIVATION_CONFIRMED: processing 7
processing 4 } case NIL_EXIT_STATE :
case HANDOVER_TRANSFERED, } processing 1
processing 5 case FLIGHT_ACTIVATION_PROPOSAL:
case COORDINATION_TERMINATED, processing 2
processing 6 case FLIGHT_ACTIVATION_ALARM:
case UNKNOWN_EXIT_STATE processing 3
processing 7 case FLIGHT_ACTIVATION_CONFIRMED:
} processing 4
} case HANDOVER_TRANSFERED,
Software
processing 5
case COORDINATION_TERMINATED,
processing 6
case UNKNOWN_EXIT_STATE
Module B
processing 7
}
Software
}
Module A Software
Module D
static void flightUpdate(int status) {
Software Software
switch(status) {
case NIL_EXIT_STATE :
processing 1
Module C Module E static void flightUpdate(int status) {
switch(status) {
case FLIGHT_ACTIVATION_PROPOSAL:
processing 2 case NIL_EXIT_STATE :
case FLIGHT_ACTIVATION_ALARM: processing 1
processing 3 case FLIGHT_ACTIVATION_PROPOSAL:
case FLIGHT_ACTIVATION_CONFIRMED: processing 2
processing 4 case FLIGHT_ACTIVATION_ALARM:
case HANDOVER_TRANSFERED, processing 3
processing 5 case FLIGHT_ACTIVATION_CONFIRMED:
case COORDINATION_TERMINATED, processing 4
case HANDOVER_TRANSFERED,
processing 6
processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
Changes
31/03/03
}
}
56
57. structural switch
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE:
processing 1
case FLIGHT_ACTIVATION_PROPOSAL:
static void flightUpdate(int status) { processing 2
case FLIGHT_ACTIVATION_ALARM:
switch(status) { processing 3
case FLIGHT_ACTIVATION_CONFIRMED:
case NIL_EXIT_STATE : processing 4
processing 1 case HANDOVER_TRANSFERED,
case FLIGHT_ACTIVATION_PROPOSAL: processing 5
processing 2 case COORDINATION_TERMINATED, static void flightUpdate(int status) {
case FLIGHT_ACTIVATION_ALARM: processing 6
processing 3 case UNKNOWN_EXIT_STATE switch(status) {
case FLIGHT_ACTIVATION_CONFIRMED: processing 7
processing 4 } case NIL_EXIT_STATE :
case HANDOVER_TRANSFERED, } processing 1
processing 5 case FLIGHT_ACTIVATION_PROPOSAL:
case COORDINATION_TERMINATED, processing 2
processing 6 case FLIGHT_ACTIVATION_ALARM:
case UNKNOWN_EXIT_STATE processing 3
processing 7 case FLIGHT_ACTIVATION_CONFIRMED:
} processing 4
} case HANDOVER_TRANSFERED,
Software
processing 5
case COORDINATION_TERMINATED,
processing 6
case UNKNOWN_EXIT_STATE
Module B
processing 7
}
Software
}
Module A Software
Module D
Software Software
Spaghetti Plate
static void flightUpdate(int status) {
switch(status) {
case NIL_EXIT_STATE :
processing 1
Module C Module E static void flightUpdate(int status) {
switch(status) {
case FLIGHT_ACTIVATION_PROPOSAL:
processing 2 case NIL_EXIT_STATE :
case FLIGHT_ACTIVATION_ALARM: processing 1
processing 3 case FLIGHT_ACTIVATION_PROPOSAL:
case FLIGHT_ACTIVATION_CONFIRMED: processing 2
processing 4 case FLIGHT_ACTIVATION_ALARM:
case HANDOVER_TRANSFERED, processing 3
processing 5 case FLIGHT_ACTIVATION_CONFIRMED:
case COORDINATION_TERMINATED, processing 4
case HANDOVER_TRANSFERED,
processing 6
processing 5
case UNKNOWN_EXIT_STATE case COORDINATION_TERMINATED,
processing 7 processing 6
} case UNKNOWN_EXIT_STATE
} processing 7
Changes
31/03/03
}
}
57
58. Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
58
59. Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later ?
1 Week 1 Day
After After
31/03/03
59
67. Polymorphism
Print()
Client Color
+print()
31/03/03
67
68. Polymorphism
Print()
Client Color
+print()
Black
+ print()
31/03/03
68
69. Code of the Black object print() operation
class Black extends Color
{
public void print()
{
System.out.println( quot; Black quot;); }
}
31/03/03
69
70. Polymorphism
Print()
Client Color
+print()
Black Brown
+ print() + print()
31/03/03
70
71. Code of the Brown object print() operation
class Brown extends Color
{
public void print()
{
System.out.println( quot; Brown quot;); }
}
31/03/03
71
72. Polymorphism
Print()
Client Color
+print()
Black Brown Red Blue
+ print() + print() + print() + print()
31/03/03
72
73. Code of the Red object print() operation
class Red extends Color
{
public void print()
{
System.out.println( quot; Red quot;); }
}
31/03/03
73
74. Code of the Blue object print() operation
class Blue extends Color
{
public void print()
{
System.out.println( quot; Blue quot;); }
}
31/03/03
74
75. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
75
1
76. Polymorphism
Print()
Client Color
+print()
Black Brown Red Blue
+ print() + print() + print() + print()
31/03/03
76
77. Polymorphism
Print()
Client Color
+print()
No Changes
Black Brown Red Blue
+ print() + print() + print() + print()
newColor
31/03/03
+ print()
77
78. Code of the Blue object print() operation
class NewColor extends Color
{
public void print()
{
System.out.println( quot; NewColor quot;); }
}
31/03/03
78
79. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
79
1
80. GOF
GoF stand for Gang of Four.
It refers to the pattern seminal book of John Vlissides,
Erich Gamma, Richard Helm, Ralph Johnson:
Title: Design Patterns: Elements of Reusable Object-
Oriented Software.
31/03/03
80
82. Design Pattern GOF Definition
A design pattern systematically names, motivates, and explains a
general design that addresses a recurring design problem in
object-oriented systems.
It describes the problem, the solution, when to apply the solution,
and its consequences.
It also gives implementation hints and examples.
The solution is a general arrangement of objects and classes that
solve the problem.
The solution is customized and implemented to solve the problem
in a particular context.
31/03/03
82
83. Why Design Pattern ?
Because we want to use polymorphism to manage
the changes
But it is very difficult to find the object class lattice
which leads to polymorphism
Design pattern Language is a catalogue of object
class lattices which handle a certain problem with
polymorphism.
31/03/03
83
84. What to Expect from Design Patterns
A Common Design Vocabulary
A Documentation and Learning Aid
An Adjunct to Existing Methods
A Target for Refactoring
Anti pattern are also useful.
31/03/03
84
89. What to Expect from Design Patterns
A Common Design Vocabulary
A Documentation and Learning Aid
An Adjunct to Existing Methods
A Target for Refactoring
Anti pattern are also useful.
31/03/03
89
90. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
90
1
91. The GOF Abstract Factory Design Pattern
*GoF stand for Gang of Four. It refers to the famous books of John Vlissides, Erich Gamma, Richard Helm,
31/03/03
Ralph Johnson. Design Patterns: Elements of Reusable Object-Oriented Software.
91
92. Factory Pattern
Print()
Client Color
+print()
UNKNOWN_EXIT
Black Brown Red _STATE
+ print() + print() + print() + print()
ColorFactory
31/03/03
+ create()
92
93. Factory Pattern
The switch is now hidden in the object state factory.
The factory returns a new object of the right derived
class by using a switch case on the state integer
code.
The client always sees the root class object type
Color.
Each state object know how to manage client
invocation in its case.
31/03/03
93
94. Factory pseudo code
static color create(int Color) {
switch(Color) { New Object
case Black :
return color = new black();
break;
case Brown:
return color = new brown();
break;
case Red:
return color = new red();
break;
case Orange :
return color = new Orange();
break;
case Yellow:
return color = new Yellow();
break;
case Green :
return color = new Green();
break;
case Blue :
31/03/03
return color = new Blue();
}
}
94
95. OOD in software industry
Design for changes
Sources of Change
Designing and programming in future tense
Procedural Oriented Design (POD) VS Object Oriented Design (OOD)
Procedural Oriented Design
Design The Problem Statement
Consequence of Problem Statement change
State and Procedure Dichotomy
Object Oriented Design
Integrate State and Procedure
Design A Solution Statement
No Consequence of Problem Statement change
GOF Design Pattern
Factory
31/03/03
State pattern
95
1
96. Dynamic Polymorphism
Static polymorphism (Factory)
State machine
Pattern State creates one object for each state and
uses polymorphism to enable transparent client
invocation.
Dynamic Polymorphism
31/03/03
96
97. State Pattern (from the GoF)
31/03/03
GoF stand for Gang of Four. It refers to the famous books of Vlisside and Co.
Design Patterns: Elements of Reusable Object-Oriented Software.
97
104. State model transformation
Client HelloContext Color
Request() Handle()
Black Brown Orange
Handle() Handle() Handle()
31/03/03
10
105. State model transformation
Client HelloContext Color
Request() Handle()
Context
Concrete state
Black Brown Orange
Handle() Handle() Handle()
31/03/03
10
106. Polymorphism and state patterns
If we have an object which state can change during
its lifetime and we have to perform different
operations according to the object state we use the
pattern state.
pattern State avoids switch even if the state of the
object is changing
pattern State creates one object for each state and
uses polymorphism to enable transparent client
invocation.
31/03/03
10
107. Objective
State pattern avoid structural switch
No enumeration in Java
An enumeration may be managed as a state
machine.
31/03/03
10
108. Next step
Model Driven Development
Code generation
31/03/03
10
109. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
10
110. Object Oriented Design (OOD)
in software industry
The second order polynomial example
Emmanuel FUCHS
111. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
11
137. Checks Roots Interval : procedural solution
Discriminat
Sign
>0 <0
=0
Computes root case 1 Computes roots case 2 2
T F T F
( /X1/ <= X & X <=
X == X1
/X2/ )
Return True Return False Return True Return False Return False
End
31/03/03
13
138. Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
13
139. Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later ?
1 Week 1 Day
After After
31/03/03
13
141. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
14
142. First Object Model : Domain Model
Second Order
Polynomial
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
31/03/03
14
143. First Object Model : Domain Model
Second Order
Polynomial Discriminant
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
31/03/03
14
144. First Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
14
145. Design Model Creation without Factory
Second Order
Polynomial
computeRoots()
create()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
14
146. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
14
147. Domain Model
Second Order Discriminant
Polynomial
31/03/03
14
148. Domain Model: Polynomial Factory
Second Order
Polynomial
Second Order
Polynomial
Factory create
Discriminant
31/03/03
14
149. Domain Model: Polynomial Factory
Second Order
Polynomial
Second Order
Polynomial
Factory
Discriminant
31/03/03
14
150. First Design Model with operation
Second Order
Polynomial
Double a
Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
151. Discriminant
class Discriminant {
private double delta;
public Discriminant (double a, double b, double c) {
delta = (b * b) - (4.0 * a * c);
}
public double value () {
return delta;
}
}
31/03/03
15
152. Factory: Initial Requirements
static Polynome create( double a, double b, double c) {
Discriminant theDiscriminant = new Discriminant(a,b,c);
double delta = theDiscriminant.value();
Polynome polynome;
if (delta == 0.0) {
return polynome = new SingleRootPolynome(a,b,c,theDiscriminant) ;
}
else if (delta > 0.0) {
return polynome = new TwoRootsPolynome(a,b,c,theDiscriminant) ;
}
else {
return polynome = new NoRootPolynome(a,b,c,theDiscriminant);
}
}
31/03/03
15
153. Factory 1° Requirements Change
static Polynome create( double a, double b, double c) {
Discriminant theDiscriminant = new Discriminant(a,b,c);
double delta = theDiscriminant.value();
Polynome polynome;
if (delta == 0.0) {
return polynome = new SingleRootPolynome(a,b,c,theDiscriminant) ;
}
else if (delta > 0.0) {
return polynome = new TwoRootsPolynome(a,b,c,theDiscriminant) ;
}
else {
return polynome = new ComplexRootsPolynome(a,b,c,theDiscriminant);
}
}
31/03/03
15
154. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
15
155. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
156. Computes root : Single Root Polynomial
void computesRoots() {
System.out.println (quot; Single root: quot;);
System.out.println (quot; x = quot; + (-b / (2.0*a)));
}
31/03/03
15
157. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
159. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
15
160. Computes root : No Root Polynomial
void computesRoots() {
System.out.println (quot; No rootsquot;);
}
31/03/03
16
161. Second order polynomial
The problem
1° requirements change
2° requirements change
Procedural solution
Initial requirements
1° requirements change
2° requirements change
Object Solution
Polynomial Factory
Initial requirements
1° requirements change
31/03/03
2° requirements change
1
16
162. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
16
163. Design Model with operation
Second Order
Polynomial
Double a Discriminant
Double b
Double c
computeRoots()
Single Root Two Roots Complex Roots
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
31/03/03
16