Why are interfaces used so prolifically in .NET apps?

Recently I began working on a largish mainstream project to deliver a public-facing e-commerce platform for a client I cannot reveal.

I'm working with seasoned developers with many years experience across many projects in the City of London.

It seems everyone is into interfaces in a big way. I开发者_运维百科t's overwhelming and I now doubt everything I've done before, which is to use abstract base classes.

.NET is not COM, it's not an interface-based programming platform. Am I missing something or is this just herd mentality - the years of IProgramming have proliferated as accepted norms in .NET land?

Thanks

Luke

Interfaces promote loose coupling, and are easy to mock. They make the separation between API and implementation very clear.

Of course, you can use abstract base classes when there'll be common functionality between different implementations (and there can still be an interface on top of the abstract class if you want) but if everything in the abstract class is abstract, and there are no fields, why use up your one shot at inheritance by way of an abstract class? Where's the benefit?

Abstract Classes and Interfaces have two different uses.
The first ones are used to provide Father/Child inheritance.
The second ones are used to specify a specific behavior to implementing classes.
I Agree Interfaces are too frequently used for the wrong reasons IMHO.

EDIT :
Besides, the extensive use of interfaces may result in boxing/unboxing issues :
This may occur when a value-type implementing an interface is passed to a method having the interface-type as its parameter. I personnally had to face that issue and refactored the code to get rid of interfaces(though it was convenient for API concerns) to gain performance, as the class at issue was used and passed millions of times during runtime.

It all depends on what you want to achieve. The main difference between interfaces and abstract classes being that a class can inherit multiple interfaces but only a single abstract class. So both have their own purpose.

Abstract and Interface have their different uses.

A class that is derived "is" something. A class implementing an interface "can do" something.

Classes derive from a base class because they want to specifically inherit the parent's implemented features and behaviour. This can further be chained, because there can be a need for a group in the family to retain a common set of reusable behaviour, while another group branches off to implement a different set of common behaviour.

e.g. the System.Web.UI.Control family of classes - all have common functionality for ASP.NET server controls, but implementations further down the family differ greatly. But they still render HTML to the web page at the end of the day.

Interfaces on the other hand simply define what you expect a implementing class to do, not exactly to resemble. There is no hard definition as to how to achieve those capabilities. In fact the implementations may well be done to achieve wildly different things for the main system, but structured in a templated manner (the Interface) to allow the system to manage them all in a standard way.

e.g. IHttpModule, Providers, System.Runtime.Remoting.Channels, etc.

Interfaces specify a capability of a type, not an inheritance relationship. "Good" examples of interfaces are those that encapsulate quite general concepts that possibly apply to a wide range of very different concrete types that may have nothing else in common (think of IComparable or IEnumerable).

It is not always easy to decide what is "the right way" to go, using a class hierarchy or an interface-based approach. I consider interfaces to be one possiblity to raise the level of abstraction: Instead of specifing a method that requires its argument to be part of a certain class hierarchy, you just state what abilities the passed object should exhibit (e.g. sortability). This often allows you to formulate algorithms in a more generic way.

Using interfaces is very much an OO paradigm. Interfaces can abstract implementation to allow for more comprehensive testing, scalability and more easily build component-based (which makes apps more extensible) applications.

Of course the use of interfaces will vary depending on requirements (eg non-functional: must be able to build unit tests for each layer of an n-tier application).

Multiple devs can work on the same app and not care about how the other devs will implement their components, but know what to send and what to expect back again.

One advantage of base classes over interfaces is you can share functionality in all objects in a particular layer (say for a tiered architecture). Eg. validating common fields or converting a commonly used data type.

Programming to interfaces is core OO principle. It enables you to build in Dependency inversion/inversion of control - ie implementations don't directly depend on other implementations - instead, they depend on other Types . What this does is make it easy to plug in/plug out parts of your system. It also enhances testability of the system, since its easy to provide mocks conforming to an interface if all your implementation cares about is the interface. Also, having a system described in terms of a few interfaces also makes it easier to understand the overall policies of the system. Trying to divine this from a bunch of base classes that have implementation details just makes it a little more harder.

Abstract base classes are really nothing more than a way to share implementation that is common between multiple subclasses. But beware of avoiding the interface and directly binding to an abstract base class - what you're doing by that is setting in stone that you not only bind to the interface of the abstract base, but will also always carry around the implementation. There are many times when what seems like a given today is turned around 180 degrees in a few months/years and this the kind of 'permanent' decision that you shouldn't take lightly. The cost of always having an interface is much less, in my opinion.

So in effect, have an interface to document a Type, and if among the implementors of the type you see a lot of potential code reuse, create an abstract base that inherits from the interface. THe abstract base could also introduce pure virtual hook methods that are really the implementation details that and provide convenience and code reuse.

Finally, you might be frustrated if your interfaces arent right - in that case, they just make things harder (ie you have all the additional work of interfaces and none of the advantages and then they feel plain wrong) - but given by what you're saying, this doesn't look like to be the case.

Full disclosure - I'm not a .NET developer. I'm a java/python developer though I have decent exposure to .NET. There's far more .NET developers at my workplace than Java devs - and we have these discussions quite a bit. As an aside, I find this sentiment that interfaces are overused more prevalent in the .NET world rather than among Java devs - but that's just my perspective.