Cohesion and Coupling and their types

Stumbled upon an article: http://www.infoworld.com/article/2949579/application-architecture/design-for-change-coupling-and-cohesion-in-object-oriented-systems.html

Following are the details from the article which are most important:

 

Coupling

Coupling may be defined as the degree of interdependence that exists between software modules and how closely they are connected to each other. In essence, coupling indicates the strength of interconnectedness between software modules. When this coupling is high, we may assume that the software modules are interdependent, i.e., they cannot function without the other. There are several dimensions of coupling:

• Content coupling -- this is a type of coupling in which a particular module can access or modify the content of any other module. In essence, when a component passes parameters to control the activity of some other component, there is a control coupling amongst the two components.
• Common coupling -- this is a type of coupling in which you have multiple modules having access to a shared global data
• Stamp coupling -- this is a type of coupling in which data structure is used to pass information from one component in the system to another
• Control coupling -- this is a type of coupling in which one module can change the flow of execution of another module
• Data coupling -- in this type of coupling, two modules interact by exchanging or passing data as a parameter

Cohesion

Cohesion denotes the level of intra-dependency amongst the elements of a software module. In other words, Cohesion is a measure of the degree to which the responsibilities of a single module or a component form a meaningful unit. Cohesion is of the following types:

• Co-incidental cohesion -- this is an unplanned random cohesion that might be a result of breaking a module into smaller modules.
• Logical cohesion -- this is a type of cohesion in which multiple logically related functions or data elements are placed in the same component
• Temporal cohesion -- this is a type of cohesion in which elements of a module are grouped in a manner in which they are processed at the same point of time. An example could be a component that is used to initialize a set of objects.
• Procedural cohesion -- this is a type of cohesion in which the functions in a component are grouped in a way to enable them to be executed sequentially and make them procedurally cohesive
• Communicational cohesion -- in this type of cohesion the elements of a module are logically grouped together in a way that they execute sequentially and they work on the same data
• Sequential cohesion -- in this type of cohesion the elements of a module are grouped in such a manner that the output of one of them becomes the input of the next -- they all execute sequentially. In essence, if the output of one part of a component is the input of another, we say that the component has sequential cohesion.
• Functional cohesion -- this is the best and the most preferred type of cohesion in which the degree of cohesion is the highest. In this type of cohesion, the elements of a module are functionally grouped into a logical unit and they work together as a logical unit -- this also promotes flexibility and reusability.

The best practices

Tight coupling increases the maintenance cost as it is difficult and changes to one component would affect all other components that are connected to it. So, code refactoring becomes difficult as you would need to refactor all other components in the connected-chain so that the functionality doesn't break. This process is cumbersome and takes a lot of tedious effort and time.

You should design classes that contain the less number of instance variables, i.e., your class design is "good" if it contains a small number of instance variables. Ideally, each of the methods in your class should manipulate one or more of these instance variables. Theoretically, a class is maximally cohesive if each of the instance variables of the class is used or manipulated by each of the methods of that class. When cohesion in class is high the methods and the data members of the class are co-dependent and work together as a single logical unit. However, in reality it isn't possible to design such classes or I would rather say, it is not advisable to design classes that are maximally cohesive.

Puzzle Time

Its amazing that in day to day life in office and discussion with colleges churn out some really interesting knowledge bits and these bits sometimes vibrate quite a bit of threads in your head. Here are some of those bits.
  
** River crossing: she-goat, wolf and cabbage 

Description:

A farmer is returning from market, where he bought a she-goat, a wolf and cabbage. On the way home he must cross a river. His boat is little, allowing him to take only one of the three things. He can’t keep the she-goat and the cabbage together (because the she-goat would eat it), nor the she-goat with the wolf (because the she-goat would be eaten). How shall the farmer get everything on the other side (without any harm)?

Solution:

farmer crosses with goat
farmer returns alone
farmer crosses with cabbage or wolf
farmer returns with goat
farmer crosses with whichever (cabbage or wolf) he didn’t take the first time
farmer returns alone
farmer crosses with goat
they are all on the other side

** Four glasses puzzle/ blind bartender's problem (
http://en.wikipedia.org/wiki/Four_glasses_puzzle)

Description: 

Four glasses or tumblers are placed on the corners of a square rotatable table. Some of the glasses are upright (up) and some upside-down (down). A blindfolded person is seated next to the rotatable table and is required to re-arrange the glasses so that they are all up or all down, either arrangement being acceptable, which will be signalled by the ringing of a bell.

The glasses may be re-arranged in turns subject to the following rules:
1. Any two glasses may be inspected in one turn and after feeling their orientation the person may reverse the orientation of either, neither or both glasses.
2. After each turn the table is rotated through a random angle.

The puzzle is to devise an algorithm which allows the blindfolded person to ensure that all glasses have the same orientation (either up or down) in a finite number of turns. The algorithm must be non-stochastic i.e. it must not depend on luck.  

Solution:

An algorithm that guarantees the bell will ring in at most five turns is as follows:

1. On the first turn choose a diagonally opposite pair of glasses and turn both glasses up.
2. On the second turn choose two adjacent glasses. At least one will be up as a result of the previous step. If the other is down, turn it up as well. If the bell does not ring, then there are now three glasses up and one down.
3. On the third turn choose a diagonally opposite pair of glasses. If one is down, turn it up and the bell will ring. If both are up, turn one down. There are now two glasses down, and they must be adjacent.
4. On the fourth turn choose two adjacent glasses and reverse both. If both were in the same orientation then the bell will ring. Otherwise there are now two glasses down and they must be diagonally opposite.
5. On the fifth turn choose a diagonally opposite pair of glasses and reverse both. The bell will ring.

Enabling x86 Android Emulation

We all have experienced slow emulator on Mac, Linux and Windows (especially windows) because of which we use virtualization images of Android i.e. Genymotion, etc. So, if you are running your OS on Intel processor then you can use Intel HAXM (Hardware Acclerated Execution Manager) to speedup your emulator.

Following are the links which discuss as to how to implement HAXM:

For Windows and Linux: http://software.intel.com/en-us/articles/speeding-up-the-android-emulator-on-intel-architecture

For Mac: http://simonguest.com/2013/04/16/enabling-x86-android-emulation/