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 2
Wednesday, May 18, 2011
11. Shameless Plug
• Exercises of Design - my design book...
DCI 5
Wednesday, May 18, 2011
12. Shameless Plug
• Exercises of Design - my design book...
• Just started!
DCI 5
Wednesday, May 18, 2011
13. Shameless Plug
• Exercises of Design - my design book...
• Just started!
• http://exercisesofdesign.java.net
DCI 5
Wednesday, 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 6
Wednesday, 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 6
Wednesday, 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 6
Wednesday, May 18, 2011
18. The Taxonomy API
• Models the taxonomy of a philogenetic tree
• The standard way of biology for representing (bird) species
DCI 8
Wednesday, May 18, 2011
21. So, what about a Bird?
• Both a Taxon and an Observable
DCI 10
Wednesday, May 18, 2011
22. So, what about a Bird?
• Both a Taxon and an Observable
• Multiple inheritance?
DCI 10
Wednesday, May 18, 2011
23. So, what about a Bird?
• Both a Taxon and an Observable
• Multiple inheritance?
• Multiple interface implementation?
DCI 10
Wednesday, May 18, 2011
24. So, what about a Bird?
• Both a Taxon and an Observable
• Multiple inheritance?
• Multiple interface implementation?
• Composition
DCI 10
Wednesday, 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 10
Wednesday, 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 10
Wednesday, May 18, 2011
29. Data, Context and Interaction
• OOD best practice formalized by Trygve Reenskaug
DCI 12
Wednesday, May 18, 2011
30. Data, Context and Interaction
• OOD best practice formalized by Trygve Reenskaug
• The formalizer of MVC
DCI 12
Wednesday, 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 12
Wednesday, 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 12
Wednesday, 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 12
Wednesday, 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 12
Wednesday, May 18, 2011
36. DCI - aims
• Improve readability of a OO system
DCI 13
Wednesday, May 18, 2011
37. DCI - aims
• Improve readability of a OO system
• Give system behaviour first-class status
DCI 13
Wednesday, 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 13
Wednesday, 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 13
Wednesday, 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 13
Wednesday, 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 13
Wednesday, 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 13
Wednesday, May 18, 2011
44. DCI - Data
• What the system is
DCI 14
Wednesday, May 18, 2011
45. DCI - Data
• What the system is
• Relatively static with relations
DCI 14
Wednesday, May 18, 2011
46. DCI - Data
• What the system is
• Relatively static with relations
• Domain structure implemented with “conventional” classes
DCI 14
Wednesday, 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 14
Wednesday, 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 14
Wednesday, 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 14
Wednesday, 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 14
Wednesday, 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 14
Wednesday, May 18, 2011
53. DCI - Context (and Roles)
• Associated to a use case, user story, scenario, or
algorithm
DCI 15
Wednesday, 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 15
Wednesday, 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 15
Wednesday, 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 15
Wednesday, 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 15
Wednesday, 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 15
Wednesday, 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 15
Wednesday, May 18, 2011
66. DCI - Interaction
• What the system does
DCI 17
Wednesday, May 18, 2011
67. DCI - Interaction
• What the system does
• Occurs among roles, which act as adapters among objects
DCI 17
Wednesday, 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 17
Wednesday, 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 17
Wednesday, 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 17
Wednesday, 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 17
Wednesday, 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 17
Wednesday, May 18, 2011
74. DCI - Execution Model
• The Context finds object participants
DCI 18
Wednesday, May 18, 2011
75. DCI - Execution Model
• The Context finds object participants
• Then, it assigns (injects?) roles to them
DCI 18
Wednesday, 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 18
Wednesday, 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 18
Wednesday, 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 18
Wednesday, May 18, 2011
80. Some issues
• What about anemic objects?
DCI 19
Wednesday, May 18, 2011
81. Some issues
• What about anemic objects?
• Perhaps not a problem considering clusters object + roles
DCI 19
Wednesday, May 18, 2011
82. Some issues
• What about anemic objects?
• Perhaps not a problem considering clusters object + roles
• Object schizophrenia
DCI 19
Wednesday, 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 19
Wednesday, 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 19
Wednesday, 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 19
Wednesday, 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 19
Wednesday, 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 19
Wednesday, May 18, 2011
88. DCI - How to
implement?
Wednesday, May 18, 2011
93. Implementation issues
• Static vs dynamic
• Java
• AOP, annotation-driven code generation (e.g. Qi4J)
• Other languages
DCI 21
Wednesday, May 18, 2011
94. Implementation issues
• Static vs dynamic
• Java
• AOP, annotation-driven code generation (e.g. Qi4J)
• Other languages
• Traits, mix-ins
DCI 21
Wednesday, 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 21
Wednesday, 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 21
Wednesday, 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 21
Wednesday, 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 21
Wednesday, 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 22
Wednesday, May 18, 2011
101. NetBeans Platform Lookup; as()
• Role role = object.getLookup().lookup(Role.class) ...
DCI 23
Wednesday, 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 23
Wednesday, 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 23
Wednesday, 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 23
Wednesday, 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 23
Wednesday, May 18, 2011
109. Some example reusable roles
• Displayable:
• String s = myObject.as(Displayable).getDisplayName();
DCI 25
Wednesday, May 18, 2011
110. Some example reusable roles
• Displayable:
• String s = myObject.as(Displayable).getDisplayName();
• IconProvider:
DCI 25
Wednesday, May 18, 2011
111. Some example reusable roles
• Displayable:
• String s = myObject.as(Displayable).getDisplayName();
• IconProvider:
• Icon i = myObject.as(IconProvider).getIcon(16);
DCI 25
Wednesday, 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 25
Wednesday, 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 25
Wednesday, 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 25
Wednesday, 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 25
Wednesday, 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 25
Wednesday, 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 25
Wednesday, 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 25
Wednesday, May 18, 2011