• Like
Object Oriented Design And Programing
Upcoming SlideShare
Loading in...5
×

Object Oriented Design And Programing

  • 2,200 views
Uploaded on

Polymorphism Vs Enumerated

Polymorphism Vs Enumerated

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,200
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
421
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Object Oriented Design (OOD) in software industry Available at www.elfuchs.com Emmanuel FUCHS
  • 2. 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
  • 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
  • 28. Hierarchical, Structural Programming, “Top Down” Reuse of Real operations for Complex Operations Procedures 31/03/03 28
  • 29. Hierarchical, Structural Programming, “Top Down” Reuse of Real operations for Complex Operations Procedures 31/03/03 29
  • 30. Hierarchical, Structural Programming, “Top Down” Reuse of Real operations for Complex Operations Procedures Spaghetti Plate 31/03/03 30
  • 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
  • 32. State and Procedure dichotomy State Procedures 31/03/03 32
  • 33. State and Procedure dichotomy State Procedures 31/03/03 33
  • 34. State and Procedure dichotomy State Procedures Spaghetti Plate 31/03/03 34
  • 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
  • 41. Polymorphism Interface (specification) Implementation (body) 31/03/03 41
  • 42. Object Interface UML class Client Name Operation Operation Operation Operation Attribute Object Interface 31/03/03 42
  • 43. Object Interface and Implementation UML class Client Name Operation Operation Operation Operation Attribute Object Interface 31/03/03 Interface Implementation 43
  • 44. Object Interface and Implementation UML class Client Name Operation Operation Operation Operation Attribute Object Interface 31/03/03 Interface Implementation 44
  • 45. Object collaboration 31/03/03 45
  • 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
  • 60. The object solution Polymorphism 31/03/03 60
  • 61. Polymorphism Print() Client Color +print() 31/03/03 61
  • 62. Polymorphism Print() Client Color +print() No Changes Black + print() 31/03/03 62
  • 63. Polymorphism Print() Client Color +print() No Changes Black Brown + print() + print() 31/03/03 63
  • 64. Polymorphism Print() Client Color +print() No Changes Black Brown Red Blue + print() + print() + print() + print() 31/03/03 64
  • 65. Polymorphism Print() Client Color +print() No Changes Black Brown Red Blue + print() + print() + print() + print() newColor 31/03/03 + print() 65
  • 66. Object Polymorphism Code example 31/03/03 66
  • 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
  • 81. GOF: The book cover 31/03/03 81
  • 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
  • 85. Design Pattern Catalogue Creational Patterns Abstract Factory Builder Factory Method Prototype Singleton 31/03/03 85
  • 86. Design Pattern Catalogue Structural Patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy 31/03/03 86
  • 87. Design Pattern Catalogue Behavioral Patterns Chain of Responsibility Command Interpreter Memento Iterator Mediator Observer State Strategy Template Method 31/03/03 Visitor 87
  • 88. Design Pattern Map 31/03/03 88
  • 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
  • 98. State model transformation Client Color Request() 31/03/03 98
  • 99. State diagram Black Orange Request() Request() Request() Request() Brown Red 31/03/03 99
  • 100. structural switch static void printsState(int state) { switch(state) { case Black : System.out.println( “Blackquot;); break; case Brown : System.out.println( “Brownquot;); break; case Red : System.out.println( “Redquot;); break; case Orange : System.out.println( “Orangequot;); break; } 31/03/03 } 10
  • 101. structural switch static void printsState(int state) { switch(state) { case Black : System.out.println( “Blackquot;); break; case Brown : System.out.println( “Brownquot;); break; case Red : System.out.println( “Redquot;); break; Spaghetti Plate case Orange : System.out.println( “Orangequot;); break; } 31/03/03 } 10
  • 102. State model transformation Client Color Request() 31/03/03 10
  • 103. State model transformation Client Context Request() 31/03/03 10
  • 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
  • 112. Second order polynomial equation ax + bx + c = 0 2 31/03/03 11
  • 113. Second order polynomial equation roots: − b ± b − 4 ac 2 x= 2a 31/03/03 11
  • 114. Second order polynomial discriminant : ∆ = b − 4 ac 2 31/03/03 11
  • 115. First iteration : find roots in R y X1 X2 x 31/03/03 11
  • 116. Changes Request : flexible solution Initial Request 1 Day After 1 Week After 31/03/03 11
  • 117. Changes Request : flexible solution Initial Request Evolution Request 1 Day After Few Weeks Later 1 Week 1 Day After After 31/03/03 11
  • 118. 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
  • 119. Second iteration : find roots in C j X1 X2 x 31/03/03 11
  • 120. Changes Request : flexible solution Initial Request 1 Day After 1 Week After 31/03/03 12
  • 121. Changes Request : flexible solution Initial Request Evolution Request 1 Day Few Weeks Later After 1 Week 1 Day After After 31/03/03 12
  • 122. 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
  • 123. Third iteration : Checks Roots Interval y X1 X2 x X X X 31/03/03 12
  • 124. Changes Request : flexible solution Initial Request 1 Day After 1 Week After 31/03/03 12
  • 125. Changes Request : flexible solution Initial Request Evolution Request 1 Day After Few Weeks Later ? 1 Week 1 Day After After 31/03/03 12
  • 126. 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
  • 127. 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
  • 128. 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
  • 129. Source code delta = (b*b) - (4*a*c); // discrimant computation if (delta < 0.0) { System.out.println (quot; No rootsquot;); } else if (delta > 0.0) { System.out.println (quot; Two roots :quot;); System.out.println (quot; x1 = quot; + (-b + Math.sqrt(delta))/ (2.0 * a)); System.out.println (quot; x2 = quot; + (-b - Math.sqrt(delta))/ (2.0 * a)); } else { System.out.println (“ Single root: quot;); System.out.println (quot; x = quot; + (-b / (2.0 * a))); } 31/03/03 12
  • 130. 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
  • 131. 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
  • 132. 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
  • 133. Source code delta = (b*b) - (4*a*c); // discrimant computation if (delta < 0.0) { System.out.println (quot; No rootsquot;); } else if (delta > 0.0) { System.out.println (quot; Two roots :quot;); System.out.println (quot; x1 = quot; + (-b + Math.sqrt(delta))/ (2.0 * a)); System.out.println (quot; x2 = quot; + (-b - Math.sqrt(delta))/ (2.0 * a)); } else { System.out.println (“ Single root: quot;); System.out.println (quot; x = quot; + (-b / (2.0 * a))); } 31/03/03 13
  • 134. Source code first modification delta = (b*b) - (4*a*c); // discrimant computation if (delta < 0.0) { System.out.println (quot; No rootsquot;); } else if (delta > 0.0) { System.out.println (quot; Two roots :quot;); System.out.println (quot; x1 = quot; + (-b + Math.sqrt(delta))/ (2.0 * a)); System.out.println (quot; x2 = quot; + (-b - Math.sqrt(delta))/ (2.0 * a)); System.out.println (quot; Complex rootsquot;); System.out.println (quot; x1 real part = quot; + (-b / (2.0*a))); System.out.println (quot; x2 imaginary part = quot; + (-b - Math.sqrt(-delta))/ (2.0*a)+ quot;iquot;); System.out.println (quot; x2 real part = quot; + (-b / (2.0*a))); System.out.println (quot; x2 imaginary part= quot; + (-b - Math.sqrt(-delta))/ (2.0*a)+ quot;iquot;); } else { System.out.println (“ Single root: quot;); System.out.println (quot; x = quot; + (-b / (2.0 * a))); } 31/03/03 13
  • 135. 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
  • 136. Functional evolution : Checks Roots Interval y X1 X2 x X X X 31/03/03 13
  • 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
  • 140. 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(quot;delta > 0quot;); 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
  • 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
  • 158. Computes root : Two Roots Polynomial void computesRoots() { System.out.println (quot; Two roots :quot;); System.out.println (quot; x1 = quot; + (-b + Math.sqrt(discriminant.value()))/ (2.0*a)); System.out.println (quot; x2 = quot; + (-b - Math.sqrt(discriminant.value()))/ (2.0*a)); } 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
  • 164. Computes root : Complex Roots Polynomial void computesRoots() { System.out.println (quot; Complex rootsquot;); System.out.println (quot; x1 real part = quot; + (-b / (2.0*a))); System.out.println (quot; x1 imaginary part = “ + (-b + Math.sqrt(-discriminant.value()))/ (2.0*a)+ quot;iquot;); System.out.println (quot; x2 real part = quot; + (-b / (2.0*a))); System.out.println (quot; x2 imaginary part = “ + (-b - Math.sqrt(-discriminant.value()))/ (2.0*a)+ quot;iquot;); } 31/03/03 16
  • 165. 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
  • 166. 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
  • 167. Bracket the parameter : single root boolean isInBetweenRoots(double x) { return (x == x1); } 31/03/03 16
  • 168. 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
  • 169. 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
  • 170. 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
  • 171. Bracket the parameter : no roots boolean isInBetweenRoots(double x) { return false; } 31/03/03 17
  • 172. That’s it !!! 31/03/03 17
  • 173. Thank You For Your Attention Questions are welcome Contacts : emmanuel.fuchs@elfuchs.com www.elfuchs.com 31/03/03 17