GRASP 1

Question 1

What is a Responsibility and what types of responsibilities are there?

Answer 1

A contract or obligation of a classifier.

Knowing and Doing Responsibilities

Question 2

What do Doing responsibilities include?

Answer 2

 directly—e.g. create object, perform calculation
 initiate action in other objects
 control and coordinate activities in other objects

Question 3

What do knowing responsibilities include?

Answer 3

Knowledge of:
 Private encapsulated data
 Related objects
 Derivable or calculable items
Can be inferred from the domain model b/c of attributes and accossiations

Question 4

What does RDD stand for?

Answer 4

Responsibility driven design

Question 5

What is RRD?

Answer 5

RDD sees an OO Design as a community of collaborating responsible objects.
It involves assigning responsibilities to classes which should be based on proven principles.

Question 6

What does GRASP stand for?

Answer 6

General Responsibility Assignment Software Patterns (or Principles).
Its a Learning Aid for RDD

Question 7

What are the 9 GRASP patterns?

Answer 7

• Creator
• Information Expert
• Low Coupling
• High Cohesion
• Controller
• Polymorphism
• Indirection
• Pure Fabrication
• Protected Variations

Question 8

What problem does the Creator pattern aim to resolve?

Answer 8

Who should be responsible for creating a new instance of some class?
Creation of objects:
 One of the most common OO activities
 Useful to have a general principle to deal with this
 Want outcomes with low coupling, increased clarity, encapsulation, and reusability

Question 9

What solution does the Creator pattern propose?

Answer 9

Assign class B responsibility to create instances of class A if one of these is true (the more the better):
 B “contains” or compositely aggregates A.
 B records A.
 B closely uses A.
 B has the initializing data for A that will be passed to A when it is created. Thus B is an Expert with respect to creating A.
If >1 applies, choose B which aggregates/containsA.

Question 10

What are the contraindications of the creator pattern?

Answer 10

Creation of significant complexity, e.g.
o recycling instances for performance.
o instances from A1, A2, …, based on property
In these cases, delegate to helper class in the form of a Concrete Factory or Abstract Factory.

Question 11

What problem does the Information Expert pattern aim to resolve?

Answer 11

What is a general principle of assigning responsibilities to objects?
Design model:
 May have 100s or 1000s of software classes
 May have 100s or 1000s of responsibilities
 Useful to have a general principle to guide choice of assignment
 Want outcomes that are easier to understand, maintain, extend, and reuse

Question 12

What solution does the Information expert pattern propose?

Answer 12

Assign responsibility to the information expert—the class that has the informationnecessary to fulfil the responsibility.
 Start assigning responsibilities by clearly stating the responsibility.
 Look in Domain Model or Design Model?
1. If relevant classes in Design, look there first.
2. Otherwise look in Domain, and use or expand to inspire creation of design classes.

Question 13

What are the contraindications of the Information Expert pattern?

Answer 13

Suggested solution can result in poor coupling and cohesion
Example:
 Need to store objects in a database (DB)
 Each class is an expert on what needs to be stored
 Add DB handling to each class?
 No: DB elements and other class elements not cohesive; couples all classes with DB services
 Separate application logic and DB logic (DB Expert)

Question 14

What problem does the Low Coupling pattern aim to resolve?

Answer 14

How to support low dependency, low change impact, and increased reuse?

Problems for a class with high coupling:
 Forced changes: result of changes in related classes
 Harder to understand in isolation
 Harder to reuse, as harder to isolate

Question 15

What solution does the Low Coupling pattern propose?

Answer 15

Assign responsibility so that coupling remains low. Use this principle to evaluate alternatives.

Question 16

What are the contraindications of the Low Coupling pattern?

Answer 16

High coupling to stable elements is rarely a problem
Example:
 Standard Java Libraries can be used extensively without concern as their use does not generate concerns relating to stability, understanding or reuse.
Note: Coupling is essential. We are choosing where it can be kept low without compromising other design aspects.

Question 17

What is coupling?

Answer 17

Measure of how strongly one element is connected to, has knowledge of or relies on others.

Question 18

What problem does the Controller pattern aim to resolve?

Answer 18

What first object beyond the UI layer receives and coordinates (“controls”) a system operation?
System operations:
 major input events
 appear on System Sequence Diagrams (SSDs)

Question 19

What solution does the Controller pattern propose?

Answer 19

Assign responsibility to a class representing one of:
 the overall “system”, a “root” object, a device the software is running within, or a major subsystem
o façade controller
 a use case scenario that deals with the event, e.g. (Handler|Coordinator|Session)
o use case or session controller

Question 20

What are the contraindications of the Controller pattern?

Answer 20

Bloated controller: too many responsibilities, low cohesion, unfocussed
o Single controller class for all system events
 Soln: add more controllers (façade → use case)
o Controller too complicated, contains too much or duplicated information: violates Information Expert and High Cohesion
 Soln: delegate!

Question 21

What problem does the High Cohesion pattern aim to resolve?

Answer 21

How to keep objects focussed, understandable, and manageable, and as a side effect, support Low Coupling?
(functional) cohesion: A measure of how strongly (functionally) related and focussed the responsibilities of an element are

Question 22

What solution does the High Cohesion pattern propose?

Answer 22

Assign a responsibility so that cohesion remains high. Use this to evaluate alternatives.

Question 23

What are the contraindications of the High Cohesion pattern?

Answer 23

Lower cohesion is sometimes justified to meet non-functional requirements
Example:
To meet performance requirements, larger, less cohesive classes are used to reduce processing overheads (e.g. transmission, storage, retrieval)

Note: Coupling and cohesion are fundamental design properties which are interdependent: both must be considered together.

Question 24

What is (functional) cohesion?

Answer 24

A measure of how strongly (functionally) related and focussed the responsibilities of an element are

Question 25

What are some issues of classes that have low cohesion?

Answer 25

 Hard to comprehend  Hard to reuse  Hard to maintain  Delicate; constantly affected by change