Software Design Trilogy Part I - Responsibility Driven Design for Rubyists
Upcoming SlideShare
Loading in...5

Software Design Trilogy Part I - Responsibility Driven Design for Rubyists






Total Views
Views on SlideShare
Embed Views



39 Embeds 2,387 1649 213 65 61 60 45 36 31 27 27 21 17 16 13 13 9 9 7 7 7 6 6 4 4 4 4 3 3 3 3 2 2 2 2 2 1 1 1 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Software Design Trilogy Part I - Responsibility Driven Design for Rubyists Software Design Trilogy Part I - Responsibility Driven Design for Rubyists Presentation Transcript

  • 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
  • OutlinePop QuizResponsibility Driven DesignResponsibility Based ModelingGRASPConsolidated OO Design ProcessExercise
  • Pop Quiz What was the first object oriented language?Simula 67 - developed in the1960s at the NorwegianComputing Center in Oslo
  • Pop QuizWhat are the key features/traits of Object OrientedProgramming?Data AbstractionEncapsulationMessagingModularityInheritancePolymorphism
  • Responsibility Driven DesignObject oriented design technique that came fromRebecca Wirfs-BrockReaction to Data-Driven Design’s lack ofencapsulation for object dataFocuses on object responsibilities and collaborationsObject interaction follows a client/server model
  • Responsibility Driven Design Process1. Identify actions that must be taken to accomplish user goals in a software system2. Identify responsibilities needed to perform these actions including information sharing responsibilities3. Identify objects most suitable for responsibilities4. Identify object collaborations needed to fulfill responsibilities, discovering new objects in the process5. 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 ModelingResponsibility Driven Design inspired technique by AlistairCockburn that helps developers start design from thebusiness domain model and use casesOften begins with higher-level component design andthen delves down into object designUse case scenario steps act as the actions for whichresponsibilities must be identified (alternativelyGiven/When/Then scenarios in Rubyland)Objects can be identified using CRC cards or objectinteraction diagramming
  • CRC CardsCRC stands for Class Responsibilities CollaborationsInteractive paper exercise for discovering objectsand collaborationsCan be done collaboratively by multiple developers
  • CRC CardsCRC stands for Class Responsibilities CollaborationsInteractive paper technique for discovering objectand collaborations based on identified high levelresponsibilities
  • CRD Cards
  • Object Interaction DiagrammingDocuments collaborations needed between objectsto accomplish a user goalHelps developers discover objects andresponsibilitiesThe two most commonly used object interactiondiagrams are: UML 2 Sequence Diagram UML 2 Communication Diagram
  • Sequence Diagram
  • Communication Diagram
  • GRASPGRASP: General Responsibility Assignment SoftwarePatternsThey help developers figure out how to assign objectresponsibilities and evaluate design decisionsContemplated collectively instead of one at a timeProvide the underpinnings for object oriented designHelp explain how design patterns are arrived to
  • GRASP1. Creator: isolates object creation responsibilities2. Information Expert: the object that holds the data performs the modification on the data3. Controller: orchestrates multiple objects in accomplishing an action4. Low Coupling: minimize coupling to other objects5. High Cohesion: increase focus of object responsibilities
  • GRASP6. Polymorphism: assign responsibilities based on types to objects of these types7. Pure Fabrication: fabricate an object to take on a responsibility that needs to be offloaded of another object to improve coupling/cohesion8. Indirection: decouple two objects by introducing an intermediary to decrease coupling and increase reuse and interchangeability9. 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 Process1. Write functional requirements as use cases2. Pick one use case and identify use case scenarios (or Given/When/Then)3. Pick one use case scenario and identify actions4. For each action, identify responsibilities needed to perform it
  • Consolidated OO Design Process5. For each responsibility, identify an object most suitable to fulfill it using GRASP as guidance6. Review the responsibility assignments done for the picked use case scenario, possibly altering your decisions based on GRASP7. 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 – Responsibilities1. User lookup2. User authentication3. User information (including address)4. User interaction request handling5. Presentation of search input form6. Search Form input handling
  • Exercise – Responsibilities6. Searching for deals7. Ordering of search results8. Retrieval of deal information9. 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 weidentifiedDiagram the object interaction for theresponsibilities we identified (Sequence orCommunication)
  • ReviewPop QuizResponsibility Driven DesignResponsibility Based ModelingGRASPConsolidated OO Design ProcessExercise
  • Stay Tuned for MoreStay tuned for more in the Software Design Trilogy: Part II: Design Patterns for Rubyists – Who Said Dynamic Languages Cant Have Patterns? Part III: Domain Driven Design in RoR Apps – When Controllers and ActiveRecords Wont Cut It Anymore
  • Contact InfoAndy Maleh / Software Engineer / GrouponBlog: http://andymaleh.blogspot.comTwitter: @AndyMaleh
  • ReferencesResponsibility Driven Design: Driven.pdfResponsibility Based Modeling: