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?

Patterns of Enterprise Application Architecture

Martin Fowler’s Patterns of Enterprise Application Architecture, is classified as

1. Domain Logic Patterns
2. Data Source Architectural Patterns
3. Object Relational Behavioral Patterns
4. Object Relational Structural Patterns
5. Object Relational Metadata Mapping Patterns
6. Web Presentation Patterns
7. Distribution Patterns
8. Offline Concurrency Patterns
9. Session State Patterns
10. Base Patterns

 

Domain Logic Patterns

Domain Logic Patterns addresses how to implement domain layer (Business Layer). Its been separated into three primary patterns

1. Transaction Script
2. Domain Model
3. Table Module

In case if we use Domain Model(116) or Table Module(125) Pattern than Domain Layer can be split in two. Service Layer(133) is placed over underlying Domain Model(116) or Table Module(125). This is not done with Transaction Script(110), since Transaction Script(110) isn’t complex enough to require a separate layer. Presentation Logic interacts with domain purely through Service Layer(133) which act as API for the application.

Transaction Script (110): Organizes business logic by procedures where each procedure handles a single request from the presentation.

Domain Model (116): An object model of the domain that incorporates both behavior and data.

Table Module (125): A single instance that handles the business logic for all rows in a database table or view.

Service Layer (133): Defines an application’s boundary with a layer of services that establishes a set of available operations and coordinates the application’s response in each operation.

 

Data Source Architectural Patterns

This pattern is further classified into:

1. Table Data Gateway
2. Row Data Gateway
3. Active Record
4. Data Mapper

Table Data Gateway(144): An object that acts as a Gateway(466) to a database table. One instance handles all the rows in a table.

Row Data Gateway(152): An object that acts as a Gateway(466) to a single record in a data source. There is one instance per row.

Active Record(160):An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

Data Mapper(165): A layer of Mappers(473) that moves data between objects and a database while keeping them independent of each other and the mapper itself.

 

Object Relational Behavioral Patterns

This pattern is further classified into:

1. Unit of Work
2. Identity Map
3. Lazy Load

Unit of Work(184): Maintains a list of objects affected by a business transaction and co-ordinates the writing out of changes and the resolution of concurrency problems.

Identity Map(195): Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up object using the map when referring to them.

Lazy Load(200): An object that doesn’t contain all of the data you need but knows how to get it.

 

Object Relational Structural Patterns

This pattern is further classified into:

1. Identity Field
2. Foreign Key Mapping
3. Association Table Mapping
4. Dependent Mapping
5. Embedded Value
6. Serializable LOB
7. Single Table Inheritance
8. Class Table Inheritance
9. Concrete Table Inheritance
10. Inheritance Mappers

Identity Field(216): Saves a database ID field in an object to maintain identity between an in-memory object and database row.

Foreign Key Mapping(236): Maps an association between objects to a foreign key reference between tables.

Association Table Mapping(248):Saves an association as a table which foreign keys to the tables they are linked by the association.

Dependent Mapping(262): Has one class perform the database mapping for a child class.

Embedded Value(268): Maps an object into several fields of another objects table.

Serializable LOB(272): Saves a graph of objects by serializing them into a single large object (LOB), which it stores into database field.

Single Table Inheritance(278):Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes.

Class Table Inheritance(285): Represents an inheritance hierarchy of classes with one table of each class.

Concrete Table Inheritance(293): Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy.

Inheritance Mappers(302): A structure to organize database mappers that handle inheritance hierarchies.

 

Object Relational Metadata Mapping Patterns

This are further classified as:

1. Metadata Mapping
2. Query Object
3. Repository

Metadata Mapping(306):Holds details of object-relational mapping in metadata.

Query Object(316): An object that represents a database query

Repository(322): Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

 

Web Presentation Patterns

This are further classified as:

1. Model View Controller
2. Page Controller
3. Front Controller
4. Transform View
5. Two Step View
6. Application Controller

Model View Controller(330): Splits user interface interactions into three distinct roles. Model represents data, View represents presentation of data and controller handles Views events and co-ordinate with various services.

Page Controller(333): An object that handles a request for a specific page or action on a web site.

Front Controller(344): A controller that handles all request for a web site.

Transform View(350):Renders information into HTML by embedding markers in a HTML page.

Two Step View(365):Turns domain data into HTML in two steps: first by forming some kind of logical page, then rendering the logical page into HTML.

Application Controller(379): A centralized point for handling screen navigation and the flow of an application.

 

Distribution Patterns

This are further classified as:

1. Remote Facade
2. Data Transfer Object

Remote Facade(388): Provides a cross grained facade on fine-grained objects to improve efficiency over a network.

Data Transfer Object(401): An Object that carries data between processes in order to reduce number of method calls.

 

Offline Concurrency Patterns

This are further classified as:

1. Optimistic Offline Lock
2. Pessimistic Offline Lock
3. Cross Grained Lock
4. Implicit Lock

Optimistic Offline Lock(416): Prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction.

Pessimistic Offline Lock(426): Prevents conflicts between concurrent business transactions by allowing only one business transaction at a time to access data.

Cross Grained Lock(438): Locks a set of related objects with a single lock.

Implicit Lock(449): Allows framework or layer supertype code to acquire offline lock.

 

Session State Patterns

This are further classified as:

1. Client Session State
2. Server Session State
3. Database Session State

Client Session State(456):Stores session state on client

Server Session State(458):Keeps the session state on a server system in a serialized form.

Database Session State(462): Stores session data as committed data in the database.

 

Base Patterns

This are further classified as:

1. Gateway
2. Mapper
3. Layer Supertype
4. Separated Interface
5. Registry
6. Value Object
7. Money
8. Special Case
9. Plugin
10. Service Stub
11. Record Set

Gateway(466):An object that encapsulates access to external system or resource.

Mapper(473): An object that sets up a communication between two independent objects.

Layer Supertype(475):A type that acts as the supertype for all types in its layer.

Separated Interface(476):Defines an interface in a separate package from its implementation.

Registry(480): A well known object that other object can use to find common objects and services.

Value Object(486): A small simple object, like money or a date range, whose equality isn’t based on identity.

Money(488): Represents a monetary value.

Special Case(496): A subclass that provides special behavior for particular cases.

Plugin(499): Links classes during configuration rather than compilation.

Service Stub(504): Removes dependency upon problematic services during testing.

Record Set(508): An in memory representation of tabular data.