Good Case For Interfaces

Question

I work at a company where some require justification for the use of an Interface in our code (Visual Studio C# 3.5).

I would like to ask for an Iron Clad reasoning t

Answer 1

• Test Driven Development
• Unit Testing

Without interfaces producing decoupled code would be a pain. Best practice is to code against an interface rather than a concrete implementation. Interfaces seem rubbish at first but once you discover the benefits you'll always use them.

Answer 2

Interfaces are not 'required for' at all, it's a design decision. I think you need to convince yourself, why, on a case-by-case basis, it is beneficial to use an interface, because there IS an overhead in adding an interface. On the other hand, to counter the argument against interfaces because you can 'simply' use inheritance: inheritance has its draw backs, one of them is that - at least in C# and Java - you can only use inheritance once(single inheritance); but the second - and maybe more important - is that, inheritance requires you to understand the workings of not only the parent class, but all of the ancestor classes, which makes extension harder but also more brittle, because a change in the parent class' implementation could easily break the subclasses. This is the crux of the "composition over inheritance" argument that the GOF book taught us.

Answer 3

Interfaces and abstract classes model different things. You derive from a class when you have an isA relationship so the base class models something concrete. You implement an interface when your class can perform a specific set of tasks.

Think of something that's Serializable, it doesn't really make sense (from a design/modelling point of view) to have a base class called Serializable as it doesn't make sense to say something isA Serializable. Having something implement a Serializable interface makes more sense as saying 'this is something the class can do, not what the class is'

Answer 4

In addition to things explained in other answers, interfaces allow you simulate multiple inheritance in .NET which otherwise is not allowed.

Alas as someone said

Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.

Answer 5

To enable unit testing of the class.

To track dependencies efficiently (if the interface isn't checked out and touched, only the semantics of the class can possibly have changed).

Because there is no runtime overhead.

To enable dependency injection.

...and perhaps because it's friggin' 2009, not the 70's, and modern language designers actually have a clue about what they are doing?

Not that interfaces should be thrown at every class interface: just those which are central to the system, and which are likely to experience significant change and/or extension.

Answer 6

The problem with the inheritance argument is that you'll either have a gigantic god class or a hierarchy so deep, it'll make your head spin. On top of that, you'll end up with methods on a class you don't need or don't make any sense.

I see a lot of "no multiple inheritance" and while that's true, it probably won't phase your team because you can have multiple levels of inheritance to get what they'd want.

An IDisposable implementation comes to mind. Your team would put a Dispose method on the Object class and let it propagate through the system whether or not it made sense for an object or not.