madhavrao…

GRASP stands for General Responsibility Assignment Software Patterns. It is used as guidelines for assigning responsibility to classes and objects in Object Oriented Design. GRASP describes fundamental principles of object design and responsibilities assignment, expressed as patterns.

There are nine patterns defined in GRASP

1. Information Expert
2. Creator
3. High Cohesion
4. Low Coupling
5. Controller
6. Polymorphism
7. Indirection
8. Pure Fabrication
9. Protected Variance

Information Expert(221): Assign the responsibility to the information expert - the class that has the information necessary to fulfill the responsibility.

It answers following question in design:

1. What is the general principle of assigning responsibility to objects?

Creator(226): Assign Class B the responsibility to create an instance of Class A if one or more of the following is true:

1. B aggregates A objects
2. B contains A objects
3. B record instances of A objects
4. B closely uses A objects
5. B has the initializing data that will be passed to A when it is created.

It answers following question in design:

1. Who should be responsible for creating a new instance of some class?

Low Coupling(229): Assign a responsibility so that coupling remains low.

It answers following question in design:

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

To know more about coupling and types of coupling Click here

High Cohesion(232): Assign a responsibility so that cohesion remains high.

It answers following question in design:

1. How to keep complexity manageable?

To know more about cohesion and types of cohesion Click here

Controller(237): Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices:

1. Represents the overall system, device, or subsystem (facade controller).
2. Represents a use case scenario within which the system event occurs, often named <Use Case Name>Handler, <Use Case Name>Coordinator, or <Use Case Name>Session (use case or session controller)

It answers following question in design:

1. Who should be responsible for handling an input system event?

Polymorphism(326): When related alternatives  or behaviors vary by type (class), assign responsibility for the behavior - using polymorphic operations - to the type for which the behavior varies.

Corollary: Do not test for the type of an object and use conditional logic to perform varying alternatives based on type.

It answers following question in design:

1. How to handle alternatives based on type?
2. How to create pluggable software components?

Pure Fabrication(329):Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represents a problem domain concept - something made up to support high cohesion, low coupling and reuse.

It answers following question in design:

1. What object should have responsibility, when you do not want to violate high cohesion and low coupling or other goals, but solutions offered by Expert are not appropriate?

Indirection(332): 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 the other components.

It answers following questions in design:

1. Where to assign a responsibility, to avoid direct coupling between two (or more) things?
2. How to de-couple objects so that low coupling is supported and reuse potential remains higher?

Protected Variations(334):Identify points of predicted variation or instability; assign responsibility to create a stable interface around them.

It answers following questions in design:

1. How to design objects, sub-systems and systems, so that the variations or instability in these elements does not have un-desirable impact on other element?

Cohesion: Cohesion is a measure of how strongly related and focused the responsibilities of an element are. An element with highly related responsibilities, and which does not do a tremendous amount of work, has high cohesion. These elements includes classes, subsystem and so on. A class with low cohesion do many unrelated things, or does too much of work. Such classes suffer from the following problems:

• hard to comprehend
• hard to reuse
• hard to maintain
• delicate; constantly effected by change

Types of Cohesion

The types of cohesion, in order of worst to best are as following:

• Coincidental Cohesion
• Logical Cohesion
• Temporal Cohesion
• Procedural Cohesion
• Communicational Cohesion
• Sequential Cohesion
• Functional Cohesion

Coincidental Cohesion (worst): Coincidental cohesion is when parts of a module are grouped arbitrarily (at random); the parts have no significant relationship (e.g. a module of frequently used mathematical functions).

Logical Cohesion: Logical cohesion is when parts of a module are grouped because they logically are categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines).

Temporal Cohesion: Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a particular time in program execution (e.g. a function which is called after catching an exception which closes open files, creates an error log, and notifies the user).

Procedural cohesion: Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution (e.g. a function which checks file permissions and then opens the file).

Communicational cohesion: Communicational cohesion is when parts of a module are grouped because they operate on the same data (e.g. a module which operates on the same record of information).

Sequential cohesion: Sequential cohesion is when parts of a module are grouped because the output from one part is the input to another part like an assembly line (e.g. a function which reads data from a file and processes the data).

Functional cohesion (best): Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module

Coupling: Its measure of how strongly one element is connected to, has knowledge of, or relies on other elements. An element with low (or weak) coupling is not dependent on too many other elements. A class with with high coupling relies on many other classes. Such classes may be undesirable; some suffer from the following problems:

• Changes  in related classes forces changes
• Harder to understand in isolation
• Harder to reuse because its use requires the additional presence of the classes on which it depends

Types of Coupling

Types of coupling in order of highest to lowest are as following:
(This also includes procedural coupling)

• Content Coupling
• Common Coupling
• External Coupling
• Control Coupling
• Stamp Coupling
• Data Coupling
• Message Coupling
• Subclass Coupling
• Temporal Coupling

Content Coupling (high): Content coupling is when one module modifies or relies on the internal workings of another module. Therefore changing the way the second module produces data will lead to changing the dependent module. In OOP improper implementation of AOP can creep in this type of coupling.

Common Coupling: Common coupling is when two modules share the same global data. Changing the shared resource implies changing all the modules using it. Enumerations, Constants are few constructs which should be looked into for this type of coupling in OOP

External Coupling: External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. Interfacing technology should be decoupled from main application by using Adapter pattern to overcome this type of coupling.

Control Coupling: Control coupling is one module controlling logic of another by passing it information on what to do. Class members should be made private, they should be exposed using public accesses. If any variable is used for controlling logic of the class, then it should be modified by methods of the class and avoid exposing them with public accesses.

Stamp Coupling: Stamp coupling exists when module shares a composite data structure and uses only part of it. E.g. passing a whole record to a function which only needs one field of it. This may lead to changing the way a module reads a record because a field which the module doesn’t need has been modified.

Data Coupling: Data Coupling is when modules share data for example; parameters. Chang in data structure all related modules.

Message Coupling (low): This is loosest type of coupling. Modules are not dependent on each other, instead they use public interface to exchange parameter less messages (or events)

Subclass Coupling: Describes relationship between a class and its parent. The class is connected to its parent, but the parent isn’t connected to child.

Temporal Coupling: When two actions are bundled together into one module just because they happen to  occur at same time then it leads to temporal coupling.