title: Concrete classes vs interfaces: When to use?
body: <p>I am pretty aware of the benefits of interfaces and how it helps aggregate common functionality of similar types of objects. However I believe people have taken this 'always program to an interface' a bit too far.</p>
  
  <p>a) People starting off by ALWAYS defining an interface and then implementing it in a class even if that interface is too specific to be implemented by any other class. - Am I the only one who thinks that this serves no useful purpose?</p>
  
  <p>b) Forcing all 'related' interfaces to derive for a common (useless) interface because it is now 'extendable' - What?</p>
  
  <p>c) What do you do in scenarios where two or more objects seem related but it is very difficult to define common interface methods because of its underlying differences?</p>
  
  <p>Lets say for example, an interface named <code>IConnection</code> with a <code>Connect()</code> method. (this is how most examples trivialize interfaces). The problem is, different type of classes that implement the IConnection interface might require different data for establishing the connection, some might require a user name and password, some might require some kind of special connection key, some might require nothing at all. The <code>Connect</code> method as a contract is perfectly valid as each class will need some way of establishing a connection but the data they need is different.</p>
  
  <p>Is an interface required in this case? If it is, how do you define the <code>Connect</code> method? If not, how do you prove that your concrete classes are still 'extendable'?</p>
  
  <p>Sorry for the long rant, this has been bugging me for quite some time now. Most people after reading the famous design patterns book try to implement every possible pattern in everything they do without bothering to figure out whether it helps. I believe the pattern should be brought into play when you are faced with a problem not just for the heck of it.</p>