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

1. Object Oriented for nonbelievers Bruno Bossola

3. Java developer since 1996

4. XP coach during 2000-2001

5. Coordinator and co-founder of JUG Torino

6. Sun Java Champion since 2005

7. Speaker at Javapolis, Jazoon, Geecon!

8. Running his own company!

10. Admit that we don't really know how to execute it

11. Try to understand what really Object Oriented is!

13. Should have a web interface

14. Should connect to a relational DB Let's start with some simple requirements!

16. sellers are payed by a fixed amount plus a percentage on sales

17. some employees are paid based on the hours worked, the others receive a fixed rate

18. employees may choose to be payed by cheque or bank money transfe r

20. how do we manage persistence? ...isn't always like that??

23. JSP+Taglibs?

25. JSP+Taglibs

26. Velocity?

28. JSP+Taglibs

29. Velocity

30. Struts2?

32. JSP+Taglibs

33. Velocity

34. Struts2

35. JSF + Ajax?

37. JSP+Taglibs

38. Velocity

39. Struts2

40. JSF + Ajax

41. GWT! (cool!)

44. DAO?

46. DAO

47. Entity Beans?

49. DAO

50. Entity Beans

51. Hibernate?

53. DAO

54. Entity Beans

55. Hibernate

56. Ibatis?

58. DAO

59. Entity Beans

60. Hibernate

61. Ibatis

62. JPA!

64. Ah, yeah, we are using Java

65. So we are doing OO, aren't we?

66. And we are also using those cool frameworks, how can it be wrong??

69. Does it give us real advantages?

71. design

73. allows you to describe a complex system in simple terms

75. the entire set of requirements will define what the final system will do

76. they may be expressed in different forms

78. from requirements you define the component that may execute the needed actions

79. in OOA those are objects and their collaborations

81. defining high-level behaviors

82. ...in short terms, is what!

84. it hides any concrete implementation

85. ...in short terms, is how!

87. Forget about the framework crap and let's do some plain old OOA and OOD!

88. No, this is not going to be easy...

90. Well, as a bonus, you will get used to it!

91. UML is not difficult, it's just... a nice way to express some concept, great way of communicating

92. As soon as you trash your UML diagrams, you're safe!

93. UML Basic crash course!

95. This is an object

96. This is a link

97. Thank you for attending the UML Basic crash course!

101. what will probably change?

103. What will change: the schedule 1. Is your pay day today ? 2. Yes | No

105. We need to “implement” the analysis model

107. (...or apply DIP continuosly, but this is another story!)

108. UML Break!

110. association

111. aggregation

112. composition

114. But let me give you a word of consolation: do you know what UML authors saId about aggregation?

116. Back to reality!

118. We need to split the responsability

119. But wait... what about code here?

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! } }

123. make schedule an Enum

126. But it's inflexible ! What if I need to add another schedule? As we agreed in analysis, the schedule may change!

127. You can definitely have a brilliant analysis model with a really poor design!

130. This design is hiding complexity!

131. UML Break!

133. Back to reality!

135. Trick: anything missing here? 1. How much should you receive? 2. $$$!

137. “ some employees are paid based on the hours worked, the others receive a fixed rate”

138. Ah-ha! That means that we have at least three different ways to get the salary amount!

139. This is what a BA should do

141. what will probably change?

143. What will change: the amount

144. A bit of abstraction! 1. How much should you receive? 2. $$$!

146. Decouple!

151. Invariant: each employee is payed with a method

152. Variant: the method used

155. If possibile they should not pollute the design model as well

156. They should be handled at implementation level

157. Trick: attach web and db later :)

158. The end...

159. Why “for nonbelievers”?

161. because I did not convince you

162. tomorrow you will start selecting the framework as usual :)

163. ...this how the world goes on! Peace :)

164. Q & A