DesignPatterns - Revision history

Suhridk: /* High coupling */

2012-01-07T17:27:43Z

High coupling

Suhridk: /* Motivation */

2012-01-07T14:42:47Z

Motivation

Suhridk: /* Intro */

2012-01-07T13:22:33Z

Intro

Suhridk: /* Intro */

2012-01-07T13:12:25Z

Intro

Suhridk: /* Intro */

2012-01-07T13:11:11Z

Intro

Suhridk: /* Polymorphism */

2011-12-23T01:04:06Z

Polymorphism

Suhridk: /* Pure Fabrication */

2011-12-23T01:01:01Z

Pure Fabrication

Suhridk: /* Pure Fabrication */

2011-12-23T00:56:40Z

Pure Fabrication

Suhridk: /* Example */

2011-12-23T00:55:16Z

Example

Suhridk: /* Intro */

2011-12-23T00:34:36Z

Intro

@@ Line 424: / Line 424: @@
 * Don't assign responsibilities that will create high dependency between classes and high impact in one class when some other class changes.
-== High coupling ==
+== High cohesion ==
 * Assign responsibilities such that cohesion stays high.

@@ Line 139: / Line 139: @@
 * We would like to add extra behavior to an object, not a class. Modifying the class would mean making compile time changes.
 * Inheritance is a '''static''' mechanism and cannot solve this problem.
 == Example ==

@@ Line 28: / Line 28: @@
 * Patterns must be validated by experience.
 * Using them is a human intensive activity.
 = Facade =

@@ Line 11: / Line 11: @@
 ** Determining how abstract or how concrete a class should be.
 ** Specifying interfaces of classes, architectures, and binary components.
 ** Designing for change.
 * Patterns are not code-reuse they are experience reuse !

@@ Line 6: / Line 6: @@
 * Patterns support reuse of software architecture and design.
 * They give software engineers a vocabulary with which to describe their designs.
 * Patterns solve design problems such as:
 ** Finding appropriate classes to solve a problem.

@@ Line 436: / Line 436: @@
 * So the type is assigned responsibility of the behavior.
 * The implementation is done by dynamically bound polymorphic operations - the very core of OO :)
 [[Category:OODE]]

@@ Line 421: / Line 421: @@
 == Pure Fabrication ==
+* OO designs are characterized by implementing classes that represent concepts in the real world.
 [[Category:OODE]]

← Older revision		Revision as of 00:55, 23 December 2011
Line 383:		Line 383:

	[[File:MetaclassPattern.png]]		[[File:MetaclassPattern.png]]
		+
		+	= GRASP Patterns =
		+
		+	== Intro ==
		+
		+	* GRASP stands for General Responsibility Assignment Software Patterns.
		+	* These patterns describe some of the fundamental principles of assigning responsibilities to objects - which is one of the hardest things to do in OO.
		+
		+	== Information Expert ==
		+
		+	* Assign responsibility for a certain operation to the class which has the most of necessary information, aka the information expert.
		+
		+	== Low coupling ==
		+
		+	* Assign responsibilities such that the coupling between classes remains low.
		+	* Don't assign responsibilities that will create high dependency between classes and high impact in one class when some other class changes.
		+
		+	== High coupling ==
		+
		+	* Assign responsibilities such that cohesion stays high.
		+	* For e.g. all printing related responsibilities should stay in a single Printer class.
		+
		+	== Creator ==
		+
		+	* Similar to the Factory pattern.
		+	* An object of class A has to be created.
		+	* Assign class B the responsibility to create objects of class A, if
		+	** B aggregates A objects
		+	** B contains A objects
		+	** B records instances of A objects
		+	** B closely uses A objects
		+	** B has the initializing data that will be passed to A when it is created i.e. B is an expert
		+	** B is already a creator of A objects.
		+
		+	* An example of class A is Employee and class B is Company. So the Company class can have the responsibility to create Employee objects.
		+
		+	== Pure Fabrication ==
		+
		+

	[[Category:OODE]]		[[Category:OODE]]