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