Put another way, favor "has-a" over "is-a" relationships.

What's so bad about inheritance?

• Subclasses are tightly coupled to their base classes. Many times subclasses make assumptions about the context in which a method it overrides is getting called, which means that small implementation changes in the base class can produce unexpected behavior.
  
• Dependencies of the subclass are hard-wired making unit testing difficult. One cannot mock a base class of a subclass.

It is definitely fine to inherit from interfaces; it's the concrete implementations that cause all of the problems.

An added benefit of composition relationships is that behavior can be changed at run-time (Strategy Pattern).

Labels: OO, Redpoint

The benefits of pair-programming include:

• Faster
  
• Fewer bugs
  
• Higher quality code (continuous peer review and brainstorming)
  
• Shared understanding of code-base
  
• Can learn from partner
  
• Better design
  
• Team building
  
• Higher confidence in code
  
• Higher satisfaction
  

Drawbacks:

• Scheduling problems (developer schedules are different)
  
• Personality conflicts
  

Most studies show that a pair is 40 to 80% faster than an individual, which means that two individuals are faster than a pair. However, the resultant code is higher quality in that it has a better design and fewer bugs. It has been extensively documented that the cost and time it takes to fix bugs found by testers or customers is many times larger than the cost of the originally written code, which effectively means that over the whole project life-cycle pair-programming is faster.

Scheduling problems can be solved, but personality conflicts can be a real problem. A good pair programmer leaves his/her ego at the door, is flexible, and most importantly communicates well. One mitigation strategy is to frequently rotate pairs.

Labels: Agile, Pair-Programming, Redpoint

One of the best ways to ensure testable code is practice Test Driven Development. How can code not be testable if it is already tested?

Another good idea is to write code that is easy to test in isolation, which is mostly done by mocking its dependencies. "Mockable" classes are achieved with:

• Injecting dependencies with an Inversion of Control framework such as Spring
  
• Avoiding singleton and static methods
  
• Favoring composition over inheritance
  

Labels: Agile, Mock, Redpoint, TDD