GRASP : Designing Objects with Responsibilities Larman chapter 17

Object design Can be described as…… After identifying your requirements and creating a domain model, then add methods to the software classes, and define the messaging between the objects to fulfill the requirements.

Fig. 17.1

GRASP patterns General Responsibility Assignment Software Patterns A learning aid to help one understand essential object design Assigment of responsibilities occurs during creation of interaction diagrams and certainly during programming.

Responsibilities Related to the obligations of an object Types : Knowing About private encapsulated data About related objects About things it can derive or calculate Doing Doing something itself Initiating a action in other objects Controlling activities in other objects Responsibilities are implemented using methods

Patterns A named description of a problem and solution that can be applied to a new context. Patterns : attempt to codify tried-and-true knowledge and principles. facilitates communication. GRASP patterns : Information Expert Creator High Cohesion Low coupling Controller

Domain model1. iteration, fig. 17.3

Who creates the square objects, fig. 17.4

Board contains Square, fig. 17.5

Info Expert : Who should know about a Square object, given a key. fig

Low Coupling, why Board over Dog, fig. 17.7

What first object after or beyond the UI should receive the message from the UI layer? fig. 17.8

Controller, Fig. 17.9

Controller, fig. 17.10

High Cohesion, fig. 17.11

Name : Controller Solution : Problem : Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices : Represent the overall system, device or subsystem (Façade controller) Represent a use case scenario within which the system events occur. Often named <UseCaseName>Handler or <UseCaseName>Session Use the same controller for all system events in the same use case scenario Problem : Who should be responsible for handling an input system event ?

Example of Controller pattern Who should be the controller for system events ? The Controller pattern suggest : A Facade controller Register POSSystem A receiver or handler of all system events of a use case scanario ProssSaleHandler ProcessSaleSession

Facade Controller

Controller, fig. 17.22

System events and Allocating system operations System Sequence Diagram

Name : Information Expert Solution : Assign a responsibility to the information expert- the class that has the information necessary to fullfill the responsibility. Problem : What is a general principle of assigning responsibilities to objects.

Fig. 17.16 Who should be responsible for knowing the grand total of a sale ?

Info Expert, fig. 17.17

Name : Creator Solution : Problem : Class B has the responsibility to create an instance of class A if : B contains or compositely aggregates A B records A objects B closely uses A objects B has the initializing data. B is a creator of A objects. Problem : Who should be responsible for creating a new instance of some class ?

Who should be responsible for creating a SalesLineItem ? fig. 17.12

Example of Creator, fig. 17.13

Name : Low Coupling Solution : Problem : Assign a responsibility so that coupling remains low. Problem : How to support low dependency, low change impact, and increased reuse ? Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.

Who should be responsible for creating a Payment instance and associate with a Sale ? Fig. 17.18 Bad Coupling

Fig. 17.19 Good Coupling

Name : High Cohesion Solution : Problem : Assign a responsibility so that cohesion remains high. Problem : How to keep complexity manageable ? Cohesion is a measure of how strongly related and focused the responsibilities of an element are.

Example of High Cohesion Who should be responsible for creating a Payment instance and associate it with a Sale ? Ex.1 High Cohesion pattern suggest ex. 2 Ex.2 Creator pattern suggest ex. 1