Possible Duplicate:
Why are interfaces useful?
In our company we have a service oriented architecture in our asp.net application. We use interfaces for every crap class. Its a huge overhead. The service classes, dataprovider classes etc... they all use interfaces but practically we could also go without those interfaces and just use the class type.
So why should we do it that complicated and lose lots of productivity?
I believe that having an interface for every class is cargo cult programming.
You need interfaces/abstract classes when you are going to change/swap implementations. They are also the easy answer for mocking dependencies in unit testing.
What you are describing is an anti-pattern. An anti-pattern is a pattern that is usually over applied to every situation even when it is in appropriate.
Someone probably read an article that espoused this anti-pattern for some niche area, and didn't comprehend the narrow application and applies it everywhere. This happens a lot with "senior" developers that are just "tenured" and not actually senior in knowledge, or managers that are just technical enough to be dangerous. Possibly someone from a C++ background that missing the tedious declaration/definition paradigm.
See also "hammer pattern", when all you know is a hammer, everything looks like nail.
This is based on my 20 years of experience seeing this exact same thing dozens of times.
First, interfaces are usually easier dependencies to fill/mock when doing unit testing, because there default behavior is... nothing, so you can be sure you're testing classes in isolation.
Second, when you do need to create a custom mock, you don't need to do anything fancy, you just write a class that inherits the interface. This makes supplying dependencies to your classes easier when testing, and sometimes the mock implementation is the 2nd implementation you're looking for.
Third, if you're just writing a class, right click=>extract interface every time, you're not interpreting the "I" in "SOLID" correctly. Interface segregation implies that interfaces are designed for the CLIENT of the interface, not to match the implementation. There is an important difference in that the former will typically yield more loosely coupled design. It is a very fine line sometimes, but worth keeping an eye on.
Of course, if you're not interested in unit testing, and not interested in SOLID, maintainable, testable code, then yeah... interfaces might not have much practical value to you unless you have multiple implementations at run time.
