Concrete classes vs interfaces: When to use?

Question

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.

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?

b) Forcing all 'related' interfaces to derive for a common (useless) interface because it is now 'extendable' - What?

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?

Lets say for example, an interface named IConnection with a Connect() 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 Connect 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.

Is an interface required in this case? If it is, how do you define the Connect method? If not, how do you prove that your concrete classes are still 'extendable'?

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.

Answer 1

In your IConnection example you're basically describing an abstract Connect() method, since each class will have to implement its own version. Usually (always?) abstract methods can only be defined with the same parameters, so Connect(username, password) and Connect(key) couldn't be implementations of the same Connect() method from an interface.

Now, at this point, you could define it as IConnection::Connect(SomeConnectionData) and derive UsernamePasswordConnectionData and KeyConnectionData, etc., etc. from that SomeConnectionData class but all this would be so hard to explain and implement that its pretty good clue that interfaces and inheritance aren't helping the situation.

If it makes programming it and using it harder, don't do it. If something is made "extendable" by becoming too complex to understand, no will extend it anyway. It's perfectly okay to define a bunch of classes, each with their own Connect() methods just as a convention.