CSC/ECE 517 Summer 2008/wiki2 6 cc

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.

---

Introduction

Cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. It is usually expressed as “high” or “low” cohesion when being discussed. High cohesion is desired because it is robust, reliable, reusable and more understandable whereas low cohesion has the opposite of those traits – difficult to maintain, test, reuse and understand. With high cohesion comes low coupling. Coupling is the degree of dependence of internal implementation between different modules – low coupling is where the module doesn't depend on what other module's internal implementation does thus a change in them won't affect the module whereas high coupling is where a change in one module might “break” other modules because they are highly dependent on eachother's internal implementations. This page will show you different types of cohesion and coupling and examples showing the “big picture” of them.

Cohesion

Cohesion is categorized in “high” and “low” but it is “measured” by how strongly-related or focused the responsibilities are for the class. In a highly-cohesive system, code readability and reusability is increased while complexity is kept manageable. A class of high cohesiveness could decrease its “cohesiveness” by carrying out more varied activities that have little in common and increasing complexity. Below we describe the different types of cohesion arranged from highest to lowest cohesion.

Functional Cohesion

Functional cohesion describes a module that is designed to perform one and only one task. A functionally cohesive module may contain multiple methods, but all of these methods are designed to help the user achieve a single task. The following example illustrates functional cohesion.

 public class Stack {
   public Stack() {
     // implementation
   }
   
   public void push(Object obj) {
     // implementation
   }
   
   public Object pop() {
     // implementation
   }
 
   public Object peek() {
     // implementation
   }
   
   public int isEmpty() {
     // implementation
   }
 }

Sequential Cohesion

Sequential cohesion describes modules whose operations are intended to be executed in sequence with the output of each operation providing input to the subsequently executed operation. The following example illustrates sequential cohesion.

  class Cube {
      public ArrayList getInfo(){ 
             ArrayList tempList = new ArrayList();
             tempList.add(getArea());
             tempList.add(getVolume());
             return tempList;
      }
      public double getArea(){return 6*side*side;} 
      public double getVolume(){return side*side*side;}
   }

Information cohesion

Information cohesion can do several things with the same data - a class with various methods using same data. The following example illustrates information cohesion.

    class Circle {
         double radius;	      
         public double getArea(){return 3.14*radius*radius;}
         public double getDiameter(){return 2 * radius;}
         public double getCircumference(){return 3.14*2*radius;}
    }

Communicational Cohesion

Communicational cohesion describes modules that perform multiple operations on the same input or output data. The following example illustrates communication cohesion.

 public class CustomerInformation {
   public CustomerInformation(int accountNum) {
     // implementation
   }
   
   public String getName() {
     // implementation
   }
   
   public float getBalance() {
     // implementation
   }
   
   // ...
 }

Procedural Cohesion

Procedural cohesion is similar to sequential cohesion in that the operations exposed are typically grouped because they are executed within a sequence. Unlike sequential cohesion however, the operations within a procedurally cohesive module can be somewhat unrelated and output from one operation is not necessarily used as input to a subsequently executed operation. The following example illustrates procedural cohesion.

 public class Student {
   public Student(int studentId) {
     // implementation
   }
   
   public void LoadStudent() {
     // implementation
   }
   
   public void UpdateGrades(int[] grades) {
     // implementation
   }
   
   public void UpdateAttendance(Date[] dates) {
     // implementation
   }
   
   public void SaveStudent() {
     // implementation
   }
 }

Temporal Cohesion

Temporal cohesion describes a module that has several operations grouped by the fact that the operations are executed within temporal proximity. The following example illustrates temporal cohesion.

 public class Startup {
   public void Initialize() {
      InitializeLogging();
      
      InitializeUI();
      
      InitializeDb();
   }
   
   public void InitializeLogging() {
     // implementation
   }
   
   public void InitializeUI() {
     // implementation
   }
   
   public void InitializeDb() {
     // implementation
   }
 }

Logical Cohesion

Logical cohesion describes a module that groups operations because categorically they are related but the operations themselves are quite different. Typically, these modules accept a control flag which indicates which operation to execute. The following example illustrates logical cohesion.

 public class DataStore {
   public void SaveData(int destination, byte[] data) {
     switch (destination) {
       default:
       case 0:
         SaveToDb(data)
         break;
       
       case 1:
         SaveToFile(data)
         break;
       
       case 2:
         SaveToWebService(data)
         break;
     }
   }
   
   protected void SaveToDb(byte[] data) {
     // implementation
   }
   
   protected void SaveToFile(byte[] data) {
     // implementation
   }
   
   protected void SaveToWebService(byte[] data) {
     // implementation
   }
 }

Coincidental Cohesion

Coincidental cohesion describes a module whose operations are unrelated to one another and the module itself can be used to achieve several different types of tasks. The following example illustrates coincidental cohesion [1].

 public static class Math {
   public static int Add(int a, int b) {
     // implementation
   }
   
   public static int Subtract(int a, int b) {
     // implementation
   }
   
   // ...
 }

Advantages and Disadvantages

Cohesion is the idea that the module does a single task - be it calculating data, checking file etc. The "single task mindedness" drastically reduces code breaking when other modules are changed. If the module uses data from multiple other modules - if even one module changes or breaks, this module might need to be changed thus more time wasted. With single task modules, individual modules can be changed with very little problem.

Coupling

Coupling is categorized low (loose or weak) or high (tight or strong). Low coupling is a relationship where one module interacts with another module through a stable interface and does not need to be concerned with other module's implementation. With low coupling, a change in one module will not require changes in the implementation of another module (since they are not dependent on each other). High coupling introduces problems like one module change into multiple module changes, difficulty of understanding the relationships and difficulty of testing and reusing individual modules because of high dependence. Low coupling facilitates high cohesion and vice versa. Low coupling may also reduce performance, and a highly-coupled system is sometimes desirable to achieve maximum efficiency. Below we describe the different types of coupling arranged from highest to lowest coupling.

Content coupling

Content coupling occurs when one or more modules access the internals of another module. The following example illustrates content coupling.

 public class Rectangle {
 
   public int Top = 0;
   public int Left = 0;
   public int Width = 0;
   public int Height = 0;
   
   public Rectangle(int top, int left, int width, int height) {
     this.Top = top;
     this.Left = left;
     this.Width = width;
     this.Height = Height;
   }
    
   public int getArea() {
     return this.Width * this.Height;
   }
 }

 public class FloorPlan {
   Rectangle rectangle = null;
 
   public FloorPlan(int width, int height) {
     rectangle = new Rectangle(0, 0, 50, 100);
   }
 
   public void modifyDimensions(int width, int height) {
     rectangle.Width = width;
     rectangle.Height = height;
   }
   
   public int getArea() {
     return rectangle.getArea();
   }
 }

In this example, FloorPlan is able to directly modify the Width and Height fields of the Rectangle object. This coupling creates a dependency from FloorPlan on the internals of the Rectangle object that inhibits maintenance of the Rectangle class. If someone wanted to go back and change the Width and Height fields of Rectangle class to use a different data type they would also have to update the FloorPlan class.

Common coupling

Common coupling occurs when two or more modules modify the same same global variable. The following example illustrates common coupling.

 #include <stdio.h>
 #include <string.h>
 
 #define NUM_FIELDS 3
 
 class EmployeeRecordParser {
   public:
     EmployeeRecordParser(char* strRow, int nFields) : m_nCount(nFields), m_aryFields(0) {
 
       m_aryFields = new char*[m_nCount];
 
       char* strField = strtok(strRow, ",");
   
       for (int ct = 0; ct < m_nCount && strField; ++ct) {
 
          m_aryFields[ct] = new char[strlen(strField) + 1];

          memcpy(m_aryFields[ct], strField, strlen(strField));
 
          m_aryFields[ct][strlen(strField)] = 0;
 
          strField = strtok(NULL, ",");
       }
      }
  	
     ~EmployeeRecordParser() {
        if (m_aryFields)			
          delete [] m_aryFields;
      }
 
      int GetCount() { return m_nCount; }
      char* operator[](int nIndex) { return GetField(nIndex); }
      char* GetField(int nIndex) { return nIndex < m_nCount ? m_aryFields[nIndex] : ""; }
  
    private:
      char**	m_aryFields;
      int	m_nCount;
 };

 void ParseRecords(char* strFile) {
   int nRecords = 0;
   char* strRow = strtok(strFile, "\n");
 
   while (strRow) {		
 
     EmployeeRecordParser record(strRow, NUM_FIELDS);
 
     printf("\nEmployee Record %d\n------------------------\n", ++nRecords);
 
     for (int i = 0; i < record.GetCount(); ++i)  {
       printf("Field %d: %s\n", i, record[i]);
     }
 
     strRow = strtok(NULL, "\n");
   }
 }
 
 int main() {
   char str[] = "Tom,Frank,919-777-2333\nMikel,Dundlin,919-234-5512\nRobert,Skoglund,919-232-2904";
 
   ParseRecords(str);
  
   return 0;
 }

In the C++ example above, both the ParseRecords method and the EmployeeRecordParser class make use of the globally accessible strtok function. Internally, strtok uses a static variable to track the position of the current string being tokenized, which is also used to determine when the whole string has been parsed. In this particular example, the coupling on this common function has a side-effect that causes a bug that prevents all the records from being correctly parsed.

Control coupling

Control coupling occurs when one module controls the execution flow of another module. The following example illustrates control coupling.

 enum InfoType { id, name, balance }
 
 public class CustomerInfo() {
   public Object getCustomerInfo(InfoType type) {
     Object returnVal = null;
     switch (infoType) {
       case InfoType.id:                    
         returnVal = getCustomerId();
         break;
 
       case InfoType.name:
         returnVal = getCustomerName();
         break;
 
       case InfoType.balance:
         returnVal = getCustomerBalance();
         break;
     }
     
     return returnVal;      
   }
 
   // ...
 }

 public class Client {
   private customerInfo = new CustomerInfo();
 
   public void execute() {
     int id = (int)customerInfo.getCustomerInfo(InfoType.id);
     // ...
   }
 }

Stamp coupling

Stamp coupling occurs when two or more modules access or modify the same data of a shared object. The following example illustrates stamp coupling.

 public class Customer {
   private int id = 0;
   private String name = "";
   private float balance = 0.0f;
 
   public int getId() { return id; }
 
   public void setId(int _id) { id = _id; }
 
   public String getName() { return name; }
 
   public void setName(String _name) { name = _name; }
 
   public float getBalance() { return balance; }
 
   public void setBalance(float _balance) { balance = _balance; }
 }

 public class CustomerInfo() {
   public void save(Customer customer) {
     int id = customer.getId();
     String name = gustomer.getName();
     // ...
   }
 }

 public class Client {
   private customerInfo = new CustomerInfo();
 
   public void execute() {
     Customer customer = new Customer();
 
     customer.setId(5);
     customer.setName("Example");
     customer.setBalance(100f);
     
     customerInfo.save(customer);
   }
 }

Data coupling

Data coupling occurs when one module passes primitive type or simple data structure to another module as an argument. The following example illustrates data coupling.

 public class CustomerInfo
 {
   public float getCustomerBalance(int customerId)
   {
     // implementation details
   }
 }
   
 public class Client
 {
   private customerInfo = new CustomerInfo();
   
   public void execute(int customerId)
   {
       float balance = customerInfo.getCustomerBalance(customerId);
 
       // ...    
   }
 }

Message coupling

This is the loosest type of coupling. Modules are not dependent on each other, instead they use a public interface to exchange parameter-less messages. The following example illustrates messag coupling.

      class superclass {
          public void processData(){ module1.processData(); }
      }

      public Module2 {
          public void doSomething() { superclass.processData(); }
      }

No coupling

Modules do not communicate at all with one another.

Advantages and disadvantages

Coupling allows interaction between different modules so more complicated tasks can be done. However, a strong coupling will decrease the flexibility of the modules and it will be harder to main and understand. If coupling is too tight, changing one module might have a "snowball effect" and will require changes of other modules that are dependent on it. Coupling must be used with caution and modules must use exactly what it needs and nothing more.

Related Concepts

Measuring Cohesion

The goal of well-designed systems is to have highly cohesive modules. Below are three metrics that can be used to determine the level of cohesion within a system.

Lack of Cohesion 1 (LCOM1)

 LCOM1 = (P > Q) ? (P – Q) : 0
 
 P = Total number of method pairs that do not use a common field of the class.
 Q = Total number of method pairs that access at least one common field of the class.

Lower LCOM1 values indicate higher cohesion and better overall design.

Lack of Cohesion 2 (LCOM2)

 LCOM2 = 1 – sum(mA)/(m*a)
 
 m = Total number of methods in the class.
 a = Total number of attributes in the class.
 mA = Total number of methods that access attribute a.
 sum(mA) = Sum of all mA for all attributes of the class.

Lower LCOM2 values indicate higher cohesion and better overall design. If the total number of methods or attributes is zero than the value of LCOM2 is undefined.

Lack of Cohesion 3 (LCOM3)

 LCOM3 = (m – sum(mA)/a) / (m – 1)
 
 m = Total number of methods in the class.
 a = Total number of attributes in the class.
 mA = Total number of methods that access attribute a.
 sum(mA) = Sum of all mA for all attributes of the class.

LCOM3 values greater than one indicates low cohesion and should be addressed. If the total number of methods is less than two or the number of attributes is zero than the value of LCOM3 is undefined.

Measuring Coupling

While it is impossible to avoid some level of coupling within systems, the goal is to reduce coupling as much as possible. Below are three metrics that can be used to determine the level of coupling within a system.

Coupling Between Objects (CBO)

 CBO = sum(t)
 
 t = Total number of types that are referenced by a particular class, not including any possible super-classes, primitive types or common framework classes.

Lower CBO values indicate lower coupling.

Data Abstraction Coupling (DAC)

 DAC = sum(a)
 
 a = Total number of types that are used for attribute declarations, not including primitive types, common framework classes, or types that are inherited from any possible super-classes.

Lower DC values indicate lower coupling.

Method Invocation Coupling (MIC)

 MIC = nMIC / (N – 1)
 
 N = Total number of classes defined within the project.
 nMIC = Total number of classes that receive a message from the target class.

Lower MIC values indicate lower coupling.

Demeter's Law

Demeter's Law is a design principle that when applied to object-oriented programming means that object A can reference object B but object A cannot use object B to reference object C. Complying with this principle prevents object A from knowing that object B uses object C thereby reducing coupling. If object A needs to access a function of object C then it is up to object B to expose an operation encapsulating the reference to object C. The following example [2] illustrates how this could be done.

 public float calculateTotal(Order order) {
    return order.getProducts().getTotalCost();
 }

In the example object the object which implements calculateTotal() is calling getTotalCost on a Products object which is exposed through order. An alternative to this approach would be for the order object to expose this functionality as suggested by the following example.

 public float calculateTotal(Order order) {
   return order.getTotalCost()
 }
 
 public class Order {
   // ...
 
   public float getTotalCost() {
     return products.getTotalCost();
   }
   
   // ...
 }

Conclusion

Coupling and Cohesion go hand in hand. On one hand cohesion wants modules to do exactly a single task thus reduces problems and making a module handle itself. Coupling is inevitably used by cohesion to complete tasks and thus could introduce problems. So good programming desires high cohesion and low coupling - modules that does one task without affecting other modules while at the sametime use as less data/objects from other modules as possible to have low coupling.

See also

• Wikipedia: Cohesion
• Wikipedia: Coupling
• Software Engineeriing Presentation: Coupling and Cohesion
• More Cohesion Metrics
• More Coupling Metrics
• Example: Measuring Coupling and Cohesion

References

1. http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-cohesion-16069
2. http://www.waysys.com/ws_content_bl_pgssd_ch06.html
3. http://www.site.uottawa.ca:4321/oose/index.html#cohesion
4. http://javaboutique.internet.com/tutorials/coupcoh/index-2.html
5. http://bmrc.berkeley.edu/courseware/cs169/spring01/lectures/objects/sld001.htm
6. http://blogs.ittoolbox.com/eai/implementation/archives/design-principles-coupling-data-and-otherwise-16061
7. http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
8. http://www.cs.sjsu.edu/faculty/pearce/modules/lectures/ood/metrics/Cohesion.htm
9. http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2004/designModularity.htm
10. http://www.eli.sdsu.edu/courses/spring99/cs535/notes/cohesion/cohesion.html#Heading8
11. http://www.site.uottawa.ca:4321/oose/index.html#sequentialcohesion