Hacker News Reader

Comment by hocuspocus | Hacker News Reader

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

View on HN

It's test-friendly. The code may not have explicitly defined second implementation, but a simple "@Mock FooService" declaration in a test.

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.

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.

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.

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.

FooService removes all the noise and makes it obvious the point of the class.

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.

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.

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.

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

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.

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

Reply on news.ycombinator.com