CSC/ECE 517 Summer 2008/wiki2 c6 CohCoupling

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.

Problem Definition

Cohesion and coupling. 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.

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. 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.