Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Object Oriented for nonbelievers Bruno Bossola
About me <ul><li>C developer since 1988
Java developer since 1996
XP coach during 2000-2001
Coordinator and co-founder of JUG Torino
Sun Java Champion since 2005
Speaker at Javapolis, Jazoon, Geecon!
Running his own company! </li></ul>
Agenda <ul><li>Admit that we don't really know what Object Oriented is about
Admit that we don't really know how to execute it
Try to understand what really Object Oriented is! </li></ul>
Let's start with a problem! <ul><li>Create a payroll system
Should have a web interface
Should connect to a relational DB </li></ul>Let's start with some simple requirements!
Requirements! <ul><li>some employees are payed every two weeks, some every month
sellers are payed by a fixed amount plus a percentage on sales
some employees are paid based on the hours worked, the others receive a fixed rate
employees may choose to be payed by cheque or bank money transfe r </li></ul>
But at the end of the day... ...who cares! We need to think about the architecture! <ul><li>how do we manage web access?
how do we manage persistence? </li></ul>...isn't always like that??
Web access <ul><li>Servlet? </li></ul>
Web access <ul><li>Servlet
JSP+Taglibs? </li></ul>
Web access <ul><li>Servlet
JSP+Taglibs
Velocity? </li></ul>
Web access <ul><li>Servlet
JSP+Taglibs
Velocity
Struts2? </li></ul>
Web access <ul><li>Servlet
JSP+Taglibs
Velocity
Struts2
JSF + Ajax? </li></ul>
Web access <ul><li>Servlet
JSP+Taglibs
Velocity
Struts2
JSF + Ajax
GWT! (cool!) </li></ul>
Persistence <ul><li>JDBC? </li></ul>
Persistence <ul><li>JDBC
DAO? </li></ul>
Persistence <ul><li>JDBC
DAO
Entity Beans? </li></ul>
Persistence <ul><li>JDBC
DAO
Entity Beans
Hibernate? </li></ul>
Persistence <ul><li>JDBC
DAO
Entity Beans
Hibernate
Ibatis? </li></ul>
Persistence <ul><li>JDBC
DAO
Entity Beans
Hibernate
Ibatis
JPA!  </li></ul>
Upcoming SlideShare
Loading in …5
×

Geecon10: Object Oriented for nonbelievers

778 views

Published on

Provocative speech about Objecy Oriented, presented at <a> Geecon2010 </a>

Published in: Technology, Education
  • Really nice presentation.

    A possible reason why you might not be believed is that there is no mention of how OOP could help you implementing the DB and GUi parts .... could you create objects that separate what is not likely to change 'you will input the id of the employee and current date' from what does change 'yesterday Velocity, today GWT, tomorrow who knows...'
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Geecon10: Object Oriented for nonbelievers

  1. 1. Object Oriented for nonbelievers Bruno Bossola
  2. 2. About me <ul><li>C developer since 1988
  3. 3. Java developer since 1996
  4. 4. XP coach during 2000-2001
  5. 5. Coordinator and co-founder of JUG Torino
  6. 6. Sun Java Champion since 2005
  7. 7. Speaker at Javapolis, Jazoon, Geecon!
  8. 8. Running his own company! </li></ul>
  9. 9. Agenda <ul><li>Admit that we don't really know what Object Oriented is about
  10. 10. Admit that we don't really know how to execute it
  11. 11. Try to understand what really Object Oriented is! </li></ul>
  12. 12. Let's start with a problem! <ul><li>Create a payroll system
  13. 13. Should have a web interface
  14. 14. Should connect to a relational DB </li></ul>Let's start with some simple requirements!
  15. 15. Requirements! <ul><li>some employees are payed every two weeks, some every month
  16. 16. sellers are payed by a fixed amount plus a percentage on sales
  17. 17. some employees are paid based on the hours worked, the others receive a fixed rate
  18. 18. employees may choose to be payed by cheque or bank money transfe r </li></ul>
  19. 19. But at the end of the day... ...who cares! We need to think about the architecture! <ul><li>how do we manage web access?
  20. 20. how do we manage persistence? </li></ul>...isn't always like that??
  21. 21. Web access <ul><li>Servlet? </li></ul>
  22. 22. Web access <ul><li>Servlet
  23. 23. JSP+Taglibs? </li></ul>
  24. 24. Web access <ul><li>Servlet
  25. 25. JSP+Taglibs
  26. 26. Velocity? </li></ul>
  27. 27. Web access <ul><li>Servlet
  28. 28. JSP+Taglibs
  29. 29. Velocity
  30. 30. Struts2? </li></ul>
  31. 31. Web access <ul><li>Servlet
  32. 32. JSP+Taglibs
  33. 33. Velocity
  34. 34. Struts2
  35. 35. JSF + Ajax? </li></ul>
  36. 36. Web access <ul><li>Servlet
  37. 37. JSP+Taglibs
  38. 38. Velocity
  39. 39. Struts2
  40. 40. JSF + Ajax
  41. 41. GWT! (cool!) </li></ul>
  42. 42. Persistence <ul><li>JDBC? </li></ul>
  43. 43. Persistence <ul><li>JDBC
  44. 44. DAO? </li></ul>
  45. 45. Persistence <ul><li>JDBC
  46. 46. DAO
  47. 47. Entity Beans? </li></ul>
  48. 48. Persistence <ul><li>JDBC
  49. 49. DAO
  50. 50. Entity Beans
  51. 51. Hibernate? </li></ul>
  52. 52. Persistence <ul><li>JDBC
  53. 53. DAO
  54. 54. Entity Beans
  55. 55. Hibernate
  56. 56. Ibatis? </li></ul>
  57. 57. Persistence <ul><li>JDBC
  58. 58. DAO
  59. 59. Entity Beans
  60. 60. Hibernate
  61. 61. Ibatis
  62. 62. JPA! </li></ul>
  63. 63. A-ehm... <ul><li>Where exactly did we use Object Oriented?
  64. 64. Ah, yeah, we are using Java
  65. 65. So we are doing OO, aren't we?
  66. 66. And we are also using those cool frameworks, how can it be wrong?? </li></ul>
  67. 67. Sorry... <ul><li>...nothing about OO here </li></ul>...man, who cares!
  68. 68. Why OO was born? <ul><li>What exactly is it for?
  69. 69. Does it give us real advantages? </li></ul>
  70. 70. Why OO was born? <ul><li>allows you to mantain traceability of requirements between the different models </li></ul><ul><ul><li>analysis
  71. 71. design
  72. 72. implementation </li></ul></ul><ul><li>allows you to keep the complexity of your system low
  73. 73. allows you to describe a complex system in simple terms </li></ul>
  74. 74. What are requirements? <ul><li>the desired behaviors of the system
  75. 75. the entire set of requirements will define what the final system will do
  76. 76. they may be expressed in different forms </li></ul>
  77. 77. What is analysis? <ul><li>the act of translating requirements in terms used to describe a software system
  78. 78. from requirements you define the component that may execute the needed actions
  79. 79. in OOA those are objects and their collaborations </li></ul>
  80. 80. So OOA is... <ul><li>defining abstractions
  81. 81. defining high-level behaviors
  82. 82. ...in short terms, is what! </li></ul>
  83. 83. And OOD is...? <ul><li>based on abstractions identified during OOA, you define how the high level behaviors are delivered
  84. 84. it hides any concrete implementation
  85. 85. ...in short terms, is how! </li></ul>
  86. 86. Let's restart! <ul><li>Better start doing something!
  87. 87. Forget about the framework crap and let's do some plain old OOA and OOD!
  88. 88. No, this is not going to be easy... </li></ul>
  89. 89. UML? <ul><li>Fancy UML anyone?
  90. 90. Well, as a bonus, you will get used to it!
  91. 91. UML is not difficult, it's just... a nice way to express some concept, great way of communicating
  92. 92. As soon as you trash your UML diagrams, you're safe! </li></ul>
  93. 93. UML Basic crash course!
  94. 94. UML <ul><li>This is a class:
  95. 95. This is an object
  96. 96. This is a link </li></ul>
  97. 97. Thank you for attending the UML Basic crash course!
  98. 98. Requirement #1 <ul><li>“ some employees are payed every two weeks, some every month” </li></ul>1. Are you payed every month? 2. Yes | No
  99. 99. How do we do Analysis? <ul><li>That seems a bit over simplified :) </li></ul><ul><ul><li>We need to understand the ratio behind the requirement! </li></ul></ul><ul><li>We need to find abstractions and behaviors
  100. 100. My favourite way is to identify those things: </li><ul><li>what will not change?
  101. 101. what will probably change? </li></ul></ul>
  102. 102. Analysis #1 <ul><li>What will not change: every employee is payed based on some schedule
  103. 103. What will change: the schedule </li></ul>1. Is your pay day today ? 2. Yes | No
  104. 104. How do we do Design? <ul><li>Okay, we cannot write it like that
  105. 105. We need to “implement” the analysis model
  106. 106. My favourite way is: </li><ul><li>decouple any responsability
  107. 107. (...or apply DIP continuosly, but this is another story!) </li></ul></ul>
  108. 108. UML Break!
  109. 109. UML Break #2 horizontal relationships <ul><li>dependency nobody cares anymore :)
  110. 110. association
  111. 111. aggregation
  112. 112. composition </li></ul>
  113. 113. UML Break #2 horizontal relationships <ul><li>Identify relationships types may be tricky...
  114. 114. But let me give you a word of consolation: do you know what UML authors saId about aggregation? </li></ul>
  115. 115. UML Break #2 horizontal relationships <ul>“ ...if you don’t understand don’t use it.” talking about “aggregation”, from UML 0.8 official docs </ul>
  116. 116. Back to reality!
  117. 117. Design #1 <ul><li>It seems to me that the Employee nows about some kind of schedule
  118. 118. We need to split the responsability
  119. 119. But wait... what about code here? </li></ul>
  120. 120. Design #1 (attempt) public class PaySchedule { public static int MONTHLY = 0; public static int BIWEEKLY = 1; public int schedule; public PaySchedule (int aSchedule) {...} public boolean isPayDay(Date today) { if (schedule == MONTHLY && today...) return true; else if (schedule == BIWEEKLY && today...) return true; else return false; // doh! } }
  121. 121. Design #1 (attempt) <ul><li>Okay, I probably choose the worst method
  122. 122. But I could have made it cool! </li></ul><ul><ul><li>make schedule an inner class
  123. 123. make schedule an Enum
  124. 124. introduce an external parser in Pyton (WTF??) </li></ul></ul><ul><li>What's the problem in this design? </li></ul>
  125. 125. Design #1 (attempt) <ul><li>The s**t that I wrote is fully respecting the analysis model
  126. 126. But it's inflexible ! What if I need to add another schedule? As we agreed in analysis, the schedule may change!
  127. 127. You can definitely have a brilliant analysis model with a really poor design! </li></ul>
  128. 128. Design #1 (attempt) <ul><li>Suggestions? </li></ul>
  129. 129. Design #1 <ul><li>No if, just polymorphism!
  130. 130. This design is hiding complexity! </li></ul>
  131. 131. UML Break!
  132. 132. UML Break #3 vertical relationships <ul><li>generalization (specialization) </li></ul>
  133. 133. Back to reality!
  134. 134. Requirement #2 <ul><li>“ sellers are payed by a fixed amount plus a percentage on sales”
  135. 135. Trick: anything missing here? </li></ul>1. How much should you receive? 2. $$$!
  136. 136. Analysis #2 (attempt) <ul><li>How about the next requirement?
  137. 137. “ some employees are paid based on the hours worked, the others receive a fixed rate”
  138. 138. Ah-ha! That means that we have at least three different ways to get the salary amount!
  139. 139. This is what a BA should do </li></ul>
  140. 140. Analysis #2 / #3 <ul><li>So let's go back to the plain old way... </li><ul><li>what will not change?
  141. 141. what will probably change? </li></ul></ul>
  142. 142. Analysis #2 / #3 <ul><li>What will not change: every employee is payed
  143. 143. What will change: the amount
  144. 144. A bit of abstraction! </li></ul>1. How much should you receive? 2. $$$!
  145. 145. Design #2 / #3 <ul><li>Ok, so how each Employee will know about how much is payed?
  146. 146. Decouple!
  147. 147. There's something that is needed here! </li></ul><ul><ul><li>an abstraction
  148. 148. some implementations </li></ul></ul><ul><li>Ideas? </li></ul>
  149. 149. Design #2 / #3 <ul><li>Like it? </li></ul>
  150. 150. Analysis #4 <ul><li>“ employees may choose to be payed by cheque or bank money transfer”
  151. 151. Invariant: each employee is payed with a method
  152. 152. Variant: the method used </li></ul>
  153. 153. Design #4 <ul><li>Piece of cake! </li></ul>
  154. 154. What about NFRs? <ul><li>Non functional requirement should not pollute the analysis model
  155. 155. If possibile they should not pollute the design model as well
  156. 156. They should be handled at implementation level
  157. 157. Trick: attach web and db later :) </li></ul>
  158. 158. The end...
  159. 159. Why “for nonbelievers”?
  160. 160. Why “for nonbelievers”? <ul><li>Because you're not going to believe this
  161. 161. because I did not convince you
  162. 162. tomorrow you will start selecting the framework as usual :)
  163. 163. ...this how the world goes on! Peace :) </li></ul>
  164. 164. Q & A

×