Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-08-01T02:01:02Z

Bsriship: /* External links */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication; they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develop code for short term. Following patterns can help make your code more reusable and readable but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to [http://en.wikipedia.org/wiki/Refactoring refactor] the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to [http://davidhayden.com/blog/dave/archive/2005/03/28/903.aspx Expert Pattern], we need to assign this responsibility to Sales. However, there are a large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task; therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use pure fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]
*[http://www.mindspring.com/~mgrand/pattern_synopses2.htm Software Pattern Synopses]
* Book - Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-08-01T02:00:44Z

Bsriship: /* External links */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication; they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develop code for short term. Following patterns can help make your code more reusable and readable but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to [http://en.wikipedia.org/wiki/Refactoring refactor] the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to [http://davidhayden.com/blog/dave/archive/2005/03/28/903.aspx Expert Pattern], we need to assign this responsibility to Sales. However, there are a large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task; therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use pure fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]
*[http://www.mindspring.com/~mgrand/pattern_synopses2.htm Software Pattern Synopses]
* Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-08-01T02:00:09Z

Bsriship: /* External links */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication; they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develop code for short term. Following patterns can help make your code more reusable and readable but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to [http://en.wikipedia.org/wiki/Refactoring refactor] the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to [http://davidhayden.com/blog/dave/archive/2005/03/28/903.aspx Expert Pattern], we need to assign this responsibility to Sales. However, there are a large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task; therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use pure fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]
*[http://www.mindspring.com/~mgrand/pattern_synopses2.htm Software Pattern Synopses]
* Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition
by Craig Larman
[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T18:24:04Z

Bsriship: /* Introduction */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to [http://en.wikipedia.org/wiki/Refactoring refactor] the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to [http://davidhayden.com/blog/dave/archive/2005/03/28/903.aspx Expert Pattern], we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use pure fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T18:23:39Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to [http://en.wikipedia.org/wiki/Refactoring refactor] the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to [http://davidhayden.com/blog/dave/archive/2005/03/28/903.aspx Expert Pattern], we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use pure fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:35:28Z

Bsriship: /* Where not to use Pure Fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use pure fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:30:34Z

Bsriship: /* Introduction */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use Pure Fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:21:48Z

Bsriship: /* Where not to use Pure Fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use Pure Fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).

2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:21:19Z

Bsriship: /* How would you classify it */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

== Where not to use Pure Fabrication ==
1. Pure fabrication should be used only when necessary. It should not be overused as in general, its not a good thing to separate behavior from the relevant information. In case of the above example of sales instances, sale could use another fabricated class to add a line item: SalesLineItemAdder. But that increases the complexity of the system. It also increases coupling as it leads to a class that knows things (the Sale) and another class that does things with that knowledge (SalesLineItemAdder).
2. Also, pure fabrication violates a basic OO principle "Do not talk to strangers". So in places where maintaining data and is crucial pure fabrication should not be used.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:11:30Z

Bsriship: /* External links */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]
*[http://www.christmann.ws/ucis342/class9/class9.html Object Oriented Analysis and Logical design]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:09:52Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

[[Image:SalesStorage.gif]]

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:07:15Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]
* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.gif]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.
[[Image:SalesStorage.gif]]

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

File:SalesStorage.gif

2008-07-25T16:06:41Z

Bsriship:

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T16:06:14Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]

* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database. Also, there is low cohesion because the Sales class performs more than one function.
[[Image:LowCohesion.jpg]]

One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.
[[Image:SalesStorage.gif]]

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

File:BadCohesion.gif

2008-07-25T16:01:00Z

Bsriship:

File:LowCohesion.gif

2008-07-25T15:59:20Z

Bsriship:

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T15:58:05Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]

* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database.
[[Image:LowCohesion.jpg]]
One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

* Example 2 - This is a practical application of pure fabrication. The problem is to data bind a combo box to a domain object that has a property of some enum type?

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T15:56:27Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]

* Example 1 -Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database.
[[Image:Example.jpg]]
One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as SalesStorage. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

* Example 2 - This is a practical application of pure fabrication. The problem is to data bind a combo box to a domain object that has a property of some enum type?

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T15:42:46Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]

Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However, there are large number of database operations performed. In this case, we are coupling our application to the database. Also, saving objects in a database is a common task, therefore, many classes need to know how to work with the database.
One of the easy solution is to create a class that is solely responsible for saving objects in the database. Let us name this class as PersistentManager. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T15:38:23Z

Bsriship: /* Why pure fabrication? */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]

Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However,

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T15:37:42Z

Bsriship: /* Suggestion of where to use pure fabrication */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Let us consider another scenario, a system in which we may need a class that is solely responsible for saving objects in relational database. Let us name this class as PersistentManager. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]

Let us consider another example of saving sale instances in a database. According to Expert Pattern, we need to assign this responsibility to Sales. However,

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-25T15:34:52Z

Bsriship: /* Introduction */

==Pure fabrication==

Sometimes it is a good idea to introduce into a
system an object that has no counterpart in the real world. This is
called the pure fabrication pattern. Find examples of pure
fabrication, and weave them into a narrative that can teach
programmers when it is helpful and when it is not helpful to fabricate
objects.
== Introduction ==
Programming all code by a [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 design pattern]] can make the code more readable and easy to manipulate in the future. What do you do when you don't have any patterns that actually work in the design? A pure fabrication is a class that does not represent a concept in the problem domain. It is specially made up to achieve low coupling, high cohesion, and the reuse potential only if needed. So in code where you need to put something in and you can't come up with a pattern to match it, it may be time to just write the code and worry about a perfect solution later.

Strictly speaking, [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Pure Fabrication] is more of a design strategy than a design pattern. It helps designers create flexible solutions to a problem, and isolate changes to a subset of objects in applications to preserve the low-coupling and high cohesion of classes in design and to increase software maintainability. Pure fabrication can be thought of assigning a highly cohesive set of responsibilities to an artificial class.

=== Why pure fabrication? ===
We do not want our clients to know the fine grained entities to the client, so we'll have to provide a high level view to them. To achieve this, we do not want to change the interface of the entity. Therefore, to solve this problem, we can provide an additional element that provides a distributable view to the system. It also facilitates the co-ordination of the business entities, so that they still remain independent of each other. This approach is called "Pure Fabrication", because, from the business point of view, an insignificant class was introduced to decouple the client from the business objects.

* Pure fabrication is used when an operation does not conceptually belong to any object. For example, a class is not conceptually related to relational database, but it may be used to manage the database. Following the natural contours of the problem, you can implement these operations in services. It is known as "Pure Fabrication" in GRASP.

* Let us consider another scenario, a system in which we may need a class that is solely responsible for saving objects in relational database. Let us name this class as PersistentManager. It will take care of the insert, update, delete etc. operations. It encapsulates the database from the clients, by providing them coarse view of database operations. Also, it facilitates co-ordination among different databases. The PersistentManager class is itself relatively cohesive and has the sole purpose of managing and storing objects. It is a generic and reusable object and a good example of pure fabrication.

* The controller, in a MVC architecture can be viewed as an elegant example of pure fabrication pattern.

==How would you classify it ==
Pure Fabrication is classified as one of the nine [http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx GRASP Patterns] that help aid developers in assigning responsibilities to objects in your web applications and winform applications. [http://en.wikipedia.org/wiki/Factory_method_pattern Factories] are very similar to pure fabrication, they help with object persistence and object creation. They delegate object reconstitution and creation to specialized classes so domain objects are mere data containers and behaviors that act on that data. Most code is created for a specific application. Plug-in and refactoring can help redesign code to be used in the next generation. At some point when your developing code you may decide that the life cycle of the code is short and so you develope code for short term. Following patterns can help make your code more reusable and readble but in some situations writing code for just that application where it doesn't follow any pattern is the best choice

===Suggestion of where to use pure fabrication===
Sometimes you may be ask to modify code that hasn't been developed well or you will need to refactor the code to make it useful. In this situation you may just want to write a coupler that allows the code to go between the new code and the old. This would allow you to finish the job and help prevent a complete rewrite of the old code. The coupler would be considered pure fabrication because it will never be used again.

[[Image:PureFab.gif]]

=Conclusion=
Sometimes its better to develop something that works better in your code but isn't a perfect pattern. The Pure Fabrication Pattern is where you add classes into your application to create [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#High_Cohesion high cohesion] and [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Low_Coupling low coupling]. Today with code changing at a rapid pace it may be easier to design something one time and redesign it or refactor it later. We need to remember to let Design Patterns emerge, don't force them in
just for the sake of using a pattern. Always use the simplest solution that meets your needs, even if it doesn't include a pattern.

==External links==
*[http://davidhayden.com/blog/dave/archive/2005/09/18/2476.aspx Grasp Pattern]
*[http://codebetter.com/blogs/david.hayden/archive/2006/08/26/Over_2D00_Architecting-Via-Pure-Fabrication-and-Indirection-to-Reduce-Coupling.aspx Over-Architecting Via Pure Fabrication]
*[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)#Pure_Fabrication Grasp OOD]
*[http://web.njit.edu/~gblank/cis683/Larman%20Chapter%2025.ppt GRASP Pure Fabrication]
*[http://www.ibm.com/developerworks/rational/library/jun07/cuellar/ the case for High Cohesion and low coupling]
*[http://ai.ee.ccu.edu.tw/oose/Fall05/notes/sec-Ch05.pdf Pattern oriented software development]
*[http://alcor.concordia.ca/~smw/comp354/L22web-2x2.pdf Pure Fabrication Notes]

[[CSC/ECE 517 Summer 2008/wiki3 Assignment|Back to the assignment page]]

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T18:02:37Z

Bsriship: /* Introduction */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T18:01:16Z

Bsriship: /* Introduction */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T17:55:01Z

Bsriship:

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:37:19Z

Bsriship: /* Introduction */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:35:48Z

Bsriship: /* External links */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:33:19Z

Bsriship: /* External links */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:29:14Z

Bsriship: /* External links */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:27:39Z

Bsriship: /* Why pure fabrication? */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:25:38Z

Bsriship: /* Why pure fabrication? */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:25:20Z

Bsriship: /* Introduction */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:25:02Z

Bsriship: /* Introduction */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T14:19:15Z

Bsriship: /* Why pure fabrication? */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T13:59:12Z

Bsriship: /* Why pure fabrication? */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T13:57:52Z

Bsriship: /* Why pure fabrication? */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T13:57:22Z

Bsriship: /* Why pure fabrication? */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T13:57:02Z

Bsriship: /* Why pure fabrication? */

File:PureFabrication.jpg

2008-07-24T13:56:31Z

Bsriship: Pure Fabrication

Pure Fabrication

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T13:56:00Z

Bsriship: /* Why pure fabrication? */

CSC/ECE 517 Summer 2008/wiki3 1 PF

2008-07-24T13:50:28Z

Bsriship: /* Introduction */

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T20:40:03Z

Bsriship: /* Advantages of high cohesion */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show. One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}

*Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack. Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* High cohesion makes it easier to replace a module by another one that provides same functionality.
* High cohesion reduces complexity of the system, and hence increase the application's reliability.
* If the module is highly cohesive, the software is more readable and maintainable.
* Communication between developers is easier.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling. It can be achieved in the following ways -
* Number of messages passed between objects can be reduced.
* Messages can be simplified using few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling. It can be achieved by -
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling. It can be achieved in the following ways -
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Object interaction complexity associated with coupling can lead to increased error generation during development.
* Decreases the scalability of the application software. Changing requirements in one part of software will potentially require wide ranging changes in the entire application.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.
* Testability is likely to degrade with a more highly coupled system of objects.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.

'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T20:39:28Z

Bsriship: /* Cohesion and Coupling Examples */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show. One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}

*Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack. Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* High cohesion makes it easier to replace a module by another one that provides same functionality.
* High cohesion reduces complexity of the system, and hence increase the application's reliability.
* If the module is highly cohesive, the software is more readable and maintainable.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling. It can be achieved in the following ways -
* Number of messages passed between objects can be reduced.
* Messages can be simplified using few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling. It can be achieved by -
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling. It can be achieved in the following ways -
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Object interaction complexity associated with coupling can lead to increased error generation during development.
* Decreases the scalability of the application software. Changing requirements in one part of software will potentially require wide ranging changes in the entire application.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.
* Testability is likely to degrade with a more highly coupled system of objects.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.

'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T20:18:20Z

Bsriship: /* Disadvantages of high coupling */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show. One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}

*Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack. Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* High cohesion makes it easier to replace a module by another one that provides same functionality.
* High cohesion reduces complexity of the system, and hence increase the application's reliability.
* If the module is highly cohesive, the software is more readable and maintainable.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling. It can be achieved in the following ways -
* Number of messages passed between objects can be reduced.
* Messages can be simplified using few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling. It can be achieved by -
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling. It can be achieved in the following ways -
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Object interaction complexity associated with coupling can lead to increased error generation during development.
* Decreases the scalability of the application software. Changing requirements in one part of software will potentially require wide ranging changes in the entire application.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.
* Testability is likely to degrade with a more highly coupled system of objects.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.
'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T20:09:49Z

Bsriship: /* Advantages of high cohesion */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show. One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}

*Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack. Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* High cohesion makes it easier to replace a module by another one that provides same functionality.
* High cohesion reduces complexity of the system, and hence increase the application's reliability.
* If the module is highly cohesive, the software is more readable and maintainable.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling. It can be achieved in the following ways -
* Number of messages passed between objects can be reduced.
* Messages can be simplified using few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling. It can be achieved by -
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling. It can be achieved in the following ways -
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Decreases the scalability of the application software. Changing requirements that affect the suitability of some component will potentially require wide ranging changes in order to accommodate a more suitable replacement component.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.
'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T20:03:42Z

Bsriship: /* Advantages of high cohesion */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show. One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}

*Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack. Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* High cohesion makes it easier to replace a module by another one that provides same functionality.
* High cohesion reduces complexity of the system, and hence increase the application's reliability.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling. It can be achieved in the following ways -
* Number of messages passed between objects can be reduced.
* Messages can be simplified using few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling. It can be achieved by -
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling. It can be achieved in the following ways -
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Decreases the scalability of the application software. Changing requirements that affect the suitability of some component will potentially require wide ranging changes in order to accommodate a more suitable replacement component.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.
'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T19:24:21Z

Bsriship: /* To achieve low coupling */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show. One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}

*Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack. Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow, and it also reduces the possibility that a method will semantically change, and therefore require an ''[http://en.wikipedia.org/wiki/API API]'' adjustment, which reduces the ripple effect and hence reduces maintenance costs.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* Single system failure won't bring down all connected systems.
* The higher the cohesion the less chance there will be for inconsistencies to develop or for the underlying process to break because the supporting systems are not sufficiently aligned.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling. It can be achieved in the following ways -
* Number of messages passed between objects can be reduced.
* Messages can be simplified using few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling. It can be achieved by -
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling. It can be achieved in the following ways -
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Decreases the scalability of the application software. Changing requirements that affect the suitability of some component will potentially require wide ranging changes in order to accommodate a more suitable replacement component.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.
'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T19:08:00Z

Bsriship: /* Measurement of cohesion */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show. One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}

*Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack. Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow, and it also reduces the possibility that a method will semantically change, and therefore require an ''[http://en.wikipedia.org/wiki/API API]'' adjustment, which reduces the ripple effect and hence reduces maintenance costs.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* Single system failure won't bring down all connected systems.
* The higher the cohesion the less chance there will be for inconsistencies to develop or for the underlying process to break because the supporting systems are not sufficiently aligned.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling.
* Reduce the number of messages passed between objects.
* Simplify messages to a few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling.
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling.
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Decreases the scalability of the application software. Changing requirements that affect the suitability of some component will potentially require wide ranging changes in order to accommodate a more suitable replacement component.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.
'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-30T19:06:23Z

Bsriship: /* Measurement of cohesion */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is attained by:
*Including all the relevant elements of the object together in one class instead of chaining through invisible objects (like automobileTag).For example, in the given class Person, the elements automobile tag and automobile year are not directly relevant to a person. So, we can create a new class 'Car' and include it as an element in class 'Person'.

class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
class Car {
String tag;
int year;
}

*Include all the necessary elements in the object, so that the elements presence would model the object accurately. For example, in class 'TriagePatient', it is not necessary to include the favorite TV show.

class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
class RecoveringPatient {
String favoriteTVshow;
}
One way of including the rarely used attributes (like favoriteTVshow) conditions is to create a subclass.

* Ensure that all the necessary elements are present in the class to achieve completeness. For example, in a class like 'Stack', there should be a mechanism to push and pop elements to complete the stack.
class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
}

Some relevant elements may get omitted due to complexity. Knowing what to leave out is part of abstraction.

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow, and it also reduces the possibility that a method will semantically change, and therefore require an ''[http://en.wikipedia.org/wiki/API API]'' adjustment, which reduces the ripple effect and hence reduces maintenance costs.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* Single system failure won't bring down all connected systems.
* The higher the cohesion the less chance there will be for inconsistencies to develop or for the underlying process to break because the supporting systems are not sufficiently aligned.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling.
* Reduce the number of messages passed between objects.
* Simplify messages to a few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling.
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling.
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Decreases the scalability of the application software. Changing requirements that affect the suitability of some component will potentially require wide ranging changes in order to accommodate a more suitable replacement component.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.
'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve '''high cohesion''' and '''low coupling'''.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]

CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

2008-06-26T02:58:45Z

Bsriship: /* Types of Coupling [http://www.cs.unchttp://www.mediawiki.org/.edu/~stotts/145/coupling.html] */

==Problem Definition==
Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

===Introduction===
'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]''' and '''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]''' are two cornerstones of ''[http://en.wikipedia.org/wiki/Object-Oriented Object-Oriented Programming]''. They sound similar, but have very different meanings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a ''[http://en.wikipedia.org/wiki/Class_(computer_science) class]'' has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

==Cohesion==
'''Cohesion''' is the "glue" that holds a ''[http://en.wikipedia.org/wiki/Module module]'' together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple Single Responsibility Principle]. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a [http://en.wikipedia.org/wiki/Netrunner NetRunner] game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.
An example of a high cohesive EmailMessage class is given below [http://megocode3.wordpress.com/2008/02/14/coupling-and-cohesion/].
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
}
The above class was originally designed to send an email message. Suppose if it is modified in the future in a way that the user needed to be logged in to send an email which is implemented by adding a Login method to the EmailMessage class.
class EmailMessage
{
private string sendTo;
private string subject;
private string message;
private string username;
public EmailMessage(string to, string subject, string message)
{
this.sendTo = to;
this.subject = subject;
this.message = message;
}
public void SendMessage()
{
// send message using sendTo, subject and message
}
public void Login(string username, string password)
{
this.username = username;
// code to login
}
}
The Login method and username class variable really have nothing to do with the EmailMessage class and its main purpose which makes it a low cohesive class.

===Types of Cohesion [http://www.cs.unc.edu/~stotts/145/cohesion.html]===
#'''Coincidental cohesion''' (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Logical cohesion'''- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). [http://www.cs.unc.edu/~stotts/145/logicalcohesion.gif Diagram][[Image:Cohesion.jpg|thumb|300px|Types of Cohesion]]
#'''Temporal cohesion'''- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [http://www.cs.unc.edu/~stotts/145/cohesion.html].
#'''Procedural cohesion'''-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.[http://www.cs.unc.edu/~stotts/145/proceduralcohesion.gif Diagram]
#'''Communicational cohesion'''- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.[http://www.cs.unc.edu/~stotts/145/communicationalcohesion.gif Diagram]
#'''Sequential cohesion'''- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations [http://www.cs.unc.edu/~stotts/145/sequentialcohesion.gif Diagram].
#'''Functional cohesion''' (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do.
Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069].

===Measurement of cohesion===
A high degree of cohesion is indicated by:
*All the elements are relevant to the concept. It is relevant if the element is directly chained to the object instead of being associated through some chain of invisible objects.
class Person { class Person {
String name; String name;
String automobileTag; Car automobile;
String automobileYear; ----> }
}
Not relevant: people don't have class Car {
automobile tags; automobiles String tag;
do!. int year;
}

Be on the lookout for compound nouns (like automobileTag), they can indicate invisible objects.
*All the elements are necessary to adequately model the concept. An element is necessary to an object if its presence is required for the accurate modeling of the object.
class TriagePatient { class TriagePatient {
Boolean inShock? Boolean inShock?
String bloodType; String bloodType;
String favoriteTVshow; -----> }
}
Not necessary: do we really class RecoveringPatient {
need to know their TV show? String favoriteTVshow;
}
Be on the lookout for attributes which are only used under certain rare conditions.Maybe your objects should "evolve" from class to class, or maybe the attributes belong in a subclass.
*No necessary elements are missing from the group; i.e.the group is complete.Completeness is achieved if no necessary elements have been omitted.
class Stack { class Stack {
int size; -----> int size;
Object elems[]; Object elems[];
push(elem) {...} push(elem) {...}
} pop() { }
Not complete: I see push()... }
but where's pop()?
Some relevant elements may get omitted as the real world is often too complex to model in entirety, knowing what to leave out is part of abstraction.

===Advantages of high cohesion===

* Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow, and it also reduces the possibility that a method will semantically change, and therefore require an ''[http://en.wikipedia.org/wiki/API API]'' adjustment, which reduces the ripple effect and hence reduces maintenance costs.
* Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks.
* Single system failure won't bring down all connected systems.
* The higher the cohesion the less chance there will be for inconsistencies to develop or for the underlying process to break because the supporting systems are not sufficiently aligned.

== Coupling ==
'''Coupling''' is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by ''[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter]''. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

An example of a two highly coupled objects an iPod object and a Song object is given below [http://benrobb.com/2007/01/20/coupling-vs-cohesion/]. Song class might look something like this in Ruby style.
class Song
def do(action)
if action == 1
# code to play song…
elsif action == 2
# code to pause
elsif action == 3
# code to skip
endif
end
end
In the above program, programmer who wants to interface the iPod object with the Song object is now dependent on the special meaning of 1, 2, & 3 to use the Song object correctly. The iPod object and the Song object are highly coupled. We can implement these objects in another way which makes these objects more cohesive is given below.
class Song
def new(path_to_song)
#code to get the song from the filesystem
end
def self.play
#code to play song
end
def self.pause
# code to pause song
end
end
#This would allow the iPod object to call
currentSong = Song.new(”/home/user/Music/1812_Overture.mp3″)
currentSong.play
currentSong.pause
With the above code, other objects that wish to interact with it can do so in a uniform way regardless of how the Song object is implemented on the backend. They just know that Song object does what it is supposed to do.

===Types of Coupling [http://www.cs.unc.edu/~stotts/145/coupling.html]===
#'''No Direct Coupling''' (low) - These are independent modules and so are not really components of a single system.
#'''Data Coupling''' - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase [http://www.cs.unc.edu/~stotts/145/datacoupled.gif Diagram].[[Image:Coupling.jpg|thumb|300px|Types of Coupling]].
#'''Stamp Coupling''' - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. [http://www.cs.unc.edu/~stotts/145/stampcoupled.gif Diagram]
#'''Control Coupling''' - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. [http://www.cs.unc.edu/~stotts/145/controlcoupled.gif Diagram].
#'''Common Coupling''' - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. [http://www.cs.unc.edu/~stotts/145/commoncoupled.gif Diagram]
#'''Content coupling''' (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept.

In object-oriented programming, ''[http://www.economicexpert.com/a/Subclass:coupling.html Subclass coupling]'' describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

===To achieve low coupling===
1. Strive for low message coupling.
* Reduce the number of messages passed between objects.
* Simplify messages to a few parameters.
* Avoid requiring multi-message sequences.

car.pushPedal(CLUTCH);
car.shiftToGear(PARK); ---> car.start(carKey);
car.insertKey(carKey);
car.pushPedal(GAS);
car.turnKeyInIgnition();

2. Strive for low ''[http://en.wikipedia.org/wiki/Association_(object-oriented_programming) association]'' coupling.
* Reduce extent to which objects depend on the internal structure of each other.
* Reduce the use of ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html superclasses]'' instance variables by ''[http://www.science.uva.nl/ict/ossdocs/java/tutorial/java/javaOO/subclasses.html subclasses]'' (strong form of the Law of Demeter).
class Person {
String first, last; class Doctor : Person {
getName { first + last } getName {
} ^ -----> "Dr" + Person::getName();
| }
| }
class Doctor : Person {
getName {
"Dr" + first + last;
}
}

3. Strive for moderate ''[http://en.wikipedia.org/wiki/Inheritance_(computer_science) inheritance]'' coupling.
* Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses.
* Use or refine as many of superclass' operations as possible in the child classes.
class Person {
hello {
print "Hi!" class Doctor : Person {
} greetings {
} ^ ----> hello();
| }
| }
class Doctor : Person {
greetings {
print "Hi!";
}
}

=== Disadvantages of high coupling===
* Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component.
* Decreases the scalability of the application software. Changing requirements that affect the suitability of some component will potentially require wide ranging changes in order to accommodate a more suitable replacement component.
* Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive.

== Cohesion and Coupling Examples ==

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of [http://www.hypernews.org/~liberte/computing/visual.html visual programming metaphors]. Observe [http://www.kellen.net/Coupling%20and%20Cohesion.htm Figures] 1 and 2.[[Image:LooseCoupledHighCohesion.jpg |thumb|250px|Figure1: Loosely Coupled & Highly Cohesive]] What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. [[Image:HighCoupledLooseCohesion.jpg |thumb|250px|Figure2: Highly Coupled & Loosely Cohesive]].

'''In General'''

Let us take a look at some simple real life examples to understand the relation between these two terms.

Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes.

Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling.

Example 3. Child and Parent relationship -
Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings.
'''In Object Oriented terms'''

[http://dotnetslackers.com/articles/csharp/PolymorphismEncapsulation.aspx Polymorphism and encapsulation] are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [http://vista.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TOBJ_PolymorphismAndLooseCoupling] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling.

In order to achieve modularity, we need to have low coupling and high cohesion.“[http://www-cse.ucsd.edu/users/wgg/CSE131B/Design/node1.html Modularity] is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [http://en.wikipedia.org/wiki/Grady_Booch Booch 1994]
Principle: Modularity = Low Coupling + High Cohesion
It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints.

==Conclusion==
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit
interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn
results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the
objective of a good software should be to achieve high cohesion and low coupling.

==See Also==
*'''[http://en.wikipedia.org/wiki/Cohesion_(computer_science) Cohesion]'''
*'''[http://en.wikipedia.org/wiki/Coupling_(computer_science) Coupling]'''

== External links ==
*[http://www.barneyb.com/barneyblog/index.php?s=cohesion Blog on Cohesion and coupling]
*[http://www.slideshare.net/phananhvu/oop-2/ Pdf on Cohesion and Coupling]
*[http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html Why coupling is always bad / Cohesion vs. coupling]
*[http://www.theregister.co.uk/2006/08/31/cohesion_coupling/ Up with cohesion, down with coupling]
*[http://www.ebizq.net/topics/eai/features/4688.html?&pp=1 Coupling Versus Cohesion: When to Leverage Services]
*[http://www.cs.colorado.edu/~kena/classes/5828/s99/comments/nathanryan/01-29-1999.html Cohesion and coupling example]
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm What makes a module a good module?]
*[http://www.amazon.com/gp/reader/007301933X/ref=sib_dp_pt#reader-link Software Engineering: A Practitioner's Approach ]

[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Summer_2008/wiki2_Assignment Back to the Assignment Page]