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
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 [3] 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.
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); } }
In this example, the Client
and CustomerInfo
classes share the common Customer
class. This is a desired form of coupling.
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); // ... } }
In this example, Client
and CustomerInfo
interact using only primitive types of data. This is a desired form of coupling.