Was talking with my dad about Hermann's blog post today, where I propose the following metaphor: Interfaces are exactly like wall sockets. Would you say that having the same wall sockets has stifled innovation? Would you say its a good thing that we have different plugs in different regions of the world?
Havenít we still seen people work on different ways to get power into wall sockets and different types of machines using the power coming out?
Also look at stuff like these twist sockets for additional security, they are compatible with the original connectors, but expand on the original idea for specific scenarios.
Now is this stopping innovation? People are still developing inductive charging for example. Atm most are build on top of a standard wall connector, but I am sure there are also some that use solar power etc.
This is what I am talking about. I do not want to prevent people from working on inductive electric powering. I just want to make it so that you can take your code from one region of the world to another without having to carry a bag of adaptors around.
Note: This is a repost of a comment I put on the blog post by Hermann.
I wish this post had a "Like" button.
It's a good metaphor, but keep in mind power plugs define a *very* simple interface. If I had to describe a power socket in code, I suppose I would have written a single method interface that looked something like this:
public function providePower(AcPowerConsumer $appliance);
Of course, I would also define an AcPowerConsumer interface, but I suppose this one would be quite simple too.
When it comes to more complex interfaces, it becomes harder to find a good metaphor for something which is widely accepted and does not hinder progress. Think of cars for example: changing the way cars are operated and interact with roads and fuel stations would be extremely hard today, even if there was a very compelling reason to do so - I'm not saying there is such a reason, but hypothetically if there was, today's strict interfaces between drivers, cars and roads would make virtually any change not worth the cost of breaking compatibility.
So, in my opinion interfacing things like loggers and caching systems is fine. After all we are probably talking about no more than 4 common methods that such an interface could define, with maybe a few more simple interfaces that interact with the main interface (such as filters for loggers).
Interfacing something like an HTTP client is also a good idea in my opinion, because HTTP clients follow a very strict protocol as is. I cannot see how interfacing them would hinder creative development, especially if you stick to the basic high level operations performed by HTTP clients - send requests, access response content and meta data, etc.
When it comes to more complex things like say, components of Web application MVC frameworks, I do not think interfaces are a good idea - but I assume this is not what you're proposing either.
Agreed not everything will be feasible to get agreement on across framework communities. However if you look at what is happening with Silex and Symfony2, aka two frameworks coming out of the same community, its exciting to see how many interfaces can be shared despite solving two different use cases with two different approaches.