Does the concept call for imposing inheritance?
Do I make a reference or value type?
Do I make the class abstract? Do I seal it?
Do I make its members abstract? Virtual?
Do I specify hierarchy-wide implementation details?
How will derived classes use and override these rules?
What state will each instance store? What state is static?
What problem was I solving again?

When we identify the need for a new type, we really uncover a dependency on some set of operations which is best left to another component. Choosing to model those newly-discovered capabilities with a class or struct places the emphasis square on the implementation. It’s tempting to delve in and switch contexts.

Decoupled design is about isolation, and nothing isolates a dependency with fewer decisions and assumptions than an interface. They are a low-friction way to identify work for later while keeping the focus on the current problem.

In that respect, I call reverse YAGNI on @Harry M

(I should qualify this by saying that I don’t use entity interfaces. Abstraction in the model should only occur if it exists in the domain.)

If you are shipping assemblies for public consumption then you REALLY have to think about using interfaces vs assemblies (particularly given that adding a method or property to an interface requires that the consumer implement it, while you can add a property to a base class without forcing your consumer to update their code).

If you aren’t exposing the code to a third party (most of the lines of code I suspect most people write) then versioning etc. isn’t a concern – when I need the flexibility to pass in different unrelated implementations I extract an interface – not before (YAGNI).

“The interfaces certainly don’t add flexibility to a system that you wouldn’t get with a class (given that you can always extract an interface when you actually need one).”

First, they do add flexibility because I can pass wildly different impls into a method that takes an interface in its signature vs. a class which forces me to either pass in that class or pass in an inherited class (if the base class even allows inheritance). Interfaces allow for composition scenarios in ways that classes don’t or only allow awkwardly.

Second, “you can always extract an interface” — that is, until you ship in which case you now have versioning and compatibility problems.

“I’m not sure if you are agreeing with me, missing my point,…” it appears I was missing your point.

Interfaces on entities is an anti-pattern and part of what I was referring to earlier with people mis-using interfaces.

It seems in most of these discussions I get with people advocating abstract classes, they don’t first understand how to use interfaces properly. The problem is not interfaces vs. abstract classes usually, but rather bad interface usage vs. abstract classes. So abstract classes seems the more reasonable, logical alternative. But in a choice between bad and wrong, wrong seems not as bad.

But I propose good vs. wrong and good wins, at least in my book.

The interfaces certainly don’t add flexibility to a system that you wouldn’t get with a class (given that you can always extract an interface when you actually need one).

While we’re talking about the pain of interfaces, its a good time to tangentially pimp Nicolas Dorier’s little-known-but-AWESOME Genuilder project, a pre-processor for msbuild (it’s like PostSharp for source code) that can (amongst other amazing things) magically generate an interface for your classes by marking them up with an attribute.

http://genuilder.codeplex.com/documentation – see the InterfaceExtrator magic. Genuilder blew a few minds at the London ALT.NET conference recently, where we did a code session and wrote an extension to mark all properties as virtual according to a convention.

I’m not sure if you are agreeing with me, missing my point, or avoiding the discussion.

I was angling towards an entity. I don’t personally back my entities with interfaces except where polymorphism is desired. I get the impression that many folks do, in the name of TDD (or whatever flavor). This is the point I was making. I would argue that entities without implementation rules are just typed data tables.

Substitute your own “good” example if necessary, so long as its not apples to oranges like your IDocumentProducer example, which is a service, not an entity.

Both INumber and IFiftyOrLess are bad examples because they imply implementation rules and so aren’t good candidates for interfaces in the first place. A better example may be an IDocumentProducer that has a GetDocuments() method.

RE: Dynamic keyword: I admit I haven’t had a lot of opportunity to play with this in C# yet. I’d probably be tempted to treat it like I would a dynamic language and I’d probably be disappointed by that, but I can’t speak from experience, only speculation at this point.

But the point I was trying to make is that the way I use interfaces is to get the compiler to acknowledge that the passed-in object will have a Bar() method with the correct signature.

I believe Jimmy is of the same or similar mindset here. It is common/normal to have many/most interfaces with only a single implementation. This is because the interface is being used to satisfy the compiler’s requirement of certifying that the passed-in object has the correct method signature for Bar().