The document discusses responsibility driven design, an object oriented design approach that focuses on identifying the responsibilities needed to perform required actions and assigning those responsibilities to appropriate objects. It outlines the responsibility driven design process, provides an example, and discusses related concepts like responsibility based modeling, GRASP patterns, and a consolidated design process. An exercise walks through identifying responsibilities and objects for a sample requirement to search for deals near a user's location.

1. Responsibility Driven
Design for Rubyists
An Outside-In OO Design Approach
Software Design Trilogy – Part I
Prepared and Presented by:
Andy Maleh / Software Engineer / Groupon

2. Outline
Pop Quiz
Responsibility Driven Design
Responsibility Based Modeling
GRASP
Consolidated OO Design Process
Exercise

3. Pop Quiz
What was the first object oriented language?
Simula 67 - developed in the
1960s at the Norwegian
Computing Center in Oslo

4. Pop Quiz
What are the key features/traits of Object Oriented
Programming?
Data Abstraction
Encapsulation
Messaging
Modularity
Inheritance
Polymorphism

5. Responsibility Driven
Design
Object oriented design technique that came from
Rebecca Wirfs-Brock
Reaction to Data-Driven Design’s lack of
encapsulation for object data
Focuses on object responsibilities and collaborations
Object interaction follows a client/server model

6. Responsibility Driven
Design Process
1. Identify actions that must be taken to accomplish user
goals in a software system
2. Identify responsibilities needed to perform these actions
including information sharing responsibilities
3. Identify objects most suitable for responsibilities
4. Identify object collaborations needed to fulfill
responsibilities, discovering new objects in the process
5. Iterate

7. Responsibility Driven
Design Example
Action: Add new address for user, validating address,
and filling in zip code automatically.
Responsibilities:
User information storage
Address information storage
Validate address
Retrieve zip code for address

8. Responsibility Driven
Design Example
Objects:
User (stores user info)
Address (stores address info, validates address)
AddressFactory (creates new address, validates
address, fills in zip code)
ZipCodeService (retrieves zip code for address)

9. Responsibility Based
Modeling
Responsibility Driven Design inspired technique by Alistair
Cockburn that helps developers start design from the
business domain model and use cases
Often begins with higher-level component design and
then delves down into object design
Use case scenario steps act as the actions for which
responsibilities must be identified (alternatively
Given/When/Then scenarios in Rubyland)
Objects can be identified using CRC cards or object
interaction diagramming

10. CRC Cards
CRC stands for Class Responsibilities Collaborations
Interactive paper exercise for discovering objects
and collaborations
Can be done collaboratively by multiple developers

11. CRC Cards
CRC stands for Class Responsibilities Collaborations
Interactive paper technique for discovering object
and collaborations based on identified high level
responsibilities
http://www.madsen.us/uop/BSA375/handouts.htm

12. CRD Cards
http://www.item.ntnu.no/people/personalpages/others/kraemer/phd/background

13. Object Interaction
Diagramming
Documents collaborations needed between objects
to accomplish a user goal
Helps developers discover objects and
responsibilities
The two most commonly used object interaction
diagrams are:
UML 2 Sequence Diagram
UML 2 Communication Diagram

14. Sequence Diagram

15. Communication
Diagram

16. GRASP
GRASP: General Responsibility Assignment Software
Patterns
They help developers figure out how to assign object
responsibilities and evaluate design decisions
Contemplated collectively instead of one at a time
Provide the underpinnings for object oriented design
Help explain how design patterns are arrived to

17. GRASP
1. Creator: isolates object creation responsibilities
2. Information Expert: the object that holds the data
performs the modification on the data
3. Controller: orchestrates multiple objects in
accomplishing an action
4. Low Coupling: minimize coupling to other objects
5. High Cohesion: increase focus of object
responsibilities

18. GRASP
6. Polymorphism: assign responsibilities based on types to objects
of these types
7. Pure Fabrication: fabricate an object to take on a responsibility
that needs to be offloaded of another object to improve
coupling/cohesion
8. Indirection: decouple two objects by introducing an
intermediary to decrease coupling and increase reuse and
interchangeability
9. Protected Variations: protect an object from variations of
interactions with other objects by substituting the variations
with one interaction with a super interface for the other
objects and relying on polymorhpism

19. Consolidated OO Design
Process
1. Write functional requirements as use cases
2. Pick one use case and identify use case scenarios (or
Given/When/Then)
3. Pick one use case scenario and identify actions
4. For each action, identify responsibilities needed to
perform it

20. Consolidated OO Design
Process
5. For each responsibility, identify an object most
suitable to fulfill it using GRASP as guidance
6. Review the responsibility assignments done for the
picked use case scenario, possibly altering your
decisions based on GRASP
7. Repeat until done with all use cases. This is done for
one use case at a time and one iteration’s length of
requirements at a time in an Agile process (thin slice
approach as per Alistair Cockburn)

21. Exercise
Requirement: Ability to navigate deals
Use Case: Search for deals near my location
Scenario:
Given I live in Chicago at 60622
When I sign into the system
And I request a search for deals near my location
And I specify keywords for finding deals
Then I am presented with a collection of deals that match
the specified keywords and are ordered by distance in
ascending order

22. Exercise –
Responsibilities
1. User lookup
2. User authentication
3. User information (including address)
4. User interaction request handling
5. Presentation of search input form
6. Search Form input handling

23. Exercise –
Responsibilities
6. Searching for deals
7. Ordering of search results
8. Retrieval of deal information
9. Presentation of deal information

24. Exercise – Objects
1. User lookup: UserRepository (High Cohesion)
2. User authentication: AuthenticationService (Pure Fabrication,
High Cohesion)
3. User Information: User (Information Expert)
4. User interaction request handling: DealSearchController
(Controller)
5. Presentation of search form: SearchInputForm (Information
Expert)
6. Search form input handling: DealSearchController (Controller)

25. Exercise – Objects
6. Searching for deals: DealSearchService (Pure
Fabrication, High Cohesion)
7. Ordering of search results: DealSearchService (Pure
Fabrication, High Cohesion)
8. Retrieval of deal information: DealRepository (High
Cohesion)
9. Presentation of deal information: DealView (Pure
Fabrication, High Cohesion, Indirection)

26. Exercise – Notes
• Objects can have methods that represent
responsibilities they do not directly perform, yet
delegate to collaboration objects
• Example: User has a sign_in method, but the work is
performed behind the scenes with the
AuthenticationService

27. Exercise – Notes on
Ruby on Rails
• Repositories and the objects they retrieve live in the
same object with ActiveRecord. Think of the
repository as the “Ruby class object” and the object
it retrieves as the “Ruby class instance object”
• Views are split into a template file (e.g. ERB or
HAML) and a presenter object if needed to handle
the presentation logic of the view. Rails Helpers
often act as presenters though since they already
have access to the view data context (Information
Expert)

28. Personal Exercise
Create CRC Cards for the responsibilities we
identified
Diagram the object interaction for the
responsibilities we identified (Sequence or
Communication)

29. Review
Pop Quiz
Responsibility Driven Design
Responsibility Based Modeling
GRASP
Consolidated OO Design Process
Exercise

30. Stay Tuned for More
Stay tuned for more in the Software Design Trilogy:
Part II: Design Patterns for Rubyists – Who Said
Dynamic Languages Can't Have Patterns?
Part III: Domain Driven Design in RoR Apps – When
Controllers and ActiveRecords Won't Cut It Anymore

31. Contact Info
Andy Maleh / Software Engineer / Groupon
Blog: http://andymaleh.blogspot.com
Twitter: @AndyMaleh

32. References
Responsibility Driven Design:http://wirfs-
brock.com/PDFs/Responsibility- Driven.pdf
Responsibility Based Modeling:
http://alistair.cockburn.us/Responsibility-
based+modeling
GRASP: http://www.amazon.com/Applying-UML-
Patterns-Introduction-Object-Oriented/dp/0131489062