2

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?

Community
  • 1
msfanboy
  • 191
  • 2
  • 5
  • 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#](http://programmers.stackexchange.com/questions/108240/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
  • 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 Sep 20 '11 at 19:13

3 Answers3

1

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.

Oded
  • 53,326
  • 19
  • 166
  • 181
  • 1
    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 today`s 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 doesn`t 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 - Well. A simple DTO, an object that has only properties and no behavior will **not** need an interface. Insisting on one means that someone doesn't think. – Oded Sep 20 '11 at 19:16
  • @Oded Can you show please a simple example why mocking dependencies is easier with an interface ? – msfanboy Sep 20 '11 at 19:17
  • @Oded Hey cool you took exact the DTO example I suggested to my colleagues hehe. I said no interfaces for the DTO please that waste of time. – msfanboy Sep 20 '11 at 19:17
  • 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 Sep 20 '11 at 19:18
  • thx Oded 15 to go... – msfanboy Sep 20 '11 at 20:25
1

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.

1

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.

Brook
  • 1,835
  • 13
  • 17
  • 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