The code quality: Coupling and Cohesion

I want to raise the topic of code quality. I'm always passionate about the quality no matters where it comes to things, food, programming or just life.
Thinking about code in categories good and bad is not really constructive, we don't get a lot of benefits. Critisizing a code doesn't bring a lot of benefits, but It might bring a lot of problems. There is not good and bad code, there is working code. Yesterday I met a guy on facebook which mentioned how stupid could be people making 500 errors in 1000 lines of code.
Most of us, the developers, have families, pets, nice cars, friends, problems, deadlines, and we are not living in our code. We are different, with different level of education, background, experience. We are not writing ideal code, which sometimes could be ugly, stupid, unreliable, whatever. And what is ideal code?
- It's like ideal wife. Is quite, obedient, doesn't spend to much money, is faithful to you and don't get in affairs behind you.
Still think it's possible? ;)
-Rethink it again.


Thinking in business there is working code. Thinking in quality there is a code which is flexible for business needs and goes in one foot with business. What is quality code?
There is no simple definitions. But there are metrics, both numeric and non-numeric. Two of them, for object oriented code were developed by Sun Microsystems engineers: coupling and cohesion.


Coupling is the degree to which one class knows about another class. If the only knowledge that class A has about class B, is what class B has exposed through its interface, then class A and class B are said to be loosely coupled…that's a good thing. If, on the other hand, class A relies on parts of class B that are not part of class B's interface, then the coupling between the classes is tighter…not a good thing. In other words, if A knows more than it should about the way in which B was implemented, then A and B are tightly coupled.
Coupling means that one class gets at the implementation of another class.

Driver campbell = new Driver();  
Car ford = new Car("Ford", "red");  
. . .  

public class Driver  
{  
  Car myCar; 
 
  . . . .  

  public void goFaster(int speed)  
  {  
    myCar.speed += speed;  
  }  

  . . . .  

} 

The Car class has allowed access to its speed field and the Driver class changes its value directly. This means other classes gain access to the implementation of the Car class; any changes to that implementation will "break" the Driver class. This is "tight coupling" and tight coupling is A Bad Thing, because any changes to one class can mean that other classes would have to be altered too.

• To avoid tight couplingAll classes should have as small a public interface as possible.
• All non-constant fields should have private access.
• Any alterations to the values of fields should be via method calls.

The term cohesion is used to indicate the degree to which a class has a single, well-focused purpose. Keep in mind that cohesion is a subjective concept. The more focused a class is, the higher its cohesiveness—a good thing. The key benefit of high cohesion is that such classes are typically much easier to maintain (and less frequently changed) than classes with low cohesion. Another benefit of high cohesion is that classes with a well-focused purpose tend to be more reusable than other classes.

To get more about coupling and cohesion, read SCJP study guide chapter 5.1.
More over good definition and discussion around coupling and cohesion is on www.c2.com