Please don't. Interfaces are one of the few redeeming aspects of the language. They give you a way to fake mixins, they're the only hook for dynamic proxies (for quick, simple, non-bloated aspect-oriented programming), and they let you swap in different implementations. Interfaces are good, use more.
What's the perceived downside of using interfaces? That you end up with more files? That you dead-end into bare method declarations when browsing your code? Any others?
How about trading off code readability for code complexity that has some potential future payoff? Library developers might want to trade more of their readability than app developers because of the nature of 3rd party code. It's ultimately a trade off that you have to make, but there are some general rules of thumb can help you so that uber flexilibity doesn't take over.
Please read the article. Its title is very misleading. Basically it only says "With this great new mocking framework, you don't anymore have to create interfaces for everything just to be able to write proper unit tests".
There are good reasons to use interfaces and to just accept the extra minor bit of work that goes with them. When using injection frameworks (like Spring), it makes life easier to reference an iface and have your concrete class plugged in automagically (using annotations). The iface also provides a clean look at the intentions of the application. Writing impl classes is trivial with an IDE - you can create your impl and fill in stub methods quite easily. The tradeoff of separation can be worthwhile in a complex system.
One reply to address the others. Yes, Spring does not require iface proliferation - it just makes life easier when you decide you need different implementations of the same idea if you've committed to ifaces up front. YAGNI still holds true since it's usually easy enough to refactor in an interface when it does become necessary.
As far as comments about the ugliness of Java in this regard, I couldn't agree more. However, Java is Java and Python is Python, etc. If you are working in Java, and a lot of people are and don't have the option of switching to something else (think corporate, where what is common and familiar is good), if you are committed to Java, then you must embrace its paradigms. Interfaces and implementation classes are one of those. Enjoy it without fuss and focus on the problem at hand. You'll lose less sleep that way.
I don't do Java, but I always prefer to code to interfaces rather than implementations. It is more sane and allows you to "late bind" more. It is also easier to test, even in languages that aren't as strict as Java. Sure, not everything should be an interface/implementation combination, but it's not a bad start.
I guess this is only tangentially related to each other Mock objects and interfaces. I stopped using interfaces in this manner. My rule if you only have one implementation of an interface you don't need an interface. Wait to create the interface when you get your second implementation, and we have great tools that make that easy.
Now for people who do lots of mock objects this rule doesn't help them out much, but my other rule is I don't overly separate my system for testing purposes. Sure there are times when you need a mock object for java mail or external services you need to mock out. But, doing it for every service you have is really a lot of work for questionable gain. This is predicated on practical experience rather than architecture theory. The reason you separate your system for testing is to find more bugs. I found that I wasn't finding anymore bugs by separating things than I was by testing it integrated. And, in fact I found more bugs in the integration of services than I would if I only tested them in separate form. Therefore, I stopped doing the extra work to separate them because the payoff was really too small to bother. It's been much more productive to think like this.
So, the argument is that you can stop the pattern of writing IFoo and FooImpl when you're pretty sure that the only other impl of IFoo will be MockFoo.
The first { opens the body of the anonymous inner class.
The second { starts an instance initialization block, which runs on each object when it is constructed - not sure if it's before or after the constructor - gonna guess before!
It's useful in this case as anonymous inner classes can't define constructors.
No, it isn't. The first { encloses the class and the second encloses the "anonymous constructor" or whatever is called. It's code executed at object creation, even before the "named" constructor.
[+] [-] jfager|16 years ago|reply
What's the perceived downside of using interfaces? That you end up with more files? That you dead-end into bare method declarations when browsing your code? Any others?
[+] [-] chubbard|16 years ago|reply
[+] [-] brazzy|16 years ago|reply
[+] [-] kaffeinecoma|16 years ago|reply
[+] [-] locopati|16 years ago|reply
[+] [-] locopati|16 years ago|reply
As far as comments about the ugliness of Java in this regard, I couldn't agree more. However, Java is Java and Python is Python, etc. If you are working in Java, and a lot of people are and don't have the option of switching to something else (think corporate, where what is common and familiar is good), if you are committed to Java, then you must embrace its paradigms. Interfaces and implementation classes are one of those. Enjoy it without fuss and focus on the problem at hand. You'll lose less sleep that way.
[+] [-] jbooth|16 years ago|reply
[+] [-] kaffeinecoma|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
[+] [-] chubbard|16 years ago|reply
Now for people who do lots of mock objects this rule doesn't help them out much, but my other rule is I don't overly separate my system for testing purposes. Sure there are times when you need a mock object for java mail or external services you need to mock out. But, doing it for every service you have is really a lot of work for questionable gain. This is predicated on practical experience rather than architecture theory. The reason you separate your system for testing is to find more bugs. I found that I wasn't finding anymore bugs by separating things than I was by testing it integrated. And, in fact I found more bugs in the integration of services than I would if I only tested them in separate form. Therefore, I stopped doing the extra work to separate them because the payoff was really too small to bother. It's been much more productive to think like this.
[+] [-] ShabbyDoo|16 years ago|reply
[+] [-] lambdom|16 years ago|reply
[+] [-] Robin_Message|16 years ago|reply
The second { starts an instance initialization block, which runs on each object when it is constructed - not sure if it's before or after the constructor - gonna guess before!
It's useful in this case as anonymous inner classes can't define constructors.
[+] [-] samuel|16 years ago|reply