6 ms·

Relax. You can (mostly) stop using Interfaces in Java now

17 points by kaffeinecoma 17y ago

ShabbyDoo 17y ago
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.
lambdom 17y ago
Is it me or in both of the examples there is an extra { ? Is this something about Java I don't know about?
- samuel 17y ago
  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.
- Robin_Message 17y ago
  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.
locopati 17y ago
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.
- jbooth 17y ago
  Yes, but generally speaking, if you're writing FooIFace and FooImpl you should probably rethink what you're doing.
  - jfager 17y ago
    Ideally, you'd just get it right the first time, but if you're going to screw up, it's usually better to screw up by having an interface you don't really need than by having a class that should really be an interface. Generalizing that makes it hard for me to agree that FooIFace and FooImpl is, on its own, evidence that something's wrong.
    - Tuna-Fish 17y ago
      This does condense what I dislike about java quite nicely. All proper java code is full of speculative architecture and genericity -- in order to have your code easily extensible, you do have to have setters, getters, interfaces, factories and everything else from version one. As an example of a language that gets it right, look at python. You can write your orginal classes in the simplest possible way they could be written, and yet expand from there to just as much architecture as your problem needs without ever touching the users of the class.
      - jbooth 17y ago
        Well, point taken about the getters/setters, those should be automatic or at least managed via keyword or annotation (private gettable String fname or something like that) As for the rest of it.. it's just a question of proper design. If you're just making a utility, you don't need any interfaces or factories. If you're making a module for something that's intended to be run with a half-dozen service dependencies, it's probably a good idea to design it in a way that said dependencies can be injected -- whether you're using spring or doing something more lightweight. That applies across languages, same deal in python.
        17y ago
jrockway 17y ago
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.
chubbard 17y ago
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.
jfager 17y ago
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?
- chubbard 17y ago
  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.
  - jfager 17y ago
    Do you really think that interfaces on their own constitute 'uber flexibility taking over'?
    - chubbard 17y ago
      Prolific over use of interfaces when all you have is a single implementor. In a word Yes.
- kaffeinecoma 17y ago
  The point of the blog post was that we should use interfaces when appropriate, just not by default.
  - jfager 17y ago
    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.

17 points by kaffeinecoma 17y ago

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.

lambdom 17y ago

Is it me or in both of the examples there is an extra { ? Is this something about Java I don't know about?

samuel 17y ago
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.
Robin_Message 17y ago
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.

locopati 17y ago

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.

jbooth 17y ago
Yes, but generally speaking, if you're writing FooIFace and FooImpl you should probably rethink what you're doing.
- jfager 17y ago
  Ideally, you'd just get it right the first time, but if you're going to screw up, it's usually better to screw up by having an interface you don't really need than by having a class that should really be an interface. Generalizing that makes it hard for me to agree that FooIFace and FooImpl is, on its own, evidence that something's wrong.
  - Tuna-Fish 17y ago
    This does condense what I dislike about java quite nicely. All proper java code is full of speculative architecture and genericity -- in order to have your code easily extensible, you do have to have setters, getters, interfaces, factories and everything else from version one. As an example of a language that gets it right, look at python. You can write your orginal classes in the simplest possible way they could be written, and yet expand from there to just as much architecture as your problem needs without ever touching the users of the class.
    - jbooth 17y ago
      Well, point taken about the getters/setters, those should be automatic or at least managed via keyword or annotation (private gettable String fname or something like that) As for the rest of it.. it's just a question of proper design. If you're just making a utility, you don't need any interfaces or factories. If you're making a module for something that's intended to be run with a half-dozen service dependencies, it's probably a good idea to design it in a way that said dependencies can be injected -- whether you're using spring or doing something more lightweight. That applies across languages, same deal in python.
      - 17y ago

jrockway 17y ago

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.

chubbard 17y ago

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.

jfager 17y ago

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?

chubbard 17y ago
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.
- jfager 17y ago
  Do you really think that interfaces on their own constitute 'uber flexibility taking over'?
  - chubbard 17y ago
    Prolific over use of interfaces when all you have is a single implementor. In a word Yes.
kaffeinecoma 17y ago
The point of the blog post was that we should use interfaces when appropriate, just not by default.
- jfager 17y ago
  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.