Sam,

Coupling is the unnecessary dependance of one component upon another
component's implementation. An example would be if you had a Dog class
that should be able to bark and jump. You could write it like this:

class Dog
{
 void doAction(int number)
 {
    if(number==1)
         //Jump code goes here
    if(number==2)
         //Bark code goes here
 }
}

However, this way whoever used your class would have to follow your
convention that doAction(1) means jump and doAction(2) means bark. A
less-coupled way would be to write separate bark() and jump() methods.

Cohesion occurs when components are wired together in a smart, logical
way. If you have ever used a Controller class, that's a great example
of acheiving cohesion. Highly cohesive components interact with each
other semantically, in other words, they tell each other what they want
to do. In a bank example, an ATM object should be able to tell an
Account object to getBalance(), or withdrawFunds(), etc. These are
sensible ways for the ATM and Account to interact, not specific ways
that are only useful in one program.

So good OOD requires that components can interact powerfully, but
independently of eachother's implementation details. (Think of
System.out.println() - most people have no idea how that works, but
when you want to output some text, you can just use the method.)

Encapsulation is the use of hiding implementation details within your
code. Changing the above Dog code from doAction() to jump() and bark()
would be a step toward good encapsulation. This is getting
frighteningly nerdy, but I think you could say "A program with high
cohesion and low coupling exhibits good encapsulation". In other words,
encapsulation is the goal you're trying to reach when you reduce
coupling. A class with good encapsulation, in turn, lends it self to
being a cohesive part of a system.

Finally, polymorphism is fairly unrelated to the above concepts. It
refers to the ability of an object to act like its parent object if
needed. So let's say the Dog class extends the Animal class. If an
Animal can eat(), then you call call myDog.eat(), even if Dog doesn't
have an implementation of eat() in it's definition, because Animal
does, and Dog inherits all of Animal's functionality. There are other
definitions of this term, but this is the most Java-ish one I can think
of.

Kevin