grasp principles

34
Boutique product development company It is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.

Upload: raheel-arif

Post on 22-Jun-2015

617 views

Category:

Software


3 download

DESCRIPTION

General Responsibility Assignment Software Patterns

TRANSCRIPT

Page 1: GRASP Principles

Boutique product development companyIt is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.

Page 2: GRASP Principles

Boutique product development companyIt is amazing what you can accomplish when you have a client-centric team to deliver outstanding products.

GRASP PRINCIPLES

Raheel Arif | Software Engineer

Page 3: GRASP Principles

Understanding responsibilities is key to object-oriented design - Martin Fowler

GRASPo GRASP = General Responsibility Assignment

Software Patternso A set of principles for assigning responsibilities to

classes – the key skill in OO software design

Raheel Arif | Software Engineer

Page 4: GRASP Principles

GRASP PRINCIPLES

Raheel Arif | Software Engineer

9 GRASP principles:o Information Experto Creatoro Low Couplingo Controllero High Cohesiono Polymorphismo Pure Fabricationo Indirectiono Protected Variations

Page 5: GRASP Principles

GRASP Principles

Information Expert

Raheel Arif | Software Engineer

Problem: What is a general principle for assigning responsibilities to objects?

Solution: Assign a responsibility to the information expert, that is, the class that has the information necessary to fulfill the responsibility.Example: E.g., Board information needed to get a Square

Page 6: GRASP Principles

GRASP Principles

Pros and Cons

Raheel Arif | Software Engineer

• Facilitates information encapsulation: why?o Classes use their own info to fulfill tasks

• Encourages cohesive, lightweight class definitionsBut:• Information expert may contradict patterns of Low Coupling and High Cohesion

Page 7: GRASP Principles

GRASP Principles

Creator

Raheel Arif | Software Engineer

Problem: Who creates an A?Solution: Assign class B the responsibility to create an instance of class A if one of these is true (the more the better):• B "contains" or compositely aggregates A.• B records instances of A• B closely uses A• B has the initializing data for A.

Page 8: GRASP Principles

GRASP Principles

Who creates the Squares?

Raheel Arif | Software Engineer

Page 9: GRASP Principles

GRASP Principles

Raheel Arif | Software Engineer

Page 10: GRASP Principles

GRASP Principles

Low Coupling

Raheel Arif | Software Engineer

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

Page 11: GRASP Principles

GRASP Principles

Low Coupling

Raheel Arif | Software Engineer

A class with high coupling relies on many other classes – leads to problems:• Changes in related classes forces local changes• Harder to understand in isolation• Harder to reuse

Page 12: GRASP Principles

GRASP Principles

Example

Raheel Arif | Software Engineer

Page 13: GRASP Principles

GRASP Principles

Benefits

Raheel Arif | Software Engineer

• Understandability: Classes are easier to understand in isolation

• Maintainability: Classes aren’t affected by changes in other components

• Reusability: easier to grab hold of classes

Page 14: GRASP Principles

GRASP Principles

Controller

Raheel Arif | Software Engineer

Problem: Who should be responsible for handling a system event?  (Or, what object receives and coordinates a system operation?)Solution: Assign the responsibility for receiving and/or handling a system event to one of following choices:

•Represent the overall system, device or subsystem (façade controller)

•Represent a use case scenario within which the system event occurs (a <UseCase>Handler)

Page 15: GRASP Principles

GRASP Principles

High Cohesion

Raheel Arif | Software Engineer

Problem: How to keep classes focused and manageable?Solution: Assign responsibility so that cohesion remains high.Cohesion measures how strongly related and focused are the responsibilities of an element

Page 16: GRASP Principles

GRASP Principles

High Cohesion

Raheel Arif | Software Engineer

Problems from low cohesion (does many unrelated things or does too much work):

•Hard to understand/comprehend•Hard to reuse•Hard to maintain

Brittle – easily affected by change

Page 17: GRASP Principles

GRASP Principles

High Cohesion

Raheel Arif | Software Engineer

Page 18: GRASP Principles

GRASP Principles

High Cohesion

Raheel Arif | Software Engineer

• Very low cohesion – a class is responsible for many things in different functional areas

• High cohesion – a class has moderate responsibilities in one functional area and collaborates with other classes to fulfill tasks

Page 19: GRASP Principles

GRASP Principles

High Cohesion

Raheel Arif | Software Engineer

Typically high cohesion => few methods with highly related functionalityBenefits of high cohesion:

•Easy to maintain•Easy to understand•Easy to reuse

Page 20: GRASP Principles

GRASP Principles

Polymorphism

Raheel Arif | Software Engineer

Problem: How to handle alternatives based on type?  How to create pluggable software componentsSolution: When related alternatives or behaviors vary by type (class), assign responsibilities for the behavior—using polymorphic operations—to thetypes for which the behavior varies.• Polymorphic operations are those that operate on

differing classes• Don’t test for the type of the object and use conditional

logic to perform varying statements based on type.

Page 21: GRASP Principles

GRASP Principles

Monopoly Problem: How to Design for Different Square Actions?

Raheel Arif | Software Engineer

Page 22: GRASP Principles

GRASP Principles

Polymorphism

Raheel Arif | Software Engineer

Page 23: GRASP Principles

GRASP Principles

Pure Fabrication

Raheel Arif | Software Engineer

Problem: What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate?Solution: Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept something made up, to support high cohesion, low coupling, and reuse.

Page 24: GRASP Principles

GRASP Principles

Pure Fabrication- Example

Raheel Arif | Software Engineer

Who should be responsible for saving Sale instances in a relational database?

- by Information Expert ??- leads to low cohesion- and high coupling- better: create (“fabricate”) a new class that has this

responsibility

Page 25: GRASP Principles

GRASP Principles

Indirection

Raheel Arif | Software Engineer

Sometimes objects must interact with other objects or external systems, which may change (or replaced) in future. Direct coupling to such objects or systems may result in modification in our objectsProblem: Where to assign a responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher?Solution:Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. The intermediary creates an indirection between other components.

Page 26: GRASP Principles

GRASP Principles

Indirection--A Simple Example

Raheel Arif | Software Engineer

Consider a CreditAuthorizationService class that needs touse a Modem

Bad approach: Put low-level calls to the Modem API directly in the methods of the CreditAuthorizationClassBetter approach: Add an intermediateModemclass that insulates CreditAuthorizationClass from the Modem API.

Page 27: GRASP Principles

GRASP Principles

Indirection--A Simple Example

Raheel Arif | Software Engineer

Problems:In a Sales System, there are multiple external third-party tax calculators that must be supported.The system needs to be able to integrate with different calculators according to some conditions.For example; if total is above 500TL it uses the external "Tax Master" program, otherwise "Good As Gold" program.Each tax calculator has a different interface .One product may support a raw TCP socket protocol, another may offer a SOAP interface, and a third may offer a Java RMI interface.In the future, a new calculator program may be integrated into the system or an existing calculator may be removedActually Sale class is responsible to calculate the total and therefore needs the tax.However, we want to keep our system (Sale) independent from the varying external tax calculators.

Page 28: GRASP Principles

GRASP Principles

Example: Third-Party (External) Tax Calculators in the NextGen System

Raheel Arif | Software Engineer

Page 29: GRASP Principles

GRASP Principles

Example: Third-Party (External) Tax Calculators in the NextGen System

Raheel Arif | Software Engineer

Page 30: GRASP Principles

GRASP Principles

Indirection - Notes

Raheel Arif | Software Engineer

● The GoF Proxy, Bridge, and Mediator patterns utilize indirection.● For that matter, classes created for Indirection are usually also Pure

Fabrications, thus exemplifying two patterns for the price of one. :-)● Lower coupling between components● Indirection is pervasive in computer science:

"Most problems in computer science can be solved by another level of indirection."- David Wheeler

..but:"Most problems in performance can be solved by removing another layer of indirection." - anonymous

Page 31: GRASP Principles

GRASP Principles

Protected Variations

Raheel Arif | Software Engineer

Problem: How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements?Solution: Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.(The term "interface" is used in the broadest sense of an access view; it does not literally only mean something like a Java interface.

Page 32: GRASP Principles

GRASP Principles

Protected Variations - Example

Raheel Arif | Software Engineer

Problem: a client explained that the logistical support application used by an airline was a maintenance headache. There was frequent modification of the business logic to support the logistics. How do you protect the system from variations at this point?

Page 33: GRASP Principles

GRASP Principles

Protected Variations - Example

Raheel Arif | Software Engineer

Solution: A rules engine was added to the system, and an external rule editor let the subject matter experts update the rules without requiring changes to the source code of the system.

Page 34: GRASP Principles

GRASP Principles

Thank you for your time

Waleed Bin Dawood | Software Engineer

If you have any questions then please ask