CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling: Difference between revisions
Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
Cohesion and Coupling are two terms often used in ''[http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented software development]''. They sound similar, but have very different meetings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a class has a focused set of responsibilities or behaviors from a particular perspective. | Cohesion and Coupling are two terms often used in ''[http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented software development]''. They sound similar, but have very different meetings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a 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== |
Revision as of 22:48, 23 June 2008
Introduction
Cohesion and Coupling are two terms often used in object-oriented software development. They sound similar, but have very different meetings. Cohesion is the “act or state of sticking together” or “the logical agreement". It is the basic idea that a 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 module together. It can be thought of as the type of association among the component elements of a module. 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 our Card object was responsible for drawing itself, sending messages back to the server, and executing game logic, it would have 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 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. An example of a high cohesive EmailMessage class is given below [1].
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 but if it is modified in the future in a way the user needed to be logged in to send an email so the Login method was added to the EmailMessage class.