That pattern makes sense for large distributed systems or mature miceoservice frameworks that undergo constant maintenance or updating. And even then, it’s only useful if the interface is well thought out and designed.
In practice, the interface is whatever you happened to need when you make the service class, and it ends up being a 1:1 service to serviceImpl situation.
Most things don’t need to be a service, a utility class to send emails is fine, you’re not going to “interface” with that in any unique ways that need a service… im rambling on the toilet now
What about the Java practice of having a matching implementation class for every class? Or does that actually serve a purpose, lol.
That pattern makes sense for large distributed systems or mature miceoservice frameworks that undergo constant maintenance or updating. And even then, it’s only useful if the interface is well thought out and designed.
In practice, the interface is whatever you happened to need when you make the service class, and it ends up being a 1:1 service to serviceImpl situation.
Most things don’t need to be a service, a utility class to send emails is fine, you’re not going to “interface” with that in any unique ways that need a service… im rambling on the toilet now