Reason I avoid working in Java and especially the "senior java engineers".
> The logic from the senior engineer was that the interface represented the “contract” and the class the business logic.
This is basically religious dogma
Reason I avoid working in Java and especially the "senior java engineers".
> The logic from the senior engineer was that the interface represented the “contract” and the class the business logic.
This is basically religious dogma
However if instead you assume that "a class is just an implementation of an interface", then everything changes. Now the interfaces come first and classes are required to materialize them. In that paradigm objects only communicate with interfaces, never (or almost never) with other classes unless a specific implementation is required. Which is why an interface is always defined for a class even if there is no plan for other implementations of it.
Rather than a "contract", think of an interface as the description of a job. If you ever need to write a safety procedure, does it make more sense to write "In case of fire, call John; John happens to know how to extinguish a fire." or "In case of fire, call a fireman."? "Fireman" is an interface. "John" is a class implementing that job. It might be the only class in the codebase that implements it, but that is no concern of the caller. They just want that fire dealt with.