software design trilogy part i - responsibility driven design for rubyists

Responsibility Driven Design for

RubyistsAn Outside-In OO Design Approach

Software Design Trilogy – Part I

Prepared and Presented by:Andy Maleh / Software Engineer / Groupon

OutlinePop Quiz

Responsibility Driven Design

Responsibility Based Modeling

GRASP

Consolidated OO Design Process

Exercise

Pop QuizWhat was the first object oriented language?

Simula 67 - developed in the 1960s at the Norwegian Computing Center in Oslo

Pop QuizWhat are the key features/traits of Object Oriented Programming?

Data Abstraction

Encapsulation

Messaging

Modularity

Inheritance

Polymorphism

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

Responsibility Driven Design

Process1. 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

Responsibility Driven Design

ExampleAction: 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

Responsibility Driven Design

ExampleObjects: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)

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

CRC CardsCRC stands for Class Responsibilities Collaborations

Interactive paper exercise for discovering objects and collaborations

Can be done collaboratively by multiple developers

CRC CardsCRC 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

CRD Cards

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

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

Sequence Diagram

Communication Diagram

GRASPGRASP: 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

GRASP1. 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

GRASP6. 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

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

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)

ExerciseRequirement: 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

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

Exercise – Responsibilities

6. Searching for deals

7. Ordering of search results

8. Retrieval of deal information

9. Presentation of deal information

Exercise – Objects1. 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)

Exercise – Objects6. 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)

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

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)

Personal ExerciseCreate CRC Cards for the responsibilities we identified

Diagram the object interaction for the responsibilities we identified (Sequence or Communication)

ReviewPop Quiz

Responsibility Driven Design

Responsibility Based Modeling

GRASP

Consolidated OO Design Process

Exercise

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

Contact InfoAndy Maleh / Software Engineer / Groupon

Blog: http://andymaleh.blogspot.com

Twitter: @AndyMaleh

ReferencesResponsibility 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