CSC 509 Lecture Notes Week 7
Guidelines for Module Coupling and Cohesion

1. Coupling and cohesion between modules (i.e., classes).
   1. "Coupling" and "cohesion" are terms used to denote module interconnectedness.
   2. Coupling refers to how much inter-module connection exists in a design; specific measures of coupling are:
      1. the number of classes that a given class inherits from;
      2. the number of classes that a given class references as data members;
      3. the number of methods that a given method calls;
      4. the number of parameters that a given method has.
   3. Cohesion refers to how much intra-module cohesiveness a design has; measures of cohesion are:
      1. the degree to which all methods in a class perform a logically-related aspect of system functionality
      2. the degree to which a method performs a single specific function
   4. In general, coupling should be minimized and cohesion should be maximized.

2. Techniques to reduce coupling
   1. Limit the number of classes that communicate with (i.e, call functions of) other classes.
      1. E.g. in an MVP design, a Process-class method invoked by a View class method may forward a Model-class exception rather than catching the exception and calling a View-class method.
      2. E.g.,
         1. n the Rolodex system, the Process-class method RolodexCommandProcessor.processCommand is called from a View-class method in RolodexCommandEditor.
         2. The processCommand method throws an InputErrors exception back to the view, rather than catching the exception and calling a View class.
         3. This limits coupling by not having a View class reference in the RolodexCommandProcessor process class.
   2. Limit the number of calls between classes that do need to communicate with each other.
      1. E.g., in the Rolodex system, the dialog button functions, such as OKAddButton, can communicate directly with the model, without having to go through a parent view class.
      2. E.g., OKAddButton.actionPerformed can call Rolodex.add directly
      3. More highly-coupled alternative would be some chain-of-command call such as AddCardDialog.getRolodex().add.
   3. Limit the number of public functions in each class.
      1. In general, make a function public only if there is a demand for it from some other class.
      2. Do not add public get functions "in case" they may be needed; the same goes for public set functions.
      3. E.g., since AddCardDialog.getRolodex is never used, it should not be provided.
   4. Limit the types of function parameters and return values to the smallest type necessary.
      1. Consider the Rolodex.find operation.
      2. It returns zero or more cards, which could be returned as Rolodex object, or a simpler CardList object.
      3. The CardList object is preferable, since callers of Rolodex.find do not need all of the information in a full Rolodex, but only a simple list.
   5. Design to limit the amount of change needed if data representations change.
      1. When using external process classes (e.g., C++ from Java), design wrapper classes that define a generic process class that hides details of external class.
      2. With a properly designed wrapper class, little or no changes to a Model class are necessary when changing underlying data representations in Process classes.
   6. Use exception handling wisely.
      1. Consider again the use of exception handling to communicate between models and views.
      2. The InputErrors exception classes provide a generic, string-based representation that can be used uniformly for error communication.

3. Techniques to increase cohesion
   1. Generally, coupling measures are easier to pinpoint exactly.
   2. Limiting the coupling between classes in turn increases cohesiveness, since decoupling eliminates unnecessary items from classes.
   3. To address cohesion directly means to design each class to represent a single, clearly identifiable piece of data and/or encapsulate a single clearly identifiable area of functionality.
   4. To a large extent, the MVP design technique promotes cohesion, since it has well-defined functionality for each category of design class.
   5. Limiting the size of each individual scoping unit (class or function), per our design and implementation conventions, is also a way to foster cohesion.
   6. I.e., it's harder to do too much in a class or function if you can't do that much there in the first place.

4. Ease of debugging -- a major rationale for limiting coupling.
   1. Consider the debugging question: "If something goes wrong in module X, where do I look for the problem?"
   2. First, look in module X for the problem.
   3. If it's caused immediately there, then look at all other modules that connect to X.
   4. Repeat this process until the source of the problem is located.
   5. Clearly, this problem isolation process will be made more orderly, and potentially shorter if the number of directly connected modules is limited.