Friday, April 29, 2011

Coupling and Cohension

In computer programming coupling is the degree that each program module has to rely on the other modules. Coupling is usually the opposite of cohension. Low level coupling is more often than not correlating with high level cohension and vice versa. A well structured computer program is often directly related to low coupling. Good design is also often the result of low level coupling, and when it is combined with high level cohension it supports higher levels of readability and maintainability. There are lots of different types of couplings. Content coupling, or high coupling, is when one module modifies or relies on another module. High coupling can also be referred to as tight, or strong. Another type of coupling would be common coupling, and that is when two modules have the same global variable. Changing the variable would result in changing all of the modules that use it. Message coupling, or low coupling, is often achieved when component communication is done by parameters or message passing. Low level coupling can also be referred to as loose or weak coupling. Using coupling and cohension also has its disadvantages. Any kind of change made in one module usually results in a ripple effect in the other modules. It can take a lot longer to assemble modules and much more effort because of the increased inter-module dependency. And the biggest, and most obvious disadvantage of using coupling is that it is harder to reuse and test modules because other dependent modules have to be included.
Comparing coupling and cohension to life is as easy as comparing it to a recipe for making a cake. A cake breaks down into many different ingredients, but the overall outcome is the same. The outcome of the cake depends on all those ingredients being put in, in the right amounts, or the cake will not come out right. Just like in coupling the other ingredients will all have to be changed completely, or rendered useless if one of the other ingredients isn’t added the way it is suppose to be. Another good example would be a game of Jenga. Blocks are stacked on top of each other three across, once you get to a certain point in the stack you have to start moving the blocks around to keep building the stack higher. Some blocks can be moved around or “edited”, but if you try and move one of the supporting blocks the whole thing will come crashing down. If you think of the blocks as modules and the overall stack of blocks is the program, then it is easy to see how the two fit together. Each time you play Jenga you might get either really high up with the stack, or it might be too unstable and not worth trying to continue with. That is what I would use to compare low level and high level coupling with. A good way to apply coupling and cohension to life could also be as simple as your job. Keeping your job depends on a number of different factors. Factors like showing up on time, work performance, attitude, team work, etc. And keeping your job depends on all those factors combined, you cannot edit one without the others also being affected.