DCI - Data, Context and Interaction @ Jug Lugano May 2011

  • 2,075 views
Uploaded on

My personal take on the Data, Context and Interaction best practice.

My personal take on the Data, Context and Interaction best practice.

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,075
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
63
Comments
0
Likes
1

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. DCI Data, Context and Interaction Fabrizio Giudici, Senior Java Architect Tidalwave s.a.s - fabrizio.giudici@tidalwave.itWednesday, May 18, 2011
  • 2. About the speaker DCI 2Wednesday, May 18, 2011
  • 3. About the speaker • Senior Software Architect, Mentor, Technical Writer • Fourteen years of Java experience (JSE, JEE, JME, etc...) • Sun partner since 1998, Oracle consultant since 2010 • Author of a number of open source projects • Speaker at JavaOne, Devoxx, Jazoon, JAX and other events • Member of the NetBeans Dream Team • Co-leader of JUG Milano • Java.Net blogger at http://www.java.net/blogs/fabriziogiudici DCI 2Wednesday, May 18, 2011
  • 4. Agenda DCI 3Wednesday, May 18, 2011
  • 5. Agenda • A real world example DCI 3Wednesday, May 18, 2011
  • 6. Agenda • A real world example • DCI - Basic concepts DCI 3Wednesday, May 18, 2011
  • 7. Agenda • A real world example • DCI - Basic concepts • DCI - How to implement? DCI 3Wednesday, May 18, 2011
  • 8. Agenda • A real world example • DCI - Basic concepts • DCI - How to implement? • Some simple examples DCI 3Wednesday, May 18, 2011
  • 9. A real world exampleWednesday, May 18, 2011
  • 10. Shameless Plug DCI 5Wednesday, May 18, 2011
  • 11. Shameless Plug • Exercises of Design - my design book... DCI 5Wednesday, May 18, 2011
  • 12. Shameless Plug • Exercises of Design - my design book... • Just started! DCI 5Wednesday, May 18, 2011
  • 13. Shameless Plug • Exercises of Design - my design book... • Just started! • http://exercisesofdesign.java.net DCI 5Wednesday, May 18, 2011
  • 14. The Observation API • A core component of blueBill Mobile • An application about recording bird observations • Designed with a high degree of abstraction DCI 6Wednesday, May 18, 2011
  • 15. The Observation API • A core component of blueBill Mobile • An application about recording bird observations • Designed with a high degree of abstraction DCI 6Wednesday, May 18, 2011
  • 16. The Observation API • A core component of blueBill Mobile • An application about recording bird observations • Designed with a high degree of abstraction DCI 6Wednesday, May 18, 2011
  • 17. DCI 7Wednesday, May 18, 2011
  • 18. The Taxonomy API • Models the taxonomy of a philogenetic tree • The standard way of biology for representing (bird) species DCI 8Wednesday, May 18, 2011
  • 19. DCI 9Wednesday, May 18, 2011
  • 20. So, what about a Bird? DCI 10Wednesday, May 18, 2011
  • 21. So, what about a Bird? • Both a Taxon and an Observable DCI 10Wednesday, May 18, 2011
  • 22. So, what about a Bird? • Both a Taxon and an Observable • Multiple inheritance? DCI 10Wednesday, May 18, 2011
  • 23. So, what about a Bird? • Both a Taxon and an Observable • Multiple inheritance? • Multiple interface implementation? DCI 10Wednesday, May 18, 2011
  • 24. So, what about a Bird? • Both a Taxon and an Observable • Multiple inheritance? • Multiple interface implementation? • Composition DCI 10Wednesday, May 18, 2011
  • 25. So, what about a Bird? • Both a Taxon and an Observable • Multiple inheritance? • Multiple interface implementation? • Composition • Taxon and Observable are roles DCI 10Wednesday, May 18, 2011
  • 26. So, what about a Bird? • Both a Taxon and an Observable • Multiple inheritance? • Multiple interface implementation? • Composition • Taxon and Observable are roles • A Bird, in some contexts, could be a Taxon and/or an Observable DCI 10Wednesday, May 18, 2011
  • 27. DCI - Basic ConceptsWednesday, May 18, 2011
  • 28. Data, Context and Interaction DCI 12Wednesday, May 18, 2011
  • 29. Data, Context and Interaction • OOD best practice formalized by Trygve Reenskaug DCI 12Wednesday, May 18, 2011
  • 30. Data, Context and Interaction • OOD best practice formalized by Trygve Reenskaug • The formalizer of MVC DCI 12Wednesday, May 18, 2011
  • 31. Data, Context and Interaction • OOD best practice formalized by Trygve Reenskaug • The formalizer of MVC • Seen by somebody as an evolution of MVC DCI 12Wednesday, May 18, 2011
  • 32. Data, Context and Interaction • OOD best practice formalized by Trygve Reenskaug • The formalizer of MVC • Seen by somebody as an evolution of MVC • But it doesn’t replace it DCI 12Wednesday, May 18, 2011
  • 33. Data, Context and Interaction • OOD best practice formalized by Trygve Reenskaug • The formalizer of MVC • Seen by somebody as an evolution of MVC • But it doesn’t replace it • It rather broadens the analysis scope DCI 12Wednesday, May 18, 2011
  • 34. Data, Context and Interaction • OOD best practice formalized by Trygve Reenskaug • The formalizer of MVC • Seen by somebody as an evolution of MVC • But it doesn’t replace it • It rather broadens the analysis scope • http://www.artima.com/articles/dci_vision.html DCI 12Wednesday, May 18, 2011
  • 35. DCI - aims DCI 13Wednesday, May 18, 2011
  • 36. DCI - aims • Improve readability of a OO system DCI 13Wednesday, May 18, 2011
  • 37. DCI - aims • Improve readability of a OO system • Give system behaviour first-class status DCI 13Wednesday, May 18, 2011
  • 38. DCI - aims • Improve readability of a OO system • Give system behaviour first-class status • Recover readability of system properties on the whole DCI 13Wednesday, May 18, 2011
  • 39. DCI - aims • Improve readability of a OO system • Give system behaviour first-class status • Recover readability of system properties on the whole • Separate responsibilities for behaviour and domain DCI 13Wednesday, May 18, 2011
  • 40. DCI - aims • Improve readability of a OO system • Give system behaviour first-class status • Recover readability of system properties on the whole • Separate responsibilities for behaviour and domain • Behaviour: what the system does DCI 13Wednesday, May 18, 2011
  • 41. DCI - aims • Improve readability of a OO system • Give system behaviour first-class status • Recover readability of system properties on the whole • Separate responsibilities for behaviour and domain • Behaviour: what the system does • Domain: what the system is DCI 13Wednesday, May 18, 2011
  • 42. DCI - aims • Improve readability of a OO system • Give system behaviour first-class status • Recover readability of system properties on the whole • Separate responsibilities for behaviour and domain • Behaviour: what the system does • Domain: what the system is • Be close to people’s mental model DCI 13Wednesday, May 18, 2011
  • 43. DCI - Data DCI 14Wednesday, May 18, 2011
  • 44. DCI - Data • What the system is DCI 14Wednesday, May 18, 2011
  • 45. DCI - Data • What the system is • Relatively static with relations DCI 14Wednesday, May 18, 2011
  • 46. DCI - Data • What the system is • Relatively static with relations • Domain structure implemented with “conventional” classes DCI 14Wednesday, May 18, 2011
  • 47. DCI - Data • What the system is • Relatively static with relations • Domain structure implemented with “conventional” classes • Hmm... perhaps anemic classes? DCI 14Wednesday, May 18, 2011
  • 48. DCI - Data • What the system is • Relatively static with relations • Domain structure implemented with “conventional” classes • Hmm... perhaps anemic classes? • Typically it includes persistence DCI 14Wednesday, May 18, 2011
  • 49. DCI - Data • What the system is • Relatively static with relations • Domain structure implemented with “conventional” classes • Hmm... perhaps anemic classes? • Typically it includes persistence • Comes from the mental model of system stakeholders DCI 14Wednesday, May 18, 2011
  • 50. DCI - Data • What the system is • Relatively static with relations • Domain structure implemented with “conventional” classes • Hmm... perhaps anemic classes? • Typically it includes persistence • Comes from the mental model of system stakeholders • Close to the “model” in MVC DCI 14Wednesday, May 18, 2011
  • 51. DCI - Data • What the system is • Relatively static with relations • Domain structure implemented with “conventional” classes • Hmm... perhaps anemic classes? • Typically it includes persistence • Comes from the mental model of system stakeholders • Close to the “model” in MVC • E.g.: BankAccount with increase(), decrease(); no deposit() DCI 14Wednesday, May 18, 2011
  • 52. DCI - Context (and Roles) DCI 15Wednesday, May 18, 2011
  • 53. DCI - Context (and Roles) • Associated to a use case, user story, scenario, or algorithm DCI 15Wednesday, May 18, 2011
  • 54. DCI - Context (and Roles) • Associated to a use case, user story, scenario, or algorithm • Identifies objects participating in a scenario DCI 15Wednesday, May 18, 2011
  • 55. DCI - Context (and Roles) • Associated to a use case, user story, scenario, or algorithm • Identifies objects participating in a scenario • Assign to each object one or more stateless roles DCI 15Wednesday, May 18, 2011
  • 56. DCI - Context (and Roles) • Associated to a use case, user story, scenario, or algorithm • Identifies objects participating in a scenario • Assign to each object one or more stateless roles • Objects can have multiple roles at the same time DCI 15Wednesday, May 18, 2011
  • 57. DCI - Context (and Roles) • Associated to a use case, user story, scenario, or algorithm • Identifies objects participating in a scenario • Assign to each object one or more stateless roles • Objects can have multiple roles at the same time • Decompose the scenario into roles, not objects DCI 15Wednesday, May 18, 2011
  • 58. DCI - Context (and Roles) • Associated to a use case, user story, scenario, or algorithm • Identifies objects participating in a scenario • Assign to each object one or more stateless roles • Objects can have multiple roles at the same time • Decompose the scenario into roles, not objects • Contrast this with polymorphism and classic OO decomposition DCI 15Wednesday, May 18, 2011
  • 59. DCI - Context (and Roles) • Associated to a use case, user story, scenario, or algorithm • Identifies objects participating in a scenario • Assign to each object one or more stateless roles • Objects can have multiple roles at the same time • Decompose the scenario into roles, not objects • Contrast this with polymorphism and classic OO decomposition • E.g.: MoneyTransfer.{.withDraw(),.deposit()} with srcAccount and destAccount DCI 15Wednesday, May 18, 2011
  • 60. Quick terminology note DCI 16Wednesday, May 18, 2011
  • 61. Quick terminology note • Methodless role: abstract role DCI 16Wednesday, May 18, 2011
  • 62. Quick terminology note • Methodless role: abstract role • Interface, abstract class DCI 16Wednesday, May 18, 2011
  • 63. Quick terminology note • Methodless role: abstract role • Interface, abstract class • Methodful role: concrete role DCI 16Wednesday, May 18, 2011
  • 64. Quick terminology note • Methodless role: abstract role • Interface, abstract class • Methodful role: concrete role • Concrete class DCI 16Wednesday, May 18, 2011
  • 65. DCI - Interaction DCI 17Wednesday, May 18, 2011
  • 66. DCI - Interaction • What the system does DCI 17Wednesday, May 18, 2011
  • 67. DCI - Interaction • What the system does • Occurs among roles, which act as adapters among objects DCI 17Wednesday, May 18, 2011
  • 68. DCI - Interaction • What the system does • Occurs among roles, which act as adapters among objects • Roles are bound in different ways for each context DCI 17Wednesday, May 18, 2011
  • 69. DCI - Interaction • What the system does • Occurs among roles, which act as adapters among objects • Roles are bound in different ways for each context • Roles life cycle is likely to be bound to a given interaction DCI 17Wednesday, May 18, 2011
  • 70. DCI - Interaction • What the system does • Occurs among roles, which act as adapters among objects • Roles are bound in different ways for each context • Roles life cycle is likely to be bound to a given interaction • Roles should be generic DCI 17Wednesday, May 18, 2011
  • 71. DCI - Interaction • What the system does • Occurs among roles, which act as adapters among objects • Roles are bound in different ways for each context • Roles life cycle is likely to be bound to a given interaction • Roles should be generic • Interaction should be explicit given roles nature DCI 17Wednesday, May 18, 2011
  • 72. DCI - Interaction • What the system does • Occurs among roles, which act as adapters among objects • Roles are bound in different ways for each context • Roles life cycle is likely to be bound to a given interaction • Roles should be generic • Interaction should be explicit given roles nature • Hmm.... rather than emergent as in agile design? DCI 17Wednesday, May 18, 2011
  • 73. DCI - Execution Model DCI 18Wednesday, May 18, 2011
  • 74. DCI - Execution Model • The Context finds object participants DCI 18Wednesday, May 18, 2011
  • 75. DCI - Execution Model • The Context finds object participants • Then, it assigns (injects?) roles to them DCI 18Wednesday, May 18, 2011
  • 76. DCI - Execution Model • The Context finds object participants • Then, it assigns (injects?) roles to them • Roles are discovered by type (methodless roles) DCI 18Wednesday, May 18, 2011
  • 77. DCI - Execution Model • The Context finds object participants • Then, it assigns (injects?) roles to them • Roles are discovered by type (methodless roles) • Then, it triggers a method on the first role DCI 18Wednesday, May 18, 2011
  • 78. DCI - Execution Model • The Context finds object participants • Then, it assigns (injects?) roles to them • Roles are discovered by type (methodless roles) • Then, it triggers a method on the first role • Interaction goes on among other roles until the job is done DCI 18Wednesday, May 18, 2011
  • 79. Some issues DCI 19Wednesday, May 18, 2011
  • 80. Some issues • What about anemic objects? DCI 19Wednesday, May 18, 2011
  • 81. Some issues • What about anemic objects? • Perhaps not a problem considering clusters object + roles DCI 19Wednesday, May 18, 2011
  • 82. Some issues • What about anemic objects? • Perhaps not a problem considering clusters object + roles • Object schizophrenia DCI 19Wednesday, May 18, 2011
  • 83. Some issues • What about anemic objects? • Perhaps not a problem considering clusters object + roles • Object schizophrenia • Which is the identity of an object in a cluster? DCI 19Wednesday, May 18, 2011
  • 84. Some issues • What about anemic objects? • Perhaps not a problem considering clusters object + roles • Object schizophrenia • Which is the identity of an object in a cluster? • What about equals() / hashcode()? Are roles parts of identity? DCI 19Wednesday, May 18, 2011
  • 85. Some issues • What about anemic objects? • Perhaps not a problem considering clusters object + roles • Object schizophrenia • Which is the identity of an object in a cluster? • What about equals() / hashcode()? Are roles parts of identity? • Possible solution is an Identifiable role DCI 19Wednesday, May 18, 2011
  • 86. Some issues • What about anemic objects? • Perhaps not a problem considering clusters object + roles • Object schizophrenia • Which is the identity of an object in a cluster? • What about equals() / hashcode()? Are roles parts of identity? • Possible solution is an Identifiable role • Injected by context DCI 19Wednesday, May 18, 2011
  • 87. Some issues • What about anemic objects? • Perhaps not a problem considering clusters object + roles • Object schizophrenia • Which is the identity of an object in a cluster? • What about equals() / hashcode()? Are roles parts of identity? • Possible solution is an Identifiable role • Injected by context • Objects with the same identity are “equals” DCI 19Wednesday, May 18, 2011
  • 88. DCI - How to implement?Wednesday, May 18, 2011
  • 89. Implementation issues DCI 21Wednesday, May 18, 2011
  • 90. Implementation issues • Static vs dynamic DCI 21Wednesday, May 18, 2011
  • 91. Implementation issues • Static vs dynamic • Java DCI 21Wednesday, May 18, 2011
  • 92. Implementation issues • Static vs dynamic • Java • AOP, annotation-driven code generation (e.g. Qi4J) DCI 21Wednesday, May 18, 2011
  • 93. Implementation issues • Static vs dynamic • Java • AOP, annotation-driven code generation (e.g. Qi4J) • Other languages DCI 21Wednesday, May 18, 2011
  • 94. Implementation issues • Static vs dynamic • Java • AOP, annotation-driven code generation (e.g. Qi4J) • Other languages • Traits, mix-ins DCI 21Wednesday, May 18, 2011
  • 95. Implementation issues • Static vs dynamic • Java • AOP, annotation-driven code generation (e.g. Qi4J) • Other languages • Traits, mix-ins • First, acknowledge that DCI is a best practice DCI 21Wednesday, May 18, 2011
  • 96. Implementation issues • Static vs dynamic • Java • AOP, annotation-driven code generation (e.g. Qi4J) • Other languages • Traits, mix-ins • First, acknowledge that DCI is a best practice • Some languages can fit better than others DCI 21Wednesday, May 18, 2011
  • 97. Implementation issues • Static vs dynamic • Java • AOP, annotation-driven code generation (e.g. Qi4J) • Other languages • Traits, mix-ins • First, acknowledge that DCI is a best practice • Some languages can fit better than others • Frameworks might help... but they force a new nature DCI 21Wednesday, May 18, 2011
  • 98. Implementation issues • Static vs dynamic • Java • AOP, annotation-driven code generation (e.g. Qi4J) • Other languages • Traits, mix-ins • First, acknowledge that DCI is a best practice • Some languages can fit better than others • Frameworks might help... but they force a new nature • My point: DCI must be addressed in design DCI 21Wednesday, May 18, 2011
  • 99. Abstracting and sweetening • Would be nice to be technology independent • Would be nice to have some syntactic sugar • Note: not central in this presentation, but needed for code examples DCI 22Wednesday, May 18, 2011
  • 100. NetBeans Platform Lookup; as() DCI 23Wednesday, May 18, 2011
  • 101. NetBeans Platform Lookup; as() • Role role = object.getLookup().lookup(Role.class) ... DCI 23Wednesday, May 18, 2011
  • 102. NetBeans Platform Lookup; as() • Role role = object.getLookup().lookup(Role.class) ... • NetBeans Platform’s Lookup, as a bag of roles DCI 23Wednesday, May 18, 2011
  • 103. NetBeans Platform Lookup; as() • Role role = object.getLookup().lookup(Role.class) ... • NetBeans Platform’s Lookup, as a bag of roles • Allows both static implementation and dynamic injection DCI 23Wednesday, May 18, 2011
  • 104. NetBeans Platform Lookup; as() • Role role = object.getLookup().lookup(Role.class) ... • NetBeans Platform’s Lookup, as a bag of roles • Allows both static implementation and dynamic injection • Role role = object.as(Role); DCI 23Wednesday, May 18, 2011
  • 105. NetBeans Platform Lookup; as() • Role role = object.getLookup().lookup(Role.class) ... • NetBeans Platform’s Lookup, as a bag of roles • Allows both static implementation and dynamic injection • Role role = object.as(Role); • My syntactic sugar around Lookup DCI 23Wednesday, May 18, 2011
  • 106. Some examplesWednesday, May 18, 2011
  • 107. Some example reusable roles DCI 25Wednesday, May 18, 2011
  • 108. Some example reusable roles • Displayable: DCI 25Wednesday, May 18, 2011
  • 109. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); DCI 25Wednesday, May 18, 2011
  • 110. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: DCI 25Wednesday, May 18, 2011
  • 111. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: • Icon i = myObject.as(IconProvider).getIcon(16); DCI 25Wednesday, May 18, 2011
  • 112. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: “ask” approach • Icon i = myObject.as(IconProvider).getIcon(16); DCI 25Wednesday, May 18, 2011
  • 113. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: “ask” approach • Icon i = myObject.as(IconProvider).getIcon(16); “tell” approach DCI 25Wednesday, May 18, 2011
  • 114. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: “ask” approach • Icon i = myObject.as(IconProvider).getIcon(16); • Renderable: “tell” approach DCI 25Wednesday, May 18, 2011
  • 115. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: “ask” approach • Icon i = myObject.as(IconProvider).getIcon(16); • Renderable: • PrintWriter pw = ... // “tell” approach myObject.as(TextRenderable).render(pw); DCI 25Wednesday, May 18, 2011
  • 116. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: “ask” approach • Icon i = myObject.as(IconProvider).getIcon(16); • Renderable: • PrintWriter pw = ... // “tell” approach myObject.as(TextRenderable).render(pw); • JLabel label = ... // from Swing myObject.as(JLabelRenderable).render(label); DCI 25Wednesday, May 18, 2011
  • 117. Some example reusable roles • Displayable: • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: “ask” approach • Icon i = myObject.as(IconProvider).getIcon(16); • Renderable: • PrintWriter pw = ... // “tell” approach myObject.as(TextRenderable).render(pw); • JLabel label = ... // from Swing myObject.as(JLabelRenderable).render(label); • TextView textView = ... // from Swing myObject.as(TextViewRenderable).render(textView); DCI 25Wednesday, May 18, 2011
  • 118. Some example reusable roles Roles can be dynamically injected, • Displayable: so myObject does not depend on them • String s = myObject.as(Displayable).getDisplayName(); • IconProvider: “ask” approach • Icon i = myObject.as(IconProvider).getIcon(16); • Renderable: • PrintWriter pw = ... // “tell” approach myObject.as(TextRenderable).render(pw); • JLabel label = ... // from Swing myObject.as(JLabelRenderable).render(label); • TextView textView = ... // from Swing myObject.as(TextViewRenderable).render(textView); DCI 25Wednesday, May 18, 2011
  • 119. Examples from blueBill • ObservationSet set = ... ; set.as(ObservationSetTraverser) .visit(new KMLReportGenerator()); // visitor pattern • ObservationItem item = ...; TextView textView = ...; item.as(Taxon) .as(TextViewRenderable) .render(textView); DCI 26Wednesday, May 18, 2011
  • 120. Example: decorating roles DCI 27Wednesday, May 18, 2011
  • 121. Q &A • Question Time DCI 28Wednesday, May 18, 2011