GRASP (General Responsibility Assignment Software Principles) is a set of principles for assigning responsibilities to classes, including Expert, Creator, Low Coupling, High Cohesion, Controller, Polymorphism, Pure Fabrication, and Indirection. The principles aim to minimize dependencies between classes, reduce impacts of design changes, and allow for variations without affecting dependent components. Following these principles can result in designs with well-defined responsibilities, low coupling, high cohesion, and flexibility to handle changes.

1. GRASP (Object Oriented Design)

2. GRASP G eneral R esponsibility A ssignment S oftware P rinciples / P atterns

4. GRASP Responsibility A contract / obligation that a class / module / component must accomplish Knowledge Private state Computed state Behavior Send messages itself and modify its private state Instantiate another objects Send messages to another objects

5. GRASP GRASP Principles Expert Creator Low Coupling High Cohesion Controller Polymorphism Pure Fabrication Indirection Controlled Variation

6. GRASP - Expert Given a resposibility, what class must accomplish it? "Assign the resposibility to the class that knows the necessary information" Examples: Invoice's total amount Invoice itemss' amount

7. GRASP - Creator Who must instantiate A objects ? Class B must have that resposibility if: B is composed by A (composition) B knows the necesary information in order to instantiate A objets B depends heavily on A Design Patterns Factory AbstractFactory

8. GRASP - Low Coupling How to minimize dependencies between classes ? Coupling "When a class knows or depends on another class." If a class change the dependant class will be affected. Examples Inheritance Composition / agreggation / association A send messages to B

9. GRASP - Low Coupling How to reduce design change impacts ? Assign resposibilitys taking care of not to increasing coupling. Zero coupling is "impossible" Cyclic coupling it's the worst case

10. GRASP - High Cohesion How to design cohesive classes? Cohession "How strongly related and focused the resposiblites of a class / module / package are." Assing resposibilities related to each other. Low Cohesion implies: Hard to reuse Hard to maintain Constantly changing

11. GRASP - Controller Given an event layer (UI) and a bussines layer, who has the responsibility of receive the requests from the UI layer? A class that represents the whole system. Facade Controler Pattern A class that represents use case. Use Case Controller Pattern

12. GRASP - Polymorphism How to act different depending on object's class? How to design pluggable components ? Use polymorphism to assing responsibilities on classes when the behavior changes. Don't ask about object's class "Different types respond to compatible messages (same method name, same parameter set, same method signature). Each message represents a specific behavior." Inheritance, interfaces, duck typing

13. GRASP - Pure Fabrication How to assign responsibilities if applying the Expert principle decreases cohesion and increases coupling . eg: Invoice printing, CSV export Assign the resposibility to an artificial class that doesn't belongs to the domain model. Design Patterns: Active Record EntityManager

14. GRASP - Indirection How to assign responsibilities in order to remove coupling between two components ? Assign the responsibility to a component placed bewteen both sides Interface that hides changes produced on an external API

15. GRASP - Controlled Variation How to design in such a way that changes on classes, modules and systems doesn't affect dependent components ? Create stable interfaces upon inestable components. Variations: data behaviour external systems os ...

16. GRASP - Controlled Variation Structure variations E e = x.getA().getB().getC().getD().getE(); It's really fragile because a change on a link affects the sturcture Inside a method send messages to: this, self objects received as parameters self attributes self components instantiated objects on the current method call

17. GRASP - Controlled Variation Avoiding variations Encapsulation Polymorphism Interfaces Reflection, introspection, metadata Uniform access (access methods) Service lookups Dependency injection, IoC Virtual Machines (jvm, pvm, clr)

18. EOF