14 ms·

Why is having only one implementation for an interface bad? It neatly organizes all your code and doesn't make debugging harder at all.

hocuspocus 8y ago
How does having FooService and FooServiceImpl help with code organization at all? It brings nothing but unnecessary noise.
- humbleMouse 8y ago
  In my opinion I like hopping through a codebase where everything goes thru an interface. It just seems cleaner to me. Especially when I'm writing new classes I can think about what the interface does and stub the methods out first. So for me it just splits up the workflow in a really nice way and makes things look clean. I see your point though. Furthermore, when opening a new project you can just read through the interfaces quickly and get a good idea of what the code is doing. You can't just read thru a whole bunch of implementations and get as good of an idea.
  - hocuspocus 8y ago
    Use a better IDE? I've worked on my fair share of Spring projects and I don't miss this one bit. Even though I wade through a lot of open source libraries where the only documentation is the source code.
- Larrikin 8y ago
  FooService removes all the noise and makes it obvious the point of the class.
  - Rexxar 8y ago
    Like header/code in C or C++ ? I'm not a Java programmer but it seems like an abuse of interface if it's done systematically.
    - guitarbill 8y ago
      It's also silly. If this was the only use-case, you could just generate "interfaces"/headers from the class for the people who want this in e.g. an IDE. No need to liter the codebase with that.
- _old_dude_ 8y ago
  public interfaces help to make dependencies clear and honest. If the implementation doesn't provide more methods than the interface (a transparent class in GoF terminology) you should not name it. In Java, the implementation is usually created inside a static method (a static factory) of the interface as a lambda or an anonymous class.
  - hocuspocus 8y ago
    > public interfaces help to make dependencies clear and honest. Again, moot point if there's only one implementation. > If the implementation doesn't provide more methods than the interface (a transparent class in GoF terminology) you should not name it. > In Java, the implementation is usually created inside a static method (a static factory) of the interface as a lambda or an anonymous class. And how's that not needlessly convoluted and ugly? You're illustrating guitarbill's point about applying design patterns blindly.
- ivan_gammel 8y ago
  It's test-friendly. The code may not have explicitly defined second implementation, but a simple "@Mock FooService" declaration in a test.
  - guitarbill 8y ago
    This is a fair point, however in practice there's solution for that (Mockito, as long as the class isn't final). Which is how it should be. Your code shouldn't be untestable, on the other hand you shouldn't have to go out of your way to make it testable by adding more cruft.
    - ivan_gammel 8y ago
      I don't think the design should be based on the requirement to use Mockito library and it's not the only and not always the most convenient way to provide a test implementation. So, no, it's not how it should be.
- vermasque 8y ago
  Interfaces can also provide read-only references of a instance. Consider interface Foo with accessors only and a MutableFoo implementation with accessors and mutators. The creator of the MutableFoo instance can make all sorts of changes to the instance but then pass it around as a Foo that can't be modified. Another option is to simply put all the state in the constructor so that a Foo never needs to be mutated; however, that might not be elegant in some cases state is incrementally accrued. I do acknowledge that XImpl is kinda ugly as name.
  - hocuspocus 8y ago
    > The creator of the MutableFoo instance can make all sorts of changes to the instance but then pass it around as a Foo that can't be modified. Until you cast the object... You should use truly immutable data types unless you specifically need otherwise, most modern languages and libraries encourage you to do so.
jayd16 8y ago
When you only have one implementation, you often have no concept of what a second implementation will look like and you have no idea what concept or task you're delegating to the interface. They just become header files for the single implementation. Now, you can be good at planning ahead and know what the abstraction should be in many cases. This is still much rarer than all cases. Indiscriminately creating an interface for every class means you're probably not giving the interface much thought.

hocuspocus 8y ago

How does having FooService and FooServiceImpl help with code organization at all? It brings nothing but unnecessary noise.

humbleMouse 8y ago
In my opinion I like hopping through a codebase where everything goes thru an interface. It just seems cleaner to me. Especially when I'm writing new classes I can think about what the interface does and stub the methods out first. So for me it just splits up the workflow in a really nice way and makes things look clean. I see your point though. Furthermore, when opening a new project you can just read through the interfaces quickly and get a good idea of what the code is doing. You can't just read thru a whole bunch of implementations and get as good of an idea.
- hocuspocus 8y ago
  Use a better IDE? I've worked on my fair share of Spring projects and I don't miss this one bit. Even though I wade through a lot of open source libraries where the only documentation is the source code.
Larrikin 8y ago
FooService removes all the noise and makes it obvious the point of the class.
- Rexxar 8y ago
  Like header/code in C or C++ ? I'm not a Java programmer but it seems like an abuse of interface if it's done systematically.
  - guitarbill 8y ago
    It's also silly. If this was the only use-case, you could just generate "interfaces"/headers from the class for the people who want this in e.g. an IDE. No need to liter the codebase with that.
_old_dude_ 8y ago
public interfaces help to make dependencies clear and honest. If the implementation doesn't provide more methods than the interface (a transparent class in GoF terminology) you should not name it. In Java, the implementation is usually created inside a static method (a static factory) of the interface as a lambda or an anonymous class.
- hocuspocus 8y ago
  > public interfaces help to make dependencies clear and honest. Again, moot point if there's only one implementation. > If the implementation doesn't provide more methods than the interface (a transparent class in GoF terminology) you should not name it. > In Java, the implementation is usually created inside a static method (a static factory) of the interface as a lambda or an anonymous class. And how's that not needlessly convoluted and ugly? You're illustrating guitarbill's point about applying design patterns blindly.
ivan_gammel 8y ago
It's test-friendly. The code may not have explicitly defined second implementation, but a simple "@Mock FooService" declaration in a test.
- guitarbill 8y ago
  This is a fair point, however in practice there's solution for that (Mockito, as long as the class isn't final). Which is how it should be. Your code shouldn't be untestable, on the other hand you shouldn't have to go out of your way to make it testable by adding more cruft.
  - ivan_gammel 8y ago
    I don't think the design should be based on the requirement to use Mockito library and it's not the only and not always the most convenient way to provide a test implementation. So, no, it's not how it should be.
vermasque 8y ago
Interfaces can also provide read-only references of a instance. Consider interface Foo with accessors only and a MutableFoo implementation with accessors and mutators. The creator of the MutableFoo instance can make all sorts of changes to the instance but then pass it around as a Foo that can't be modified. Another option is to simply put all the state in the constructor so that a Foo never needs to be mutated; however, that might not be elegant in some cases state is incrementally accrued. I do acknowledge that XImpl is kinda ugly as name.
- hocuspocus 8y ago
  > The creator of the MutableFoo instance can make all sorts of changes to the instance but then pass it around as a Foo that can't be modified. Until you cast the object... You should use truly immutable data types unless you specifically need otherwise, most modern languages and libraries encourage you to do so.

jayd16 8y ago

When you only have one implementation, you often have no concept of what a second implementation will look like and you have no idea what concept or task you're delegating to the interface. They just become header files for the single implementation. Now, you can be good at planning ahead and know what the abstraction should be in many cases. This is still much rarer than all cases. Indiscriminately creating an interface for every class means you're probably not giving the interface much thought.