3 ms·
> I was working on a Spring Boot REST API a few months ago and the senior engineer had defined every single service class as an interface and then implemented t
by qazpot 5y ago
> I was working on a Spring Boot REST API a few months ago and the senior engineer had defined every single service class as an interface and then implemented that interface in an actual @Service. The interfaces weren’t extended by multiple classes, this wasn’t an external library or a dependant, and there were no plans to implement additional classes later.
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
- wiennat 5y agoI am doing this and it helps in mocking the interface in other classes tests.
- jpatte 5y agoIt doesn't make much sense for people who always heard and thought that "an interface just lists the public methods and properties of a class". In that view the classes always come first and the interfaces are unnecessary boilerplate. 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.