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 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# Commented Sep 20, 2011 at 19:00
  • Code obfuscation and job security :)
    – Coder
    Commented Sep 20, 2011 at 19:07
  • 1
    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
    Commented Sep 20, 2011 at 19:13

3 Answers 3


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.

  • 1
    How do interfaces make unit testing easier? Commented Sep 20, 2011 at 19:05
  • @RobertHarvey - I mean when mocking dependencies.
    – Oded
    Commented Sep 20, 2011 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
    Commented Sep 20, 2011 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
    Commented Sep 20, 2011 at 19:15
  • 2
    @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
    Commented Sep 20, 2011 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.


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.

  • 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. Commented Sep 20, 2011 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
    Commented Sep 20, 2011 at 19:21

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