I agree. Contract is more expressive than Interface. But do you think that then you should rename IFoo to FooContract?

Sorry this is unrelated to the post, but I noticed that your link to http://www.dimecasts.net/ is misspelled.

I think interface is equally as good but maybe that term became a little bit too much overused (like marker, empty interfaces) and lost some of its meaning. Think about what you just wrote: "this is EXACTLY what I want to expose to you, nothing more, nothing less." - That is what I understand by interface as well.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Uhm, interesting.

While thinking about this I tend to make a distinction. I won't call my IFoo a contract but an Interface from the programming point of view, like my class Foo and Bar both may implement the IFoo interface.

Now, what I expose to my user that will eb a contract.

If I brake the contract this will have consecuences for me and anybody using my objects.

In this Contract I will include anything that is public (classes, enum, structs, and Interfaces).

So maybe API should be called APC?

Or better yet, the API or set of API's your system expose is the contract.

At this point having a project folder called Contract make sense, since the programmers may agree that anything that resides in that folder is part of the contract.

But what about public classes that expose public methods?

They should be in this folder as well, not just the interfaces but also any concrete or abstract public object.

I will have to think a bit more about this.

Dave Laribee had a ditty a while back:

codebetter.com/.../tdd-contracts-and-reading-the-fine-print.aspx

Interestingly it seems that C# 4 will allow you to enforce the contract.

Scott Bellware pointed out to me that interfaces only allow us to enforce a contract for the signature of the methods, but not their behavior.  It's up to us as devs to both name the interface and operations well, as well as provide implementations (and tests) that provide correct behavior.

I think that by starting calling interfaces "contracts" you may end up diluting the meaning on the word contract, which is not good. If the word interface reminds you something weaker, it's because interfaces *are* weaker than contracts; people can't "break" an interface  (it won't compile) but at the same time an interface doesn't guarantee that the user is following any of the contract you have in mind, there is nothing in the interface that prevents another dev from writing all types of crazy stuff inside the interface implementation functions.

I agree with Jimm/Dave/Scott, to me interfaces alone are not really contracts, they are perhaps the key part of the contract but i do think there is more involved.

I like the terms Specifications,and in good name the interfaces ITheResponsibility. Interfaces isnt really contracts in my opinion. If its not in a SOA/WS-application.But thats just my humble opinion. Merry Xmas

An interface describes the operations available and their signatures, nothing more. As others have pointed out, this is not a true contract, and as such, "interface" is an exactly correct term.

.NET 4.0 has "true" contracts, and they can be built upon interfaces. These are distinct concepts and (in my opinion) would not benefit from being muddled.

Beyond that, I question the value of a namespace dedicated to "the public API". Partitioning code based on technical structure is an anti-pattern; Eric Evans addresses this in DDD (paraphrasing): You see the story of the code the developer was writing at the time, not the domain story.

Your response is exactly the reason I called this an anti-pattern: it is an intuitive thing to do that doesn't seem detrimental in the short-term; it even seems downright clever!

But I'm willing to bet you haven't fully explored your idea and its implications in long-term maintenance scenarios, when the next developer comes along and says "great, I know where everything public is, but there is a huge amount of stuff in here, and it keeps growing! Why couldn't it be organized by feature so I can infer what this project actually does?"

I wish I hadn't mentioned DDD, because then you may have actually considered the design principle I was advocating. Ignoring good advice doesn't suddenly make your ideas better, no matter the source.

I would much rather shop in a grocery store which organizes products by type, instead of the size and shape of the packaging.

The ironic part is that you deride "drones" for not really considering the advice being given, and then you completely ignore the advice being given to remind people to consider the advice they are given.

I don't attach "gospel"-like qualities to DDD. You assumed I am just a "hey, I read this book today!" coder and responded as such. While I understand it can be wearing to hear about DDD yet again, we would have had a more productive conversation if you hadn't initially profiled me as "zealot", which is far from the truth.

I understand; I wrote my prior comment before refreshing and reading yours. I think we both came out of the gate with some preconceptions of the others' perspective.

You are wary of DDD because it tends to be framed as a "silver bullet", which we know doesn't exist in software. I have a bear of a time trying to promote its principles in the face of those who don't see its value.

With this dynamic, rhetoric is easily employed by both sides. I wasn't trying to make an argument from authority; DDD gives some definition to abstract issues that otherwise each of us has to think through separately. I was looking for common ground, not deference.

Thanks for the lively chat.

I don't see how it's going to make any difference.

1) Everyone knows an Interface is a contract

2) Everyone knows it's a contract because you must implement all members of the Interface

The intent of an interface is something learned and is something that you decided either to create or not to create based on the project's purpose, use, and planning out of the entire framework.

So I don't know that it makes any different because anyone using an Interface has to come across the term "contract" or they would not understand what an Interface is if they did not.

I guess, for a large part, it is a matter of taste what you call your interfaces / contracts, although I share the feeling that contracts have a SOA (WCF) feel, and that we should try to keep terms as disambiguous as possible.

In the plugin-style application framework we are working with here, we like to mark some of our classes as "Contracts" too, but we don't do that by sticking them in a seperate folder. I find that too inflexible, and (as Bryan was pointing out) it forces (parts of) your project into a technical structure, not a functional one.

Instead, we have defined an attribute, called "PublishedAttribute". I can mark any class, method etc. as [Published], and that flags the thing as "keep of, do not touch, modifications will possibly break clients!" to any other developer.

Besides that, our Plugin class can check on the attribute to see if it may execute a particular method or not.

Your applicaion is rather different. Users of your API will reference it. In our structure, application modules don't reference each other (unless they have a parent-child relationship), but the attribute suggestion might set you of onto some new ideas.

I like the idea.. and if they don't listen, you don't have to pay them. "You broke the terms of the contract!"