I view these two articles as being important http://martinfowler.com/bliki/ImplicitInterfaceImplementation.html and http://martinfowler.com/bliki/RoleInterface.html.

So my view. If you go ahead and create a small cut-down client focussed interface then yes its a contract and has value as an abstraction. If you do Foo : IFoo then you have a header interface and unless you put a lot of work into the contract (pre-conditions/post-conditions/errors/side effects) people will just go to the iumplementation to understand the behavior. Plus how decoupled are you, change Foo and you have to change IFoo plus if you do have another class come along and want to have it replace Foo then you can be pretty sure the interface will need to change (in fact you'll want it to change).

So do I use Foo : IFoo, I sometimes do. IoC and mocking make it attractive and it doesn't do major harm other than hiding the true abstractions (which are far more exciting). However I do say that these header interfaces are not the big design advantage that some make it out to be, not by any stretch of the imagination. Also to me interface-implementation pairs are not what SOLID is all about (ISP).

"If you eliminated all abstractions and interfaces - even the interfaces that have only one implementation"

Don't think anyone is saying that we should eliminate them all, definitely not Roy/Bellware from what i've seen.

@Colin,

excellent Fowler articles. thanks for the links and clarification on the names, etc.


"unless you put a lot of work into the contract (pre-conditions/post-conditions/errors/side effects) people will just go to the iumplementation to understand the behavior."

very true. how do you handle design by contract? i tend to do it through good unit tests and intention revealing abstractions.


"Plus how decoupled are you, change Foo and you have to change IFoo plus if you do have another class come along and want to have it replace Foo then you can be pretty sure the interface will need to change (in fact you'll want it to change)."

true again. this can be a sign of a poor / weak abstraction - not always, though. and as you say, there are some benefits when talking about IoC and other techniques, and sometimes you have to make the judgment call to put in the weak abstraction for these purposes.

header interfaces certainly aren't a big design advantage - but they can reduce the cognitive load when done correctly.

For a real world example, I have an "IMessageSender" interface with a "Send(Message message)" method. My runtime implementation is called "MessageSender" and has a lot of WebsphereMQ/XMS.NET specific code inside of it. There's only one method in the MessageSender class - the one method that was defined by the interface. Although this is technically a "header interface", I also consider it to be a good abstraction. I can easily replace the MessageSender object with something that uses WCF, web services, flat files, FTP, or anything else that I want, and add as many other methods and properties to the implementation as I need.

unfortunately, the line between strong/weak or good/bad abstraction does get blurry when we move out of service implementations and into abstractions within the domain, etc. the point is - just because it's a header interface, doesn't mean it's a bad abstraction.


"Don't think anyone is saying that we should eliminate them all, definitely not Roy/Bellware from what i've seen."

i didn't mean to say that scott/roy were saying we should get rid of all the header interfaces - sorry if it sounded that way. I think scott was asking more rhetorically, and i don't think he would say to do away with them.


"Also to me interface-implementation pairs are not what SOLID is all about (ISP)."

once again, I agree. Interface segregation is more along the lines of Role Interface as defined by Fowler in your links.

Dependency Inversion, on the other hand, gives us a good reason to use interface-implementation pairs; and can provide the additional benefit of lowering our cognitive load, thereby lowering the barrier to entry in understanding the code.

Derick,

> An intention-revealing interface, as a contract, can
> significantly reduce the cognitive load that is required
> to understand the code in question

I think this belief is rooted in an assumption of what "interface" means as per your above point, and what the keyword "interface" is in C# or Java.

If we believe that this word means the same thing in different contexts, we might be shooting ourselves in the cognitive foot.

Any module's signature is an interface. If a module is already designed to be understood, adding an interface to it can add noise and cognitive dissonance.

Adding an intention-revealing abstraction (.NET interface) to a class that has been designed without consideration for humans and human cognition can be like putting lipstick on a pig.

It's not the intention of the interfaces that make software designs understandable, it's the intention of the software designer that makes software designs understandable.

The notion of interface types (IFoo, etc) as cognitive mechanisms is .NET lore. Consider languages that don't have interface types.

@Scott,

I do tend to speak from a C# perspective, since that's what I do all day (am actively trying to find time to change that, though). But I also understand that other languages don't have explicit "interface" constructs; c++ for example. whether or not it's an explicit construct, or simply the public signature of the API, the interface we design can, and should, reduce the cognitive load of the person reading the code.

"It's not the intention of the interfaces that make software designs understandable, it's the intention of the software designer that makes software designs understandable."

a chef employs the use of a pan to cook food. does that mean the pan's intention is to cook food? not a chance! the pan has no intention of it's own - it's merely a tool that the chef uses to fulfill his intention of cooking food. by the same notions, a software designer can employ interfaces to create a design that is understandable.

just because the tool does not have inherent "intentions", doesn't mean it can't be used to fulfill some intention of the user.