Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
Why are interfaces useful?

In our company we have a service oriented architecture in our 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?

share|improve this question

marked as duplicate by Robert Harvey, Mark Trapp Sep 20 '11 at 19:14

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

I asked the same question a few days back and got great answers from the community which you might want to look at :: Usefulness of Interfaces in C# – Pankaj Upadhyay Sep 20 '11 at 19:00
Code obfuscation and job security :) – Coder Sep 20 '11 at 19:07
An important point is not to confuse a design pattern with language especific terms. Interfaces are not C# or .net especific. They play a very important role in OOP. Its correct implementation is something every OOPer should definitely learn. – AJC Sep 20 '11 at 19:13

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.

share|improve this answer
How do interfaces make unit testing easier? – Robert Harvey Sep 20 '11 at 19:05
@RobertHarvey - I mean when mocking dependencies. – Oded Sep 20 '11 at 19:06
@Oded right... it seems the todays programmer is over-applying practices without knowing WHY. The mass of the programmers I have the feeling is just using interfaces else the colleague will point with the finger on him and say he is a lousy programmer or sth. like that. It doesnt make sense at all for entites to make an interface. The Customer`s FirstName is the customers first name and will never change to whatever it could change. And even if we would switch from sql/oracle what we use to MySql the interfaces would not help. – msfanboy Sep 20 '11 at 19:14
It rather helps to use the DbCommand instead of the concrete dataprovider commands. I think WE all need to understand more about the proper use of an interface and we must be bold enough to say NO to over-engineering architectures. – msfanboy Sep 20 '11 at 19:15
@msfanboy - Without an example... When you have an interface, you can easily implement a mock (something that complies to the contract, but doesn't do anything). – Oded Sep 20 '11 at 19:18

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.

share|improve this answer

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.

share|improve this answer
Your argument doesn't seem compelling... If the purpose of interfaces is to solidify your API for unit testing purposes, I submit that your code needs to be written so that it's testable without the interface; the interface is just putting wallpaper over an underlying problem. Interfaces are not a required design item for creating SOLID, maintainable, testable code. – Robert Harvey Sep 20 '11 at 19:17
My point is that if your dependencies are on interfaces, rather than on concrete classes, then testing is easier. This is a common reason I use interfaces in LOB apps, which is what it sounds like the OP is asking for. Certainly not precisely what interfaces were created for, which is more general and can be found elsewhere. – Brook Sep 20 '11 at 19:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.