Keep it DRY, shy and tell the other guy

I read a nice article from IEEE Software by Andy Hunt and Dave Thomas that tries to describe Object Oriented Design in one sentence: "Keep it DRY, shy and tell the other guy".

DRY means: Don't Repeat Yourself. The idea is to keep a single authoritative and unambiguous representation of an information item in your system. This way, even if you end up having several copies of the same data, possibly in different representations, you should be able to generate them all from that single authoritative and unambiguous representation. Code reuse is a good example of this principle. The principle doesn't only apply to code, but also to documentation, build process, schemas, etc.

Shy means: de-coupling. The authors describe four types of coupling:

• static -- one thing requires another thing in order to compile. This is not a bad thing as long as you use what you need and avoid things you don't need. Don't carry excess baggage.
  
• dynamic -- when one piece of code requires another one at runtime in order to perform a task. This becomes a problem when you find yourself using a daisy-chain of calls to different pieces of code instead of direct communication between the parties involved.
  
• domain -- when your domain expertise becomes part of the code. This is not bad as long as the domain information doesn't change much, but becomes a serious problem when it does. Representing the domain information as meta-data and processing it using a rule engine will usually save the day.
  
• temporal -- when the coupling has time dependency. Think about avoiding time dependencies where they are not necessary.
  

Tell the other guy means: do your best to tell other code what to do instead of asking it for data and process it yourself. You shouldn't care about details and how things are done, your should just care about getting things done and leaving the details to the parties that need to do it.

I really recommend reading that short paper. It is offering quite good advice.