View source for CSC/ ECE 517 Fall 2007/wiki3 5 pr

==Introduction to Patterns==

&nbsp;&nbsp;&nbsp;Design patterns are recurring solutions to software design problems that is found in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.
The Gang of Four (GoF) patterns are generally considered the foundation for all patterns. They are categorized in three groups: Creational, Structural, and Behavioral. 
<br>
The attributes that generally define a pattern are:
Pattern name is a descriptive name, that conveys the essence of the pattern. 
Synopsis describes the purpose of the pattern, its intent, and the particular design problem(s) it addresses. 
Description discusses the participating objects, the communication, and general structure of the pattern. 
Forces specifies any constraints that must be considered when using the pattern. For example, a solution to some problem may be constrained by the fact that the solution must run on distributed computers. 
Implementation shows how the pattern might be implemented in a specific instance. 
Consequences describes the positive and negative effects of employing the pattern. 
Related Patterns identifies those patterns that either replace the given pattern in different contexts, extend the given pattern, or collaborate with the pattern in more complex cases. <br>
==Creator Pattern==
&nbsp;&nbsp;&nbsp;Creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by controlling this object creation.
&nbsp;&nbsp;&nbsp;The Creator pattern is used to decide which object should be responsible for creating new objects (instances of some class). There are several cases to consider.<br>
==Examples==
===Example 1===
Let A and B be objects. 
B aggregates A objects. That is, there is a whole-part relationship between B and A. A objects are considered to be a part of B objects. 
B contains A objects. This is a stronger whole-part relationship, also called composition. With composition, the A objects have no existence outside of their relationship with B objects. 
B records instances of A objects. 
B closely uses A objects. 
B has the initializing data that will be pass to A when it is created (thus B is an Expert with respect to creating A). 
In these cases, B is a creator of A objects. If more than one option applies, prefer a class B which aggregates or contains class A.<br>
Problem: Who should be responsible for creating a new instance of some class?
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 A. 
B closely uses A. 
B has the initializing data for A that will be passed to A when it is crated. Thus B is an Expert with respect to creating A.
In general, the class that contains (aggregates) A is typically the best class to create A because it will probably satisfy one or more of the options mentioned above.<br>

===Example 2 ===
&nbsp;&nbsp;&nbsp;Another example is adding a new DataRow to a DataTable. To get a new row, you ask the DataTable to create a new DataRow for you and then add the row to the table.
DataRow myRow = myTable.NewRow();

...

myTable.Rows.Add(myRow);
The DataTable object contains / aggregates DataRows and therefore is the logical class to create the DataRow.
By having the aggregate class create the child class, it not only follows the creator pattern but also supports the Information Expert, High Cohesion, and Low Coupling GRASP(General Responsibility Assignment Software Patterns: gives guidelines for assigning responsibility to classes and objects.) Patterns. <br>

There are many types of Creator patterns as mentioned below:
  Abstract Factory  
  Builder 	  
  Factory Method
  Prototype 	  
  Singleton
<br>

==Factory Pattern==
&nbsp;&nbsp;&nbsp;The factory method is not different from the creational pattern, instead is a type of creational pattern. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. 
&nbsp;&nbsp;&nbsp;The factory method design pattern handles this problem by defining a separate method for creating the objects, which subclasses can then override to specify the derived type of product that will be created. More generally, the term factory method is often used to refer to any method whose main purpose is creation of objects.
This pattern helps determine who should be responsible for creating objects when there are special considerations, such as complex creation logic. 
<br>
==References==
http://en.wikipedia.org/wiki/GRASP_%28Object_Oriented_Design%29<br>
http://en.wikipedia.org/wiki/Factory_method_pattern<br>
http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/Creator.html<br>