Object Oriented Design (OOD)
in software industry
Available at www.elfuchs.com
Emmanuel FUCHS

Why OOD ?
Design for changes
Procedural Oriented Design (POD) VS Object
Oriented Design (OOD)
Procedural Oriented Design
Object Oriented Design
Design Pattern
31/03/03
2

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

Changes Request : flexible solution
Productive
Initial Request programmer
1 Day
After
Unproductive
programmer
1 Week
After
31/03/03
4

Changes Request : flexible solution
Productive
Initial Request Evolution
programmer
Request
1 Day
After
Unproductive
programmer
1 Week
After
31/03/03
5

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

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

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

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

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

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

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

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

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

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

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

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

User Input
Operation:
A: Addition
B: Subtraction
C: Division
E: Multiplication
Enter a choice =>
31/03/03
18

User Input
Operation: Addition
A: First Integer
B: Second Integer
Enter a choice =>
31/03/03
19

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

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

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

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

User Input : Operation in R and C
Operation:
A: Real
B: Complex
Enter a choice =>
31/03/03
24

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

Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
26

Changes Request : flexible solution
Initial Request Evolution Request
1 Day Few Weeks Later
After
1 Week 1 Day
After After
31/03/03
27

Hierarchical, Structural Programming, “Top Down”
Reuse of Real operations for Complex Operations
Procedures
31/03/03
28

Hierarchical, Structural Programming, “Top Down”
Reuse of Real operations for Complex Operations
Procedures
31/03/03
29

Hierarchical, Structural Programming, “Top Down”
Reuse of Real operations for Complex Operations
Procedures
Spaghetti Plate
31/03/03
30

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

State and Procedure dichotomy
State Procedures
31/03/03
32

State and Procedure dichotomy
State Procedures
31/03/03
33

State and Procedure dichotomy
State Procedures
Spaghetti Plate
31/03/03
34

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

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.

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.

Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
38

Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
39

Object analogy
A driver doesn't care of
engine's internal working.
He only knows the interface
Implementation Interface
31/03/03
40

Polymorphism
Interface
(specification) Implementation
(body)
31/03/03
41

Object Interface
UML class
Client Name
Operation
Operation
Operation
Operation
Attribute
Object Interface
31/03/03
42

Object Interface and Implementation
UML class
Client Name
Operation
Operation
Operation
Operation
Attribute
Object Interface
31/03/03
Interface Implementation
43

Object Interface and Implementation
UML class
Client Name
Operation
Operation
Operation
Operation
Attribute
Object Interface
31/03/03
Interface Implementation
44

Object collaboration
31/03/03
45

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

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

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

Replace case and enum by object .
enum Color {
Black,
Brown,
Red,
Orange,
Yellow,
Green,
Blue,
}
31/03/03
49

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

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

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

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

Replace case and enum by object .
enum Color {
Black,
Brown,
Red,
Orange,
Yellow,
Green,
Blue,
NewColor,
}
31/03/03
54

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 }

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

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

Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
58

Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later ?
1 Week 1 Day
After After
31/03/03
59

The object solution
Polymorphism
31/03/03
60

Polymorphism
Print()
Client Color
+print()
31/03/03
61

Polymorphism
Print()
Client Color
+print()
No Changes
Black
+ print()
31/03/03
62

Polymorphism
Print()
Client Color
+print()
No Changes
Black Brown
+ print() + print()
31/03/03
63

Polymorphism
Print()
Client Color
+print()
No Changes
Black Brown Red Blue
+ print() + print() + print() + print()
31/03/03
64

Polymorphism
Print()
Client Color
+print()
No Changes
Black Brown Red Blue
+ print() + print() + print() + print()
newColor
31/03/03
+ print()
65

Object Polymorphism
Code example
31/03/03
66

Polymorphism
Print()
Client Color
+print()
31/03/03
67

Polymorphism
Print()
Client Color
+print()
Black
+ print()
31/03/03
68

Code of the Black object print() operation
class Black extends Color
{
public void print()
{
System.out.println( \" Black \"); }
}
31/03/03
69

Polymorphism
Print()
Client Color
+print()
Black Brown
+ print() + print()
31/03/03
70

Code of the Brown object print() operation
class Brown extends Color
{
public void print()
{
System.out.println( \" Brown \"); }
}
31/03/03
71

Polymorphism
Print()
Client Color
+print()
Black Brown Red Blue
+ print() + print() + print() + print()
31/03/03
72

Code of the Red object print() operation
class Red extends Color
{
public void print()
{
System.out.println( \" Red \"); }
}
31/03/03
73

Code of the Blue object print() operation
class Blue extends Color
{
public void print()
{
System.out.println( \" Blue \"); }
}
31/03/03
74

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

Polymorphism
Print()
Client Color
+print()
Black Brown Red Blue
+ print() + print() + print() + print()
31/03/03
76

Polymorphism
Print()
Client Color
+print()
No Changes
Black Brown Red Blue
+ print() + print() + print() + print()
newColor
31/03/03
+ print()
77

Code of the Blue object print() operation
class NewColor extends Color
{
public void print()
{
System.out.println( \" NewColor \"); }
}
31/03/03
78

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

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

GOF: The book cover
31/03/03
81

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

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

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

Design Pattern Catalogue
Creational Patterns
Abstract Factory
Builder
Factory Method
Prototype
Singleton
31/03/03
85

Design Pattern Catalogue
Structural Patterns
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
31/03/03
86

Design Pattern Catalogue
Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Memento
Iterator
Mediator
Observer
State
Strategy
Template Method
31/03/03
Visitor
87

Design Pattern Map
31/03/03
88

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

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

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

Factory Pattern
Print()
Client Color
+print()
UNKNOWN_EXIT
Black Brown Red _STATE
+ print() + print() + print() + print()
ColorFactory
31/03/03
+ create()
92

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

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

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

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

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

State model transformation
Client Color
Request()
31/03/03
98

State diagram
Black Orange
Request()
Request() Request()
Request()
Brown Red
31/03/03
99

structural switch
static void printsState(int state) {
switch(state) {
case Black :
System.out.println( “Black\");
break;
case Brown :
System.out.println( “Brown\");
break;
case Red :
System.out.println( “Red\");
break;
case Orange :
System.out.println( “Orange\");
break;
}
31/03/03
}
10

structural switch
static void printsState(int state) {
switch(state) {
case Black :
System.out.println( “Black\");
break;
case Brown :
System.out.println( “Brown\");
break;
case Red :
System.out.println( “Red\");
break;
Spaghetti Plate
case Orange :
System.out.println( “Orange\");
break;
}
31/03/03
}
10

State model transformation
Client Color
Request()
31/03/03
10

State model transformation
Client Context
Request()
31/03/03
10

State model transformation
Client HelloContext Color
Request() Handle()
Black Brown Orange
Handle() Handle() Handle()
31/03/03
10

State model transformation
Client HelloContext Color
Request() Handle()
Context
Concrete state
Black Brown Orange
Handle() Handle() Handle()
31/03/03
10

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

Objective
State pattern avoid structural switch
No enumeration in Java
An enumeration may be managed as a state
machine.
31/03/03
10

Next step
Model Driven Development
Code generation
31/03/03
10

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

Object Oriented Design (OOD)
in software industry
The second order polynomial example
Emmanuel FUCHS

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

Second order polynomial equation
ax + bx + c = 0
2
31/03/03
11

Second order polynomial equation roots:
− b ± b − 4 ac 2
x=
2a
31/03/03
11

Second order polynomial discriminant :
∆ = b − 4 ac 2
31/03/03
11

First iteration : find roots in R
y
X1 X2
x
31/03/03
11

Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
11

Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later
1 Week 1 Day
After After
31/03/03
11

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

Second iteration : find roots in C
j
X1 X2
x
31/03/03
11

Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
12

Changes Request : flexible solution
Initial Request Evolution Request
1 Day Few Weeks Later
After
1 Week 1 Day
After After
31/03/03
12

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
12

Third iteration : Checks Roots Interval
y
X1 X2
x
X
X X
31/03/03
12

Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
12

Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later ?
1 Week 1 Day
After After
31/03/03
12

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
12

Procedural solution
Start
Input coefficients a,b,c
Computes discriminant
Delta = b * b – 4 * a * c
>0 Discriminant
<0
Sign
=0
Computes roots Computes single root
print roots print root print no roots
31/03/03
End
12

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
12

Source code
delta = (b*b) - (4*a*c); // discrimant computation
if (delta < 0.0) {
System.out.println (\" No roots\");
}
else if (delta > 0.0) {
System.out.println (\" Two roots :\");
System.out.println (\" x1 = \" + (-b + Math.sqrt(delta))/ (2.0 * a));
System.out.println (\" x2 = \" + (-b - Math.sqrt(delta))/ (2.0 * a));
}
else {
System.out.println (“ Single root: \");
System.out.println (\" x = \" + (-b / (2.0 * a)));
}
31/03/03
12

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
13

Procedural solution
Start
Input coefficients a,b,c
Computes discriminant
Delta = b * b – 4 * a * c
>0 Discriminant
<0
Sign
=0
Computes roots Computes single root
print roots print root print no roots
31/03/03
End
13

Procedural solution Complex roots
Start
Input coefficients a,b,c
Computes discriminant
Delta = b * b – 4 * a * c
>0 Discriminant
<0
Sign
=0
Computes roots Computes double root Computes Complex roots
print roots print root print roots
31/03/03
End
13

Source code
delta = (b*b) - (4*a*c); // discrimant computation
if (delta < 0.0) {
System.out.println (\" No roots\");
}
else if (delta > 0.0) {
System.out.println (\" Two roots :\");
System.out.println (\" x1 = \" + (-b + Math.sqrt(delta))/ (2.0 * a));
System.out.println (\" x2 = \" + (-b - Math.sqrt(delta))/ (2.0 * a));
}
else {
System.out.println (“ Single root: \");
System.out.println (\" x = \" + (-b / (2.0 * a)));
}
31/03/03
13

Source code first modification
delta = (b*b) - (4*a*c); // discrimant computation
if (delta < 0.0) {
System.out.println (\" No roots\");
}
else if (delta > 0.0) {
System.out.println (\" Two roots :\");
System.out.println (\" x1 = \" + (-b + Math.sqrt(delta))/ (2.0 * a));
System.out.println (\" x2 = \" + (-b - Math.sqrt(delta))/ (2.0 * a));
System.out.println (\" Complex roots\");
System.out.println (\" x1 real part = \" + (-b / (2.0*a)));
System.out.println (\" x2 imaginary part = \" + (-b - Math.sqrt(-delta))/ (2.0*a)+ \"i\");
System.out.println (\" x2 real part = \" + (-b / (2.0*a)));
System.out.println (\" x2 imaginary part= \" + (-b - Math.sqrt(-delta))/ (2.0*a)+ \"i\");
}
else {
System.out.println (“ Single root: \");
System.out.println (\" x = \" + (-b / (2.0 * a)));
}
31/03/03
13

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
13

Functional evolution : Checks Roots Interval
y
X1 X2
x
X
X X
31/03/03
13

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

Changes Request : flexible solution
Initial Request
1 Day
After
1 Week
After
31/03/03
13

Changes Request : flexible solution
Initial Request Evolution Request
1 Day
After
Few Weeks Later ?
1 Week 1 Day
After After
31/03/03
13

Source Code
static boolean isInBetweenRoots(double x,double a,double b, double c) {
double delta, x1, x2;
delta = (b*b) - (4*a*c);
if (delta < 0.0)
return false;
else if (delta > 0.0) {
System.out.print(\"delta > 0\");
x1 = (-b + Math.sqrt(delta))/ (2.0*a);
x2 = (-b - Math.sqrt(delta))/ (2.0*a);
return (Math.abs(x1) <= Math.abs(x)) && (Math.abs(x) <= Math.abs(x2));
}
else {
x1 = -b / (2.0 * a);
return (x == x1);
}
}
31/03/03
14

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

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

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

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

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

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

Domain Model
Second Order Discriminant
Polynomial
31/03/03
14

Domain Model: Polynomial Factory
Second Order
Polynomial
Second Order
Polynomial
Factory create
Discriminant
31/03/03
14

Domain Model: Polynomial Factory
Second Order
Polynomial
Second Order
Polynomial
Factory
Discriminant
31/03/03
14

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

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

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

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

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

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

Computes root : Single Root Polynomial
void computesRoots() {
System.out.println (\" Single root: \");
System.out.println (\" x = \" + (-b / (2.0*a)));
}
31/03/03
15

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

Computes root : Two Roots Polynomial
void computesRoots() {
System.out.println (\" Two roots :\");
System.out.println (\" x1 = \" + (-b + Math.sqrt(discriminant.value()))/ (2.0*a));
System.out.println (\" x2 = \" + (-b - Math.sqrt(discriminant.value()))/ (2.0*a));
}
31/03/03
15

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

Computes root : No Root Polynomial
void computesRoots() {
System.out.println (\" No roots\");
}
31/03/03
16

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

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

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

Computes root : Complex Roots Polynomial
void computesRoots() {
System.out.println (\" Complex roots\");
System.out.println (\" x1 real part = \" + (-b / (2.0*a)));
System.out.println (\" x1 imaginary part = “
+ (-b + Math.sqrt(-discriminant.value()))/ (2.0*a)+ \"i\");
System.out.println (\" x2 real part = \" + (-b / (2.0*a)));
System.out.println (\" x2 imaginary part = “
+ (-b - Math.sqrt(-discriminant.value()))/ (2.0*a)+ \"i\");
}
31/03/03
16

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

Design Model
Second Order
Polynomial
computeRoots()
isInBetweenRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
isInBetweenRoots() isInBetweenRoots() isInBetweenRoots()
31/03/03
16

Bracket the parameter : single root
boolean isInBetweenRoots(double x) {
return (x == x1);
}
31/03/03
16

Design Model
Second Order
Polynomial
computeRoots()
isInBetweenRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
isInBetweenRoots() isInBetweenRoots() isInBetweenRoots()
31/03/03
16

Bracket the parameter : Two roots
boolean isInBetweenRoots(double x) {
return (Math.abs(x1) <= Math.abs(x)) && (Math.abs(x) <= Math.abs(x2));
}
31/03/03
16

Design Model
Second Order
Polynomial
computeRoots()
isInBetweenRoots()
Single Root Two Roots No Root
Second Order Second Order Second Order
Polynomial Polynomial Polynomial
computeRoots() computeRoots() computeRoots()
isInBetweenRoots() isInBetweenRoots() isInBetweenRoots()
31/03/03
17

Bracket the parameter : no roots
boolean isInBetweenRoots(double x) {
return false;
}
31/03/03
17

That’s it !!!
31/03/03
17

Thank You For Your Attention
Questions are welcome
Contacts :
emmanuel.fuchs@elfuchs.com
www.elfuchs.com
31/03/03
17