Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-22T04:03:21Z

Quick Gun Murugan: /* '''References''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] principles like [http://en.wikipedia.org/wiki/Coupling_(computer_science) coupling], [http://en.wikipedia.org/wiki/Cohesion_(computer_science) cohesion] and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like [http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) aggregation], [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], association between classes, and data type (smarted than [http://en.wikipedia.org/wiki/SQL SQL] data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in Figure 8.
[[Image:Wiki 3 12 6.jpg]]
Figure 8 : One-to-many mapping

==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In Figure 9, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].
[[Image:Wiki 3 12 7.jpg]]
Figure 9 : Many-to-many mapping

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

Differences between the two approaches has been tabulated below: 
{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''Type Conversion'''==
There are situations when the values in the database do not map directly to object data types. Take the Boolean data type for example. Boolean values "true" and "false" may be saved as "T" and "F" respectively in the database. Type conversion should be facilitated without any data loss[2]. The figure below shows type conversion mapping.
[[Image:Tcmapfig.jpg]]

=='''References'''==
[1] http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2] http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3] http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4] http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5] http://www.dparsons.co.uk/mindthegap.pdf 
[6] http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7] http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8] http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9] http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10] http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11] http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12] http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html 
[13] http://wiki.eclipse.org/Introduction_to_Mappings_(ELUG)

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-22T04:01:54Z

Quick Gun Murugan: /* '''Type Conversion''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] principles like [http://en.wikipedia.org/wiki/Coupling_(computer_science) coupling], [http://en.wikipedia.org/wiki/Cohesion_(computer_science) cohesion] and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like [http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) aggregation], [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], association between classes, and data type (smarted than [http://en.wikipedia.org/wiki/SQL SQL] data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in Figure 8.
[[Image:Wiki 3 12 6.jpg]]
Figure 8 : One-to-many mapping

==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In Figure 9, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].
[[Image:Wiki 3 12 7.jpg]]
Figure 9 : Many-to-many mapping

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

Differences between the two approaches has been tabulated below: 
{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''Type Conversion'''==
There are situations when the values in the database do not map directly to object data types. Take the Boolean data type for example. Boolean values "true" and "false" may be saved as "T" and "F" respectively in the database. Type conversion should be facilitated without any data loss[2]. The figure below shows type conversion mapping.
[[Image:Tcmapfig.jpg]]

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

File:Tcmapfig.jpg

2009-11-22T04:00:36Z

Quick Gun Murugan:

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-22T03:58:06Z

Quick Gun Murugan: /* '''Type Conversion''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] principles like [http://en.wikipedia.org/wiki/Coupling_(computer_science) coupling], [http://en.wikipedia.org/wiki/Cohesion_(computer_science) cohesion] and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like [http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) aggregation], [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], association between classes, and data type (smarted than [http://en.wikipedia.org/wiki/SQL SQL] data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in Figure 8.
[[Image:Wiki 3 12 6.jpg]]
Figure 8 : One-to-many mapping

==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In Figure 9, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].
[[Image:Wiki 3 12 7.jpg]]
Figure 9 : Many-to-many mapping

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

Differences between the two approaches has been tabulated below: 
{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''Type Conversion'''==
There are situations when the values in the database do not map directly to object data types. Take the Boolean data type for example. Boolean values "true" and "false" may be saved as "T" and "F" respectively in the database. Type conversion should be facilitated without any data loss[2].

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-22T03:40:31Z

Quick Gun Murugan: /* '''Foreign key aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] principles like [http://en.wikipedia.org/wiki/Coupling_(computer_science) coupling], [http://en.wikipedia.org/wiki/Cohesion_(computer_science) cohesion] and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like [http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) aggregation], [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], association between classes, and data type (smarted than [http://en.wikipedia.org/wiki/SQL SQL] data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in Figure 8.
[[Image:Wiki 3 12 6.jpg]]
Figure 8 : One-to-many mapping

==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In Figure 9, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].
[[Image:Wiki 3 12 7.jpg]]
Figure 9 : Many-to-many mapping

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

Differences between the two approaches has been tabulated below: 
{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''Type Conversion'''==
There are situations when the values in the database do not map directly to object data types. Take the Boolean data type for example. Boolean values "true" and "false" may be saved as "T" and "F" respectively in the database. Type conversion should be facilitated without any data loss.

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-22T03:08:08Z

Quick Gun Murugan:

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] principles like [http://en.wikipedia.org/wiki/Coupling_(computer_science) coupling], [http://en.wikipedia.org/wiki/Cohesion_(computer_science) cohesion] and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like [http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) aggregation], [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism], association between classes, and data type (smarted than [http://en.wikipedia.org/wiki/SQL SQL] data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in Figure 8.
[[Image:Wiki 3 12 6.jpg]]
Figure 8 : One-to-many mapping

==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In Figure 9, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].
[[Image:Wiki 3 12 7.jpg]]
Figure 9 : Many-to-many mapping

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

Differences between the two approaches has been tabulated below: 
{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for mapping objects to relational databases

2009-11-20T18:04:47Z

Quick Gun Murugan: CSC/ECE 517 Fall 2009/wiki3 12 Patterns for mapping objects to relational databases moved to CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM: Link did not appear in Expertiza.

#REDIRECT [[CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM]]

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-20T18:04:47Z

Quick Gun Murugan: CSC/ECE 517 Fall 2009/wiki3 12 Patterns for mapping objects to relational databases moved to CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM: Link did not appear in Expertiza.

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in Figure 8.
[[Image:Wiki 3 12 6.jpg]]
Figure 8 : One-to-many mapping

==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In Figure 9, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].
[[Image:Wiki 3 12 7.jpg]]
Figure 9 : Many-to-many mapping

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

Differences between the two approaches has been tabulated below: 
{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T21:30:19Z

Quick Gun Murugan: /* '''Foreign key aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

Differences between the two approaches has been tabulated below: 
{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T21:29:12Z

Quick Gun Murugan: /* '''Foreign key aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

[[Image:Index.4.png]]

{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T21:28:47Z

Quick Gun Murugan: /* '''Single table aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_2.jpg]]
Figure 1: Domain Class Figure 2: Mapper Class

For example: - To find an employee “John”.
Figure 1 represents the Employee Domain class and Figure 2 represents the corresponding Mapper Class.
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_3_a.jpg]]
Figure 3: Domain Class Figure 4: Single Table Inheritance

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_4_.jpg]]
Figure 5: Domain Class Figure 6: Class Table Inheritance

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.
[[Image:wiki_3_12.jpg]] [[Image:Wiki_3_12_5.jpg]]
Figure 6: Domain Class Figure 7: Concrete Table Inheritance

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In Figure 6, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
[[Image:Wiki_3_12_6.gif]]
Figure 6: One-to-one mapping

==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

[[Image:Index.2.png]]

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

File:Index.4.png

2009-11-18T21:28:12Z

Quick Gun Murugan:

File:Index.2.png

2009-11-18T21:27:48Z

Quick Gun Murugan:

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:42:03Z

Quick Gun Murugan: /* '''Foreign key aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

For example: - To find an employee “John”:-
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In fig, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:41:09Z

Quick Gun Murugan: /* '''Foreign key aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

For example: - To find an employee “John”:-
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In fig, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

{|border="2" cellspacing="0" cellpadding="4" width="100%" align="center"
|-
|align="center"|'''Single Table Aggregation'''
|align="center"|'''Foreign Key Aggregation'''
|-
|align="center"|Only one table needs to be accessed to retrieve an aggregating object with all its aggregated objects. On the other hand, the fields for aggregated objects’ attributes are likely to increase the number of pages retrieved with each database access, resulting in a possible waste of I/O bandwidth.
|align="center"|Needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation.
|-
|align="center"|If the same object is aggregated in more that on one object, a change in the aggregated object would require a change in a lot of database table. This pattern thus has poor maintainability.
|align="center"|Since the aggregated object has it's own table, the pattern is more maintainable and flexible.
|-
|align="center"|Aggregated objects are automatically deleted on deletion of the aggregating objects.
|align="center"|Aggregated objects are not automatically deleted on deletion of the aggregating objects.
|-
|align="center"|Ad-hoc queries are very hard to formulate.
|align="center"|Factoring out aggregated objects allows easy querying these tables with ad-hoc queries.
|}

Ad-hoc queries: Factoring out aggregated objects into separate tables allows easy querying these tables with ad-hoc queries.

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:23:57Z

Quick Gun Murugan: /* '''Foreign key aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

For example: - To find an employee “John”:-
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In fig, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

==='''Foreign key aggregation'''===
To achieve this create a table each for the aggregating and aggregated object. Create a foreign key reference between the two table by inserting a synthetic object identity into the aggregated objects type and reference it in the aggregating objects table.

Comparison

Performance: For optimal performance the solution should allow to retrieve an object with one database access without any join operations. Database accesses should fetch a minimum number of pages to economize on I/O bandwidth.

Maintainability: For optimal maintainability, aggregated types, that are aggregated in more than one object type, should be mapped to one set of tables instead of being strayed identically across many different spots in the physical data model. Normalization should be used at the data model level to ease maintenance and ad hoc queries.

Consistency of the database: Aggregation implies that the aggregated object’s life cycle is coupled with the aggregating object’s life cycle. This has to guaranteed by either the database or application code

Performance: Foreign Key Aggregation needs a join operation or at least two database accesses where Single Table Aggregation needs a single database operation. If accessing aggregated objects is a statistical rare case this is acceptable. If the aggregated objects are always retrieved together with the aggregating object, you have to have a second look at performance here.

Maintenance: Factoring out objects like the AddressTypes into tables of their own makes them easier to maintain and hence makes the mapping more flexible.

Consistency of the database: Aggregated objects are not automatically deleted on deletion of the aggregating objects. To perform this task you have to provide and maintain application kernel code or database triggers. This is also an implementation issue. You have to chose one of these two options.

Ad-hoc queries: Factoring out aggregated objects into separate tables allows easy querying these tables with ad-hoc queries.

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:11:58Z

Quick Gun Murugan: /* '''Single table aggregation''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

For example: - To find an employee “John”:-
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In fig, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
In this pattern the a table is created with the attributes of the Aggregating objects. The attributes of the Aggregating object is simple added to this table.

==='''Foreign key aggregation'''===

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:05:01Z

Quick Gun Murugan: /* '''References''' */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

For example: - To find an employee “John”:-
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In fig, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
==='''Foreign key aggregation'''===

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]http://www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:04:20Z

Quick Gun Murugan:

=='''Overview'''==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping] is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

{|border="2" cellspacing="0" cellpadding="4" width="50%" align="center"
|-
|align="center"|'''Object Oriented Data Model'''
|align="center"|'''Relational Database Management System'''
|-
|align="center"|Class
|align="center"|Table
|-
|align="center"|Object
|align="center"|Row
|-
|align="center"|Entity
|align="center"|Key
|-
|align="center"|State
|align="center"|Data
|-
|align="center"|Behavior
|align="center"|Transactions
|-
|align="center"|Inheritance
|align="center"|Data Relationships
|}

=='''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]'''==
[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance] in [http://en.wikipedia.org/wiki/Object-oriented_design Object Oriented Design] makes it difficult to map between object and relation databases. In this pattern, there is mapper class for each domain class that will save and load data for the domain class [8]. Mapper class allows both abstract and concrete classes to handle their own O/R mapping[8].

For example: - To find an employee “John”:-
Application calls find () method on concrete mapper object and instantiate a new Executive object. The find () will pass this executive object and database record to load () of Executive. This in turn will call the load () of Superclass. When all loads return, find returns the filled object.
Mappers loading and saving the domain objects is determined by the inheritance mapping. This inheritance hierarchy is represented in the database as follows:-
*Single Table Inheritance
*Class Table Inheritance
*Concrete Table Inheritance
Choosing a mapping scheme depends on speed requirement, whether database is shared and type of [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS].

==='''Single Table Inheritance'''===
Inheritance Hierarchy of all classes is represented as single table. The columns of this table will have fields of all classes in the hierarchy. Advantage of this Inheritance is that there is one table and requires no join while retrieving data. But it could lead to large confusing table and name conflicts.

==='''Class Table Inheritance '''===
One table for each class is constructed. The advantage of this table inheritance is that there is clear relationship between class and table. There is high normalization. But multiple tables requires join and when fields move up and down in hierarchy, it requires changes in the tables.

==='''Concrete Table Inheritance'''===
In this hierarchy there is one table per concrete class. The table are independent, requires no join and there is no unused fields.

The strengths and weaknesses of each approach are compared below:

{|border="2" cellspacing="0" cellpadding="4" width="70%" align="center"
|-
|align="center"|'''Factors to Consider'''
|align="center"|'''One table per hierarchy'''
|align="center"|'''One table per concrete class'''
|align="center"|'''One table per class'''
|-
|align="center"|Ad hoc reporting
|align="center"|Simple
|align="center"|Medium
|align="center"|Medium/Difficult
|-
|align="center"|Ease of implementation
|align="center"|Simple
|align="center"|Medium
|align="center"|Difficult
|-
|align="center"|Ease of data access
|align="center"|Simple
|align="center"|Simple
|align="center"|Medium/Simple
|-
|align="center"|Coupling
|align="center"|Very High
|align="center"|High
|align="center"|Low
|-
|align="center"|Speed of data access
|align="center"|Fast
|align="center"|Fast
|align="center"|Medium/Fast
|-
|align="center"|Support for polymorphism
|align="center"|Medium
|align="center"|Low
|align="center"|High
|}

=='''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) Association] Mapping'''==
The [http://en.wikipedia.org/wiki/Foreign_key Foreign key] is used to maintain relationships in relational databases. A row in one table can relate to a row in another table using foreign key. Therefore to implement relationships, a key of one table must include in the other table [4].
==='''One-to-one mapping'''===
If one record in Table A corresponds to exactly one row in Table B, this relationship is called One – to-one relationships [10]. In fig, the address attribute of an employee class forms a one-to-one relation with the address class. In database, this relationship is stored by creating one-to- one mapping between these two objects by storing the id of Address instance in the Employee table instance is written [11]. When the employee is read form database, the address instance is linked to Employee. Here, the mapping is from Employee to Address.
==='''One-to-many mapping'''===
If each record in Table A corresponds to many records in Table B , but each record in Table B links to only one record in Table A, this relationship is called One-to-many relationships [10].
In fig, a Order may have zero to many OrderItems. To represent in relational database, the Owner object’s OID can be inserted into OrderItem table [9]. Here, OID is Foreign Key. This is shown in fig .
==='''Many-to-many mapping'''===
If each record in Table A may links to many records in Table B and vice-versa [10], it’s called Many-to-Many relationships. In fig, let’s consider that an employee can work more than one department and department can contain more than one employee. 
The Many-to-Many relationships is represented in term of association table. A separate table called association table is created that contains the foreign keys of participating tables [9].

=='''[http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming) Aggregation] Mapping'''==
[http://en.wikipedia.org/wiki/Class_diagram#Aggregation Aggregation] is a specialized version of the association relationship. Aggregations may be mapped to relational data model either by integrating all objects' attributes into a single table or using foreign keys.
==='''Single table aggregation'''===
==='''Foreign key aggregation'''===

=='''References'''==
[1]http://www.objectarchitects.de/ObjectArchitects/orpatterns/ 
[2]http://subs.emis.de/LNI/Proceedings/Proceedings48/GI.Band.48-6.pdf 
[3]http://www.joeyoder.com/Research/objectmappings/Persista.pdf 
[4]http://www.ibm.com/developerworks/library/ws-mapping-to-rdb/ 
[5]http://www.dparsons.co.uk/mindthegap.pdf 
[6]http://proceedings.informingscience.org/InSITE2007/IISITv4p767-779Jusi281.pdf 
[7]http://www.sis.pitt.edu/~gray/INFSCI1025/references/AmblerORMMapping101Article.pdf 
[8]www.brettdaniel.com/files/2006/inheritancemapping.ppt 
[9]http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?MappingObjects2Tables/mapping_object.htm 
[10]http://databases.about.com/cs/tutorials/a/accessgup7.htm 
[11]http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/relmapun005.htm 
[12]http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:01:55Z

Quick Gun Murugan: /* '''Aggregation Mapping''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T01:01:03Z

Quick Gun Murugan: /* '''Association Mapping''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-18T00:59:50Z

Quick Gun Murugan: /* '''Aggregation Mapping''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T23:57:36Z

Quick Gun Murugan: /* '''Association Mapping''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T23:47:53Z

Quick Gun Murugan: /* '''Concrete Table Inheritance''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T23:47:14Z

Quick Gun Murugan:

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T23:38:19Z

Quick Gun Murugan: /* '''Overview''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T18:13:00Z

Quick Gun Murugan: /* '''Overview''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T18:05:06Z

Quick Gun Murugan: /* '''[http://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html Inheritance Mapping]''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T18:03:21Z

Quick Gun Murugan: /* '''Concrete Table Inheritance''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T18:02:32Z

Quick Gun Murugan: /* '''Single Table Inheritance''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T18:02:13Z

Quick Gun Murugan: /* '''Class Table Inheritance ''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T17:52:20Z

Quick Gun Murugan: /* '''Inheritance Mapping''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T17:45:38Z

Quick Gun Murugan: /* '''Overview''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T17:00:09Z

Quick Gun Murugan: /* '''Overview''' */

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T16:33:10Z

Quick Gun Murugan:

=='''Overview'''==
Object-relational mapping is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

CSC/ECE 517 Fall 2009/wiki3 12 Patterns for ORM

2009-11-17T16:32:26Z

Quick Gun Murugan:

=Overview
Object-relational mapping is not trivial. Apart from being based on Software Engineering principles like coupling, cohesion and polymorphism, the object paradigm focuses on building applications out of objects that have both data and behavior. However, the relational paradigm is based on mathematical principles and focuses primarily on storing data. If only data objects were to be mapped to the relational database the procedure would have been fairly straightforward. With the growing complexities of object models, concepts like aggregation, inheritance, polymorphism, association between classes, and data type (smarted than SQL data types) have to be mapped to relational table structure. The table below highlights the fundamental mismatch between object oriented data model and relational data storage.

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T02:02:53Z

Quick Gun Murugan: /* Pree's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/State_pattern State], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
** [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]: Bundle the constructors of a family of related objects into one object.
* State Handling: generic manipulation of object state.
** [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]: Guarantee single instance of a class.
** [http://en.wikipedia.org/wiki/Prototype_pattern Prototype]: Create new objects by cloning an existing one (the prototype).
** [http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]: Save space by sharing common state among objects.
** [http://en.wikipedia.org/wiki/Memento_pattern Memento]: save and restore an object’s internal state.
* Control: control of execution and method selection.
** [http://en.wikipedia.org/wiki/Blackboard_system Blackboard]: Dynamically decide which transformers (knowledge sources) to apply to a shared data structure.
** [http://en.wikipedia.org/wiki/Command_pattern Command]: Separate composition of a request from the time it is executed.
** [Chain of Responsibility]: Pass a request down a chain of objects until an object handles it.
* Virtual Machines: simulated processors.
** Interpreter: Execute a program written in the inter-preter’s language.
** Rule-based Interpreter: Execute a rule set using a fact base.
* Convenience Patterns: simplified coding.
** Convenience Method: Simplify method invocations by suppressing parameters whose values are the same for many calls.
** Convenience Class: Simplify method invocations by storing parameter values in the class.
** Default Class: Provide a default implementation of a class that normally must be reimplemented by the client. Subclasses override only the methods for which the defaults are inappropriate.
** [http://en.wikipedia.org/wiki/Null_Object_pattern Null object]: Eliminate frequent tests for null references by replacing null references with a reference to the null object.
* Compound Patterns: patterns composed from others, with the original patterns visible.
** [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller]: Provide multiple, dynamic views on shared data and dynamically change responses to user input.
** Bureaucracy: Organize objects in a hierarchical structure such that it maintains its inner consistency by itself.
** Active Bridge: Connect an application to event-driven resouces in a portable way.
* [http://en.wikipedia.org/wiki/Concurrency_pattern Concurrency]: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.
** [http://www.eventhelix.com/RealTimeMantra/PatternCatalog/protocol_stack.htm Protocol Stack]

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T02:01:57Z

Quick Gun Murugan: /* Zimmer's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern Mediator], [http://en.wikipedia.org/wiki/Facade_pattern Facade], [http://en.wikipedia.org/wiki/Memento_pattern Memento], [http://en.wikipedia.org/wiki/Iterator_pattern Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern Builder], [http://en.wikipedia.org/wiki/Strategy_pattern Strategy], [http://en.wikipedia.org/wiki/Observer_pattern Observer], [http://en.wikipedia.org/wiki/Bridge_pattern Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method], [http://en.wikipedia.org/wiki/State_pattern State], [http://en.wikipedia.org/wiki/Command_pattern Command], [http://en.wikipedia.org/wiki/Visitor_pattern Visitor], [http://en.wikipedia.org/wiki/Composite_pattern Composite], [http://en.wikipedia.org/wiki/Decorator_pattern Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
** [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]: Bundle the constructors of a family of related objects into one object.
* State Handling: generic manipulation of object state.
** [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]: Guarantee single instance of a class.
** [http://en.wikipedia.org/wiki/Prototype_pattern Prototype]: Create new objects by cloning an existing one (the prototype).
** [http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]: Save space by sharing common state among objects.
** [http://en.wikipedia.org/wiki/Memento_pattern Memento]: save and restore an object’s internal state.
* Control: control of execution and method selection.
** [http://en.wikipedia.org/wiki/Blackboard_system Blackboard]: Dynamically decide which transformers (knowledge sources) to apply to a shared data structure.
** [http://en.wikipedia.org/wiki/Command_pattern Command]: Separate composition of a request from the time it is executed.
** [Chain of Responsibility]: Pass a request down a chain of objects until an object handles it.
* Virtual Machines: simulated processors.
** Interpreter: Execute a program written in the inter-preter’s language.
** Rule-based Interpreter: Execute a rule set using a fact base.
* Convenience Patterns: simplified coding.
** Convenience Method: Simplify method invocations by suppressing parameters whose values are the same for many calls.
** Convenience Class: Simplify method invocations by storing parameter values in the class.
** Default Class: Provide a default implementation of a class that normally must be reimplemented by the client. Subclasses override only the methods for which the defaults are inappropriate.
** [http://en.wikipedia.org/wiki/Null_Object_pattern Null object]: Eliminate frequent tests for null references by replacing null references with a reference to the null object.
* Compound Patterns: patterns composed from others, with the original patterns visible.
** [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller]: Provide multiple, dynamic views on shared data and dynamically change responses to user input.
** Bureaucracy: Organize objects in a hierarchical structure such that it maintains its inner consistency by itself.
** Active Bridge: Connect an application to event-driven resouces in a portable way.
* [http://en.wikipedia.org/wiki/Concurrency_pattern Concurrency]: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.
** [http://www.eventhelix.com/RealTimeMantra/PatternCatalog/protocol_stack.htm Protocol Stack]

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T02:00:36Z

Quick Gun Murugan: /* Tichy's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
** [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]: Bundle the constructors of a family of related objects into one object.
* State Handling: generic manipulation of object state.
** [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]: Guarantee single instance of a class.
** [http://en.wikipedia.org/wiki/Prototype_pattern Prototype]: Create new objects by cloning an existing one (the prototype).
** [http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]: Save space by sharing common state among objects.
** [http://en.wikipedia.org/wiki/Memento_pattern Memento]: save and restore an object’s internal state.
* Control: control of execution and method selection.
** [http://en.wikipedia.org/wiki/Blackboard_system Blackboard]: Dynamically decide which transformers (knowledge sources) to apply to a shared data structure.
** [http://en.wikipedia.org/wiki/Command_pattern Command]: Separate composition of a request from the time it is executed.
** [Chain of Responsibility]: Pass a request down a chain of objects until an object handles it.
* Virtual Machines: simulated processors.
** Interpreter: Execute a program written in the inter-preter’s language.
** Rule-based Interpreter: Execute a rule set using a fact base.
* Convenience Patterns: simplified coding.
** Convenience Method: Simplify method invocations by suppressing parameters whose values are the same for many calls.
** Convenience Class: Simplify method invocations by storing parameter values in the class.
** Default Class: Provide a default implementation of a class that normally must be reimplemented by the client. Subclasses override only the methods for which the defaults are inappropriate.
** [http://en.wikipedia.org/wiki/Null_Object_pattern Null object]: Eliminate frequent tests for null references by replacing null references with a reference to the null object.
* Compound Patterns: patterns composed from others, with the original patterns visible.
** [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller]: Provide multiple, dynamic views on shared data and dynamically change responses to user input.
** Bureaucracy: Organize objects in a hierarchical structure such that it maintains its inner consistency by itself.
** Active Bridge: Connect an application to event-driven resouces in a portable way.
* [http://en.wikipedia.org/wiki/Concurrency_pattern Concurrency]: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.
** [http://www.eventhelix.com/RealTimeMantra/PatternCatalog/protocol_stack.htm Protocol Stack]

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T01:40:17Z

Quick Gun Murugan: /* Tichy's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
** [http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]: Bundle the constructors of a family of related objects into one object.
* State Handling: generic manipulation of object state.
** [http://en.wikipedia.org/wiki/Singleton_pattern Singleton]: Guarantee single instance of a class.
** [http://en.wikipedia.org/wiki/Prototype_pattern Prototype]: Create new objects by cloning an existing one (the prototype).
** [http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]: Save space by sharing common state among objects.
** [http://en.wikipedia.org/wiki/Memento_pattern Memento]: save and restore an object’s internal state.

* Control: control of execution and method selection.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki1b 12 Schemes for Pattern Classification

2009-10-13T01:25:42Z

Quick Gun Murugan: CSC/ECE 517 Fall 2009/wiki1b 12 Schemes for Pattern Classification moved to CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

#REDIRECT [[CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification]]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T01:25:42Z

Quick Gun Murugan: CSC/ECE 517 Fall 2009/wiki1b 12 Schemes for Pattern Classification moved to CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T01:22:55Z

Quick Gun Murugan: /* Gang of Four's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T01:19:02Z

Quick Gun Murugan: /* Gang of Four's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"
|align="center"|[http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T01:17:42Z

Quick Gun Murugan: /* Gang of Four's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern Memento]
|-
|rowspan="5" align="center"
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern Strategy]
|-
|rowspan="2" align="center"
|align="center" [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T01:15:48Z

Quick Gun Murugan: /* Tichy's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern| Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern| Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern| Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern| Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern| Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern| Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern| Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern| Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern| Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern| Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern| Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern| Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern| State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern| Strategy]
|-
|rowspan="2" align="center"|
|align="center"| [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.
* Variant Management: treating different objects uniformly by factoring out their commonality.
** Superclass: Provide uniform treatment of variant classes by placing common interface into a super-class; variants are subclasses. Example:
*** [http://en.wikipedia.org/wiki/Strategy_pattern Strategy pattern].
*** [http://en.wikipedia.org/wiki/Composite_pattern Composite pattern].
** [http://en.wikipedia.org/wiki/Visitor_pattern Visitor]: Add new variations of operations to stable class hierarchy.
** [http://en.wikipedia.org/wiki/Template_method_pattern Template Method]: Specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T00:59:29Z

Quick Gun Murugan: /* Tichy's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern| Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern| Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern| Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern| Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern| Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern| Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern| Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern| Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern| Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern| Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern| Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern| Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern| State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern| Strategy]
|-
|rowspan="2" align="center"|
|align="center"| [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: Hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
** Pipeline: Pass data through a sequence of transformations (filters) connected by channels (pipes).
** Event Notification: Let independent parts interact by an-nouncing and responding to events (loose coupling).
** Framework: Provide a complete or nearly complete application layer that can be extended by sub-classing.

* Variant Management: treating different objects uniformly by factoring out their commonality.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T00:51:05Z

Quick Gun Murugan: /* Tichy's Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern| Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern| Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern| Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern| Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern| Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern| Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern| Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern| Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern| Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern| Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern| Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern| Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern| State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern| Strategy]
|-
|rowspan="2" align="center"|
|align="center"| [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: The purpose of this design pattern is to hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: The purpose of ADT hide data structure and access algorithms behind a change-insensitive interface. The purpose of ADT is similar to that of Module, but an ADT is typically smaller, containing a single data type. Examples:
*** Repository pattern[8].
*** [http://en.wikipedia.org/wiki/Iterator_pattern Iterator pattern].
** Layers: The purpose of a layer is to provides an interface and an implementation of this interface. Example:
*** [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern].
*** [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern].
*** [http://en.wikipedia.org/wiki/Adapter_pattern Adapter pattern].
*** [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern].
* Variant Management: treating different objects uniformly by factoring out their commonality.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T00:32:06Z

Quick Gun Murugan: /* References */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern| Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern| Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern| Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern| Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern| Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern| Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern| Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern| Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern| Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern| Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern| Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern| Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern| State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern| Strategy]
|-
|rowspan="2" align="center"|
|align="center"| [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: The purpose of this design pattern is to hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Some examples of ADT
***

* Variant Management: treating different objects uniformly by factoring out their commonality.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

=='''References'''==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]

CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

2009-10-13T00:31:23Z

Quick Gun Murugan: /* Schemes for Pattern Classification */

=='''Overview'''==
[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design patterns] in [http://en.wikipedia.org/wiki/Software_engineering software engineering] is a time-tested reusable solution to recurring problems in [http://en.wikipedia.org/wiki/Software_design software design]. The origin of design patterns can be owed to the work of civil engineer [http://en.wikipedia.org/wiki/Christopher_Alexander Christopher Alexander], who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developers. From then on design patterns became increasingly popular.

=='''Schemes for Pattern Classification'''==
===Gang of Four's Classification===
Design Patterns gained popularity with the book [http://en.wikipedia.org/wiki/Design_Patterns_(book) Design Patterns: Elements of Reusable Object-Oriented Software] by [http://en.wikipedia.org/wiki/Erich_Gamma Erich Gamma], [http://en.wikipedia.org/wiki/Richard_Helm Richard Helm], [http://en.wikipedia.org/wiki/Ralph_Johnson Ralph Johnson] and [http://en.wikipedia.org/wiki/John_Vlissides John Vlissides] published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].
* What does the pattern do?
** [http://en.wikipedia.org/wiki/Structural_pattern Structural] - These patterns deal with the composition of classes and their object.
** [http://en.wikipedia.org/wiki/Creational_pattern Creational] - These patterns deal with object creation.
** [http://en.wikipedia.org/wiki/Behavioral_pattern Behavioral] - These patterns deal with the interaction between classes and object and how they delegate responsibility.

* What is the scope of the pattern?
** Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
** Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|+ Example of Design Patterns that fall into each Category
|colspan="5" align="center"|'''Purpose'''
|-
|align="center"|'''Scope'''
|align="center"|'''Creational'''
|align="center"|'''Structural'''
|align="center"|'''Behavioral'''
|-
|rowspan="2" align="center"|Class
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method]
|rowspan="2" align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (class)]
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|-
|align="center"|[http://en.wikipedia.org/wiki/Template_method_pattern| Template Method]
|-
|rowspan="9" align="center"|Object
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory]
|align="center"|[http://en.wikipedia.org/wiki/Adapter_pattern| Adapter (object)]
|align="center"|[http://en.wikipedia.org/wiki/Command_pattern| Command]
|-
|align="center"|[http://en.wikipedia.org/wiki/Prototype_pattern| Prototype]
|align="center"|[http://en.wikipedia.org/wiki/Composite_pattern| Composite]
|align="center"|[http://en.wikipedia.org/wiki/Mediator_pattern| Mediator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Builder_pattern| Builder]
|align="center"|[http://en.wikipedia.org/wiki/Bridge_pattern| Bridge]
|align="center"|[http://en.wikipedia.org/wiki/Iterator_pattern| Iterator]
|-
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton]
|align="center"|[http://en.wikipedia.org/wiki/Decorator_pattern| Decorator]
|align="center"|[http://en.wikipedia.org/wiki/Memento_pattern| Memento]
|-
|rowspan="5" align="center"|
|align="center"|[http://en.wikipedia.org/wiki/Facade_pattern| Facade]
|align="center"|[http://en.wikipedia.org/wiki/Observer_pattern| Observer]
|-
|align="center"|[http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight]
|align="center"|[http://en.wikipedia.org/wiki/State_pattern| State]
|-
|align="center"|[http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|align="center"|[http://en.wikipedia.org/wiki/Strategy_pattern| Strategy]
|-
|rowspan="2" align="center"|
|align="center"| [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor]
|-
|align="center"|[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility]
|}

===Zimmer's Classification===
Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :
* X uses Y in its solution.
** The [http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter] design pattern uses the [http://en.wikipedia.org/wiki/Composite_pattern| Composite] design patter.
** The [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype] design pattern uses the [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] design pattern.
* Variant of X uses Y in its solution.
** Some variant of the [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge] design pattern may uses the [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter] design pattern.
* X is similar to Y.
** The [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator] design pattern is similar to the [http://en.wikipedia.org/wiki/Facade_pattern| Facade] design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

{|border="2" cellspacing="0" cellpadding="4" width="100%"
|align="center"|'''Layer'''
|align="center"|'''Design Pattern'''
|-
|align="center"|Basic design patterns and techniques.
|align="center"|[http://en.wikipedia.org/wiki/Singleton_pattern| Singleton], [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method], [http://en.wikipedia.org/wiki/Mediator_pattern| Mediator], [http://en.wikipedia.org/wiki/Facade_pattern| Facade], [http://en.wikipedia.org/wiki/Memento_pattern| Memento], [http://en.wikipedia.org/wiki/Iterator_pattern| Iterator], [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight].
|-
|align="center"|Design patterns for typical software problems.
|align="center"|[http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory], [http://en.wikipedia.org/wiki/Builder_pattern| Builder], [http://en.wikipedia.org/wiki/Strategy_pattern| Strategy], [http://en.wikipedia.org/wiki/Observer_pattern| Observer], [http://en.wikipedia.org/wiki/Bridge_pattern| Bridge], [http://en.wikipedia.org/wiki/Adapter_pattern| Adapter], [http://en.wikipedia.org/wiki/Prototype_pattern| Prototype], [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method], [http://en.wikipedia.org/wiki/State_pattern| State], [http://en.wikipedia.org/wiki/Command_pattern| Command], [http://en.wikipedia.org/wiki/Visitor_pattern| Visitor], [http://en.wikipedia.org/wiki/Composite_pattern| Composite], [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator], [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility], [http://en.wikipedia.org/wiki/Proxy_pattern| Proxy]
|-
|align="center"|Design patterns specific to an application domain.
|align="center"|[http://en.wikipedia.org/wiki/Interpreter_pattern| Interpreter]
|}

===Coad's Classification===
In 1992 Peter Coad published his first article of design patterns. According to Coad, design patterns are identified observing classes, objects and the relationships established between them[5]. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad along with David North and Mark Mayfield organized patterns into various pattern families[4].
* '''Fundamental Pattern''': This pattern is the template that all the other patterns follow.
** Collection-Worker Pattern is the fundamental object model pattern.
* '''Transaction Patterns''': These either have transaction players or have players that commonly play with the transaction player. The transaction patterns are:
** Actor-Participant pattern.
** Participant-Transaction pattern.
** Place-Transaction pattern.
** Specific Item-Transaction pattern.
** Transaction-Transaction Line Item pattern.
** Transaction-Subsequent Transaction pattern.
** Transaction Line Item-Subsequent Transaction Line Item pattern.
** Item-Line Item pattern.
** Specific Item-Line Item.
** Item-Specific Item.
** Associate-Other Associate.
** Specific Item-Hierarchical Item.
* '''Aggregate Patterns''': These patterns interconnect with other patterns. The aggregate patterns are:
** Container-Content pattern.
** Container-Container Line Item pattern.
** Group-Member.
** Assembly-Part pattern.
** Compound Part-Part pattern.
** Packet-Packet Component.
* '''Plan Patterns''': The plan patterns are:
** Plan-Step pattern.
** Plan-Plan Execution pattern.
** Plan Execution-Step Execution pattern.
** Step-Step Execution pattern.
** Plan-Plan Version pattern.
* '''Interaction Patterns''': These patterns, as the name suggests are patterns of interaction. The interaction patterns are:
** Peer-Peer pattern.
** Proxy-Specific Item pattern.
** Publisher-Subscriber pattern.
** Sender-Pass Through-Receiver pattern.
** Sender-Lookup-Receiver pattern.
** Caller-Dispatcher-Caller Back pattern.
** Gatekeeper-Request-Resource pattern.

===Pree's Classification===
In his book Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995, Wolfgang Pree categorized Coad's patterns into[5]:
* '''Basic inheritance and interaction patterns:''' These patterns encompass primarily the basic modelling capabilities offered by object oriented programming languages.
* '''Patterns for structuring object-oriented software systems: '''Most of Coad's patterns belong to this category.
* '''Patterns related to the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC] framework: ''' Those of Coad's patterns that stress the framework aspect are derivatives of the Model/View/Controller framework.
Ignoring the fine-grained[5] pattern classification proposed by Gamma's catalog, Pree applied the following classification of the listed patterns.
* '''Patterns relying on abstract coupling: '''Most of the patterns in the catalog are based on abstractly coupled classes. [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method pattern] and [http://en.wikipedia.org/wiki/Observer_pattern| Observer pattern] for example.
* '''Patterns based on recursive structures: ''' [http://en.wikipedia.org/wiki/Composite_pattern| Composite] pattern, [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern| Chain Of Responsibility] pattern, [http://en.wikipedia.org/wiki/Decorator_pattern| Decorator] pattern are all based on recursive structures.
* '''Other Catalog patterns''': Pree summarized the rest of the patterns as follows:
** An [http://en.wikipedia.org/wiki/Abstract_factory_pattern| Abstract Factory] pattern is close to the [http://en.wikipedia.org/wiki/Factory_method_pattern| Factory Method] pattern
** [http://en.wikipedia.org/wiki/Flyweight_pattern| Flyweight] pattern represents a pattern similar to Coad's Item-Description pattern.
** [http://en.wikipedia.org/wiki/Singleton_pattern| Singleton] pattern is a coding patterns that limits the number of creatable instances of a class to one.
** [http://en.wikipedia.org/wiki/Template_method_pattern| Template Method] pattern forms the basis of all patterns dealing with with abstract classes.

==='''Buschman et. al's Classification'''===
Frank Buschman and Regine Meunier identified the following categories[6]:
* '''Granularity: ''' Three levels of granularity can be specified.
** [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural Framework]: Every software architecture is built according to an overall structuring principles described by architectural frameworks. Example: The [http://en.wikipedia.org/wiki/Model-view-controller Model-View-Controller] framework.
** [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns]: These can be described as the smaller architectural units.
** [http://en.wikipedia.org/wiki/Programming_idiom Idioms]: Idioms represent the lowest level of a pattern and are closely related to a particular programming language. Example: [http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Counted_Body The Counted Body] Idiom.

*'''Functionality: '''Each pattern serves as a means to implement a particular functionality. The following categories of functionality can be distinguished:
** Creation of objects: Patterns may specify how to create particular instances of complex recursive or aggregate object structures. Example: [http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern]
** Guiding Communication between objects: Patterns may describe how to organize communication between a set of collaborating objects.
** Access to objects: Patterns may describe how to access the services and state of shared or remote objects in a safe way. Example: [http://en.wikipedia.org/wiki/Proxy_pattern Proxy pattern]
** Organizing the computation of the complex tasks: Patterns may specify how to distribute responsibilities among cooperating objects in order to solve a more complex task. Example: [http://en.wikipedia.org/wiki/Command_pattern Command pattern]

*'''Structural Principles: ''' To achieve their functionality, patterns rely on certain architectural principles. These principles can be categorized as:
** Abstraction: A pattern provides an abstract view of a particular entity or task in a software system. Example: [http://en.wikipedia.org/wiki/Facade_pattern Facade pattern]
** Encapsulation: A pattern encapsulates details of a particular object, component, or service to remove dependencies on it from its clients or to protect these details from access. Example: [http://en.wikipedia.org/wiki/Mediator_pattern Mediator pattern]
** Separation of concerns: A pattern factors out specific responsibilities into separate objects or components.
** Coupling and Cohesion: A patterns removes dependencies between strongly coupled objects. Example: [http://en.wikipedia.org/wiki/Bridge_pattern Bridge pattern]

This classification scheme is not intended as a means of picking out the right pattern, but merely a guide for designers helping them search for the pattern appropriate for a particular situation.

===Tichy's Classification===
Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:
* Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
** Modules([http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation Encapsulation]/[http://en.wikipedia.org/wiki/Information_hiding Information Hiding])[7]: The purpose of this design pattern is to hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
*** [http://en.wikipedia.org/wiki/Modula Modula's] modules.
*** [http://en.wikipedia.org/wiki/C_(programming_language) C's] header files.
***[http://en.wikipedia.org/wiki/Ada_(programming_language) Ada's] packages.
** Abstract Data Type[ADT]: Some examples of ADT
***

* Variant Management: treating different objects uniformly by factoring out their commonality.
* State Handling: generic manipulation of object state.
* Control: control of execution and method selec-tion.
* Virtual Machines: simulated processors.
* Convenience Patterns: simplified coding.
* Compound Patterns: patterns composed from others, with the original patterns visible.
* Concurrency: controlling parallel and concurrent execution.
* Distribution: problems germane to distributed systems.

==References==
[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm 
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm 
[3] [http://reference.kfupm.edu.sa/content/r/e/relationships_between_design_patterns__148528.pdf Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995] 
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995. 
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995. 
[6] Frank Buschman and Regine Meunier. “A System of Patterns." In J. O. Coplien and D. C. Schmidt (eds.), Pattern Languages of Program Design. Reading, MA: Addison-Wesley, 1995, pp. 325-343. 
[6] [http://wwwipd.ira.uka.de/~tichy/publications/Catalogue.doc Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.] 
[7] [http://doi.acm.org/10.1145/361598.361623 Parnas, D. L. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (Dec. 1972), 1053-1058.] 
[8] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University]