Must admit that for some time I've switched to non-traditional approach to Java code. In my approach interfaces are used to express whole API via few methods which then implemented in the implementation class. This solves few problems:
implementation remains compact because only few methods need to be implemented
implementation contains code which is rarely interesting to class users
class users usually don't need to look into implementation, so don't hit "the wall".
In general case interfaces are necessary to define class API. Each implementation is written as if only interfaces of other classes are present. This way we clearly separate API and its implementation. It's not even about testing. It's more about keeping code clean from implicit hidden dependencies on details of implementation of the class we're working with.
If that works for you and everybody else on your team - I‘m not against it. It‘s quite common to separate API from implementation for modules or services.
Still, to achieve what you’re describing, you don‘t need an interface (if you only have 1 implementation). A properly encapsulated class, with most methods private, and a decent Javadoc documentation would be enough. And that‘s my point.
My point about „hitting the wall“ is not about depending on implementation details - you’re completely right, that should be avoided, and can be, whether you use interfaces or not.
It‘s a statement about gaining a deep understanding of a shared codebase - which would involve your code and the code it depends upon.
From my point of view interfaces have significant advantage: they are free from unnecessary implementation "noise": fields, constructors, private constants, etc. This allows to keep code simpler and cleaner to read. This is especially true for library/framework code often heavily optimized for speed and/or space. Such a code somewhat hairy and hard to read and understand.
My current code style is significantly shifted towards interfaces and often I don't have even implementation classes and everything is put into interface.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Must admit that for some time I've switched to non-traditional approach to Java code. In my approach interfaces are used to express whole API via few methods which then implemented in the implementation class. This solves few problems:
In general case interfaces are necessary to define class API. Each implementation is written as if only interfaces of other classes are present. This way we clearly separate API and its implementation. It's not even about testing. It's more about keeping code clean from implicit hidden dependencies on details of implementation of the class we're working with.
If that works for you and everybody else on your team - I‘m not against it. It‘s quite common to separate API from implementation for modules or services.
Still, to achieve what you’re describing, you don‘t need an interface (if you only have 1 implementation). A properly encapsulated class, with most methods private, and a decent Javadoc documentation would be enough. And that‘s my point.
My point about „hitting the wall“ is not about depending on implementation details - you’re completely right, that should be avoided, and can be, whether you use interfaces or not.
It‘s a statement about gaining a deep understanding of a shared codebase - which would involve your code and the code it depends upon.
From my point of view interfaces have significant advantage: they are free from unnecessary implementation "noise": fields, constructors, private constants, etc. This allows to keep code simpler and cleaner to read. This is especially true for library/framework code often heavily optimized for speed and/or space. Such a code somewhat hairy and hard to read and understand.
My current code style is significantly shifted towards interfaces and often I don't have even implementation classes and everything is put into interface.