CSC/ECE 517 Summer 2008/wiki2 6 a

Aim

This article aims at highlighting the new areas been explored in the fields of cohesion and coupling and how using agile methodologies help attain highly cohesive classes and to maintain loose coupling between those classes. Following these approaches we can get code which is more readable and maintainable. We encourage reader to visit the references provided at the end of the article to explore more on the research work done in this field.

Introduction

Cohesion and Coupling are concepts often discussed when referring to object-oriented programming. In fact, one of the primary goals of object-oriented programming is “to build highly cohesive classes and to maintain loose coupling between those classes” [1]. In the first section of this article, we provide the basic definition of cohesion, different types of cohesion, how it is measured, advantages and disadvantages of high cohesion and some examples showing implementation of this concept in real life scenarios. Next, we explain the concept of coupling, different types of cohesion, how it is measured, advantages and disadvantages of high coupling and some examples showing implementation of this concept in real life scenarios. In the third section of this article, we highlight we include a section on how using agile approaches maintain cohesion and coupling, and why this is important, it also discusses the importance of quality metrics, and how agile teams help support the same. In next section we discuss the vast research going on in this field and hence we have included a section on new work been done in this field. Lastly, we provide a conclusion to the topics discussed herein along with some recommended further reading and references.

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. 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. It is important to understand that low coupling does not mean no coupling, rather the goal is to minimize the coupling not eliminate it. 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 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".

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();
   }
   
   // ...
 }

Types of Coupling [3]

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

Types of Coupling

.

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

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);
   }
 }

In this example, the Client and CustomerInfo classes share the common Customer class. This is a desired form of coupling. ===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. Diagram. Control coupling occurs when one module controls the execution flow of another module. The following example [4] 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);
     // ...
   }
 }

In this example, the Client class controls the flow of execution within the CustomerInfo module. This form of coupling requires modules calling CustomerInfo to know about the flow of execution within its class. ===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. 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.