views:

150

answers:

6

Heyho,

There´s a question in my mind for some time now, which hopefully can be cleared quickly by some of you:

I am a big fan of MVC, ASP.Net Mvc in my case.

What I have noticed is the hype about interfaces. Every video, tutorial and book seems to solve any kind of abstraction with interfaces. I have adapted these patterns, understood why and how and I am basically very happy with it.

But I just don´t get why interfaces are used everywhere. I´ve almost never seen some abstraction being done with abstract base classes, which I don´t understand. Maybe I miss something? I know that you can only inherit from one base class while multiple interfaces are possible. But interfaces do have disadvantages, especially when some changes need to be done, which breaks your implementations. In my projects so far, I only used to pick interfaces for completely different classes.

For example, the whole repository pattern could be done with an abstract base class, still providing testability and exchangeability, or did I miss something?

Please point me to the part where my brain laggs :)

+6  A: 

Interfaces are used in tutorials, blogs and elsewhere because those authors are particularly influenced by a group of methodology called "design for testability".

Primarily, design for testability school of thoughts used interface every way because they want to be able to mock any component under tests. If you use concrete class, then a lot of mocking tools can't mock those class, and hence will make it difficult to test your code.

Ngu Soon Hui
+1 to offset unfounded downvote. Yes, you can still test when you're using abstract classes, but testability through mocking **is** a legitimate and common reason to program to interfaces.
Jay
To allow mocking with tools like Moq is a good reason.
Richard
Yeah correct, I actually even use Moq and did not think so far. Valid point
Steffen
A: 

Coding against interfaces makes your design more flexible and extensible. For instance, plugin frameworks and dependency injection. Without interfaces, the extensibility of it is pretty much limited.

Wim Hollebrandse
+1  A: 

If the language doesn't support multiple inheritance or mix-ins abstract base classes are limited in scope compared to interfaces. E.g. in .NET if you must inherit from some other type such as MarshalByRef, you can't use an abstract base class to implement a pattern. Interfaces do not impose this restriction.

Brian Rasmussen
+1  A: 

Besides the fact you mentioned that you can inherit from a single base class only (which is pretty inconvenient if you want to use an existing class that already inherits from some class with the new framework base class), you also avoid the fragile base class problem if you use interfaces instead.

Fabian Steeg
+3  A: 

A Story

I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

While using only or mostly Interfaces does have code reuse problems(as well as eliminating nice base classes), It makes it a lot easier to do Multiple Inheritance like things. As well as having widely different implementations that will work and where you don't have to worry about the base class changing or even what it does(you do have to implement the whole thing though so its a trade off).

P.S. I think the new Go language is based on interfaces rather then inheritance(looks sort of interesting).

Roman A. Taycher
You have to implement the whole thing, yes, but in cases where inheritance is warranted, of course, you can implement the interface in a base class and THEN inherit, so you get the benefit of being able to use the interface without having to reimplement all the members in every class that is logically related through inheritance.
Jay
Having said that, VB4-6 is a good example of what happens when this type of concept is implemented badly. COM did support interface inheritance, but lack of implementation inheritance (and therefore proper framework support) did verily lead to much boilerplate code in VB6 apps >-p
ConcernedOfTunbridgeWells
+1  A: 

Read about interfaces, abstract classes, breaking changes, and MVC here: http://ayende.com/Blog/archive/2008/02/21/Re-Versioning-Issues-With-Abstract-Base-Classes-and-Interfaces.aspx.

One solution that is presented there (or somewhere else on Ayende's blog) is: do use interface but also provide abstract classes. Those who case about breaking changes can base their implementations on abstract classes. Those who need power of interfaces are also satisfied. But do make sure your methods accept interfaces, not abstract classes, as input.

queen3