Hacker News Reader

Comment by jfager | Hacker News Reader

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?

View on HN

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.

Do you really think that interfaces on their own constitute 'uber flexibility taking over'?

Prolific over use of interfaces when all you have is a single implementor. In a word Yes.

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".

The point of the blog post was that we should use interfaces when appropriate, just not by default.

I recognize the point of the blog post, but I think that's it's more dismissive of interfaces than is warranted - the title outright says to mostly stop using them, and the 3rd paragraph suggests their use is split between over-engineering and mocking. It's not until the end that you start talking about what else interfaces are good for, and even then there's a sense that you think they should be used with care.

I just disagree with that; I think it's far better to have an interface you don't really need lying around than to be caught without one when you do need it.

Reply on news.ycombinator.com