Intellisense is not a contract. or where have all the interfaces gone?
There’s something that’s been on my mind and after talking to a few folks locally I thought it may be worth while to express these fews in the open and see what other folks think about it. I’ve made it pretty clear that I’m into many different languages, frameworks and platforms. The plus to this lifestyle is that you can pick up the best of all situations and (if possible) you can be, as Neal Ford says, a polyglot programmer. If Ruby makes sense, use it, if F# makes sense, use that. I love that flexibility. More than the flexibility I love learning the conventions, patterns and practices that are born from the specific problem sets of each language (framework, pattern, etc)
In the past, I’ve, fairly and unfairly, criticized C# for being overly verbose (unless you compare it to VB.net) and I believe that was due to the fact that C#’s specification was originally doing too much. (temping Java devs, helping C++ devs come to managed, looking familiar to all but being new!) Since the original spec, we’ve grown to a C# 3.0 spec that is truly fantastic. The language is statically type but not rigid with a wonderful Reflection library, type inference, annoymous types and methods.All wonderful additions and totally welcome, no matter how demanding the learning curve may be.
Which brings me to interfaces. I’m talking interface in the sense of the C# implementation of it. In the past 5 years, I’ve seen less and less implementation of interfaces leading to more and more obfuscation of object models. Developers use naming conventions to established unity of contract and not an actual contract. I would seem that developers of C# libraries believe that since VS.NET will tell you what methods are available on an object that is currently referenced by the project that they are covered. They are certainly right to a point. Sure, if you need to quickly remember what methods are available Intellisense is perfect but you can’t build a dependcy on an outer library that can’t commit to the signatures that it is specifiying.
Before you say it, I know what you’re thinking… IClonable. Sure, IClonable is the best example of an Interface being ambiguous (the issue was deep vs. shallow copy FYI) but without other interfaces, like ICollection and IEnumerable C# would be an entirely different language. You like the implementation of foreach in C#? Well, it wouldn’t be possible without IEnumerable. foreach relies on the Interface to provide the functionality that you’d expect. That’s pretty cool and doesn’t take much to take advantage of on your own with your own collections. Just honor the IEnumerable contract and you can join the fun.
Now, I’m not suggesting that we go back to header files for each class we write but I am saying that if you’re expecting other folks (and that includes yourself) to use and depend on the code that you build you should make sure that the contracts that you expect and depend on for your program to run are honored by both the provider and the consume. It makes like easier for everyone when we can rely on what you say is going to be there.
So, what do you think? Am I making more of this than I should? Should I be happy that I have VS.NET for intellisense to prove a contract? Is it worth it? I think it is and will continue to do so.
Before I leave you, I will also mention that Interfaces provide a great view into true polymorphism. Show of hands: who where has tried to unit test asp.net? Why is it difficult? If you answered outer dependencies you’d be right. This issue exists in many different languages and frameworks who need to do the same thing. You need a web server to create an HttpContext. Your tests are bound to that environment and may fail based on other aspects of your environment and not on your actual codebase which is frustrating to say the least. Well, if there was an Interface for HttpContext (and now there is in the MVC framwork!) then you could mock the context and run your tests. Good times. Well, if you have a similar situation then it would be fantastic to provide the same interfaces to others so that they may also provide a completely different implementation for your contract that satisfies the needs of all who care. It helps in testing, it helps in debugging, it helps in documenting your code.
It’s not even a lot of work. So, think about it, start small and next time you’ve got a class you’re building, take a look at it. If you say “You know what? This class is useless without x,y,z properies.” Give it an interface! I’ll be happy you did. :)
Bonus Section!
For my birthday this year, I would like the following interfaces…
Since MVC is available, I won’t ask for all the asp.net interface I want. :)
In the past, I’ve, fairly and unfairly, criticized C# for being overly verbose (unless you compare it to VB.net) and I believe that was due to the fact that C#’s specification was originally doing too much. (temping Java devs, helping C++ devs come to managed, looking familiar to all but being new!) Since the original spec, we’ve grown to a C# 3.0 spec that is truly fantastic. The language is statically type but not rigid with a wonderful Reflection library, type inference, annoymous types and methods.All wonderful additions and totally welcome, no matter how demanding the learning curve may be.
Which brings me to interfaces. I’m talking interface in the sense of the C# implementation of it. In the past 5 years, I’ve seen less and less implementation of interfaces leading to more and more obfuscation of object models. Developers use naming conventions to established unity of contract and not an actual contract. I would seem that developers of C# libraries believe that since VS.NET will tell you what methods are available on an object that is currently referenced by the project that they are covered. They are certainly right to a point. Sure, if you need to quickly remember what methods are available Intellisense is perfect but you can’t build a dependcy on an outer library that can’t commit to the signatures that it is specifiying.
Before you say it, I know what you’re thinking… IClonable. Sure, IClonable is the best example of an Interface being ambiguous (the issue was deep vs. shallow copy FYI) but without other interfaces, like ICollection and IEnumerable C# would be an entirely different language. You like the implementation of foreach in C#? Well, it wouldn’t be possible without IEnumerable. foreach relies on the Interface to provide the functionality that you’d expect. That’s pretty cool and doesn’t take much to take advantage of on your own with your own collections. Just honor the IEnumerable contract and you can join the fun.
Now, I’m not suggesting that we go back to header files for each class we write but I am saying that if you’re expecting other folks (and that includes yourself) to use and depend on the code that you build you should make sure that the contracts that you expect and depend on for your program to run are honored by both the provider and the consume. It makes like easier for everyone when we can rely on what you say is going to be there.
So, what do you think? Am I making more of this than I should? Should I be happy that I have VS.NET for intellisense to prove a contract? Is it worth it? I think it is and will continue to do so.
Before I leave you, I will also mention that Interfaces provide a great view into true polymorphism. Show of hands: who where has tried to unit test asp.net? Why is it difficult? If you answered outer dependencies you’d be right. This issue exists in many different languages and frameworks who need to do the same thing. You need a web server to create an HttpContext. Your tests are bound to that environment and may fail based on other aspects of your environment and not on your actual codebase which is frustrating to say the least. Well, if there was an Interface for HttpContext (and now there is in the MVC framwork!) then you could mock the context and run your tests. Good times. Well, if you have a similar situation then it would be fantastic to provide the same interfaces to others so that they may also provide a completely different implementation for your contract that satisfies the needs of all who care. It helps in testing, it helps in debugging, it helps in documenting your code.
It’s not even a lot of work. So, think about it, start small and next time you’ve got a class you’re building, take a look at it. If you say “You know what? This class is useless without x,y,z properies.” Give it an interface! I’ll be happy you did. :)
Bonus Section!
For my birthday this year, I would like the following interfaces…
- ISPContext
- ISPWeb
- ISPWebService
- ISPSite
Since MVC is available, I won’t ask for all the asp.net interface I want. :)
articleStats
Here are some silly little facts about this Intellisense is not a contract. or where have all the interfaces gone?...
It was written by Leon 4 months ago.
It has 5242 letters in it.
It has 871 words in it.
It has a total of 2 comments in all.
So far Leon has the last word!
A guy who also programs in Ruby advocating for interfaces? What happened to duck typing?
Intellisense quite often doesn't work. I can't tell you the number of times I've sat behind a developer who's convinced a method isn't there because it doesn't show up in Intellisense, in spite of the fact it exists. Drives me crazy.
I've always been a strong advocate of interfaces. I don't think the average C# developer uses them enough; when I talk to many C# developer about interfaces, they think I'm talking about Winforms...
I would hope as more people incorporate unit testing into their development the use of interfaces may spread, since maybe if they use an interface to create a testable class, they'll see that interfaces are not so painful (especially with a tool like ReSharper).
On the other hand, we might all soon be programming in Ruby and completely abandon the interface concept.