You can't just extend a house willy nilly. You have to set up scaffolding, destroy some walls, have temporary rigs to keep the ceilings from collapsing, etc. Unless you want to live in a "shipping container" building, but even then there's a non 0 effort, and the shipping container constraint comes with its own set of issues.
In real life, you just can't have it both ways. There's always a trade off. If the trade makes sense go for it I say, but I think people aren't always honest (to me or themselves) about the exact trade they are making.
The problem word, i think, is "extended." To me, that means adding functionality to the feature set, to others it may mean "changing the db" - and the two designs will be different.
So as simple as possible, without unnecessary indirections and useless abstraction like interfaces that make reading the code hard, right? ;)
There really are very different perspectives on what makes code easy to manage, and interfaces (especially ones used only for a single class) are a sure-fire way for me to make code unmanageable. But java enterprise coders disagree. That can clash hard.
What is about interfaces that makes reading code hard? It is a contract, for me reading just a list of operations that are available without the concrete code, is even clearer/cleaner.
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
It's about the indirection. In the calling code, instead of knowing which specific object you are working with - and thus easily being able to check its implementation - you only know which interface it implements. Getting to the implementation can be very time consuming, especially in a system with hexagonal architecture or similar indirect patterns and dependency injection. While searching the code you then lose the context of the problem you were working on.
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.
In my experience, using tools that do not support the "Go To Implementation" shortcut makes it hard. In IntelliJ, Ctrl+Shift+Click will take you to the possible implementors of an interface.
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.
