Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Now referring to Interfaces as Contracts in code and conversation

I am just throwing this out there and am looking for feedback.

The other day when I was setting up the structure for a project at work I went to create a folder called interfaces (this is an API style project and this was going to hold all the public interfaces for the project), but I stopped.

As I sat there trying to figure out why I had stopped it dawned on me that I no longer liked the name interface(s) when talking about code.  I really like the term Contract.  The more I thought about it the more I really started to like it.

To me the term contract conveys more meaning to the next developer then the term interface.  By using the contract I am making a statement to everyone else that I am putting thought into this and this is EXACTLY what I want to expose to you, nothing more, nothing less.

I think going forward I am going to start referring to my interface (IFoo) as contracts and only use the work interface when creating the actual code.

Thoughts, Feedback?

Till next time,

[--- Remember to check out www.dimecasts.net ---]


Posted 12-23-2008 2:05 PM by Derik Whittaker

[Advertisement]

Comments

Jim wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-23-2008 3:34 PM

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

Caleb wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-23-2008 3:59 PM

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

sergiopereira wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-23-2008 4:26 PM

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.

DotNetKicks.com wrote Interfaces or contracts?
on 12-23-2008 5:50 PM

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

Hernan Garcia wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-23-2008 6:06 PM

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.

Jimmy Bogard wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-23-2008 6:18 PM

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.

Rod wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-23-2008 6:47 PM

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.

Colin Jack wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 3:52 AM

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.

Erik wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 4:12 AM

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

Bryan Watts wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 11:01 AM

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.

Derik Whittaker wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 11:08 AM

@Bryan,

<Smart Ass Response Here>

I forgot about the blue bible of DDD.  Since Eric said it, it must be gospel.

</Smart Ass Response Here>

No really i have read much of the DDD book.  But I choose to make my own design decisions based on my thoughts, beliefs and not do something just because i was told 'this is the right way'.  Of course I take into account things i have observed and practices which i find are better, but i do it on my own accord.

Sorry, i just hear way too many people talk about the blue book as being the 'be all end all' book.  It is not.  It is a good book with quality content, but like anything we read you must first understand what is being said then act upon it.  We must not simply do something because we are told to.  We are a profession of thinkers, not drones.

Bryan Watts wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 11:27 AM

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.

Derik Whittaker wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 11:34 AM

@Bryan,

I was not ignoring your advice.  In fact I am giving it some thought and i may change the layout of the project.  However, the layout of the project really has nothing to do with the spirit of the post.

In terms of DDD, yes may not have been the best decision to mention it.  

Bryan Watts wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 11:40 AM

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.

Derik Whittaker wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 11:48 AM

@Bryan,

Not sure how you can I ignored the advice being given.  In fact I even stated that I was taking it into account and MAY change things.

In terms of my rant on DDD (really goes well beyond DDD or that book) was not directed at you in any way, shape or form.  

Bryan Watts wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 12:53 PM

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.

Derik Whittaker wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-24-2008 1:22 PM

@Bryan,

I also like the lively chat.

Dave wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-27-2008 11:31 PM

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.

mwatts wrote re: Now referring to Interfaces as Contracts in code and conversation
on 12-29-2008 3:00 AM

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.

nm wrote re: Now referring to Interfaces as Contracts in code and conversation
on 01-01-2009 9:41 AM

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

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)