Not sure java is bad for indirections, java is bad for boilerplate and lack of defaults, imho. But I usually don't use frameworks/stlib directly, so I create my own boilerplate that is reusable
Not sure java is bad for indirections, java is bad for boilerplate and lack of defaults, imho. But I usually don't use frameworks/stlib directly, so I create my own boilerplate that is reusable
So I'm not talking about having one or two sensible interfaces as a contract, but codebases where every class has at least one interface, for "decoupling". Pure hell.
Concrete example from work today - we have a trading application and there are many paths that lead to alerts of some kind. Alerts are usually raised inline with any business logic (as should be - they intrinsically coupled). Alerts however can be delivered differently - via SMS, other messaging systems and/or log messages. The different places where the alerts need to be generated do not _need_ to know how the alert is going to be physically delivered to its destination - they just need to generate it. Without an interface (or at least a type alias for a function) - it would make being able to say e.g. this alert is a direct phone message vs. a chat message in some channel because of the type it is - much harder.
In the system I worked on the shortcut did not work - too many options or some consequence of the dependency system, additional layers of indirection.