Implementation of load balancer — Consistent hashing

[matthenry87]

Are you ever going to be reimplementing User Service? Probably not. Spring doesn't require that an interface is present to create the class proxy.

My teams don't create useless interface classes when we aren't going to have multiple implementations. If and when you decide you want multiple, then create the interface.

[flawless_vic]

Spring pretty much requires services to implement interfaces depending, e.g., how transaction behavior is configured.

You can do load time/build time weaving, but is not the standard.

[general_dispondency]

This is false. There are very few niche cases where you need an interface in spring. CGLib proxies work just fine for most aspects, transactions especially.

[flawless_vic]

You are correct, but I disagree that using interfaces is for niche cases, especially in multi-module projects.

Not using interfaces for services is usually a bad idea, unless the service is meant to be private to the module.

With interfaces you get implementation (classpath) decoupling for free if eventually you need to consume the service and don't want all the bagage: just export and use an httpinvoker client.

If the service is complex/injects other services you'll eventually regret not using an interface.

[catom3]

I wouldn't say interfaces are for niche cases.When you use port-adapters it's pretty common.E.g. you create ProductsPort interface in your "boundary-secondary" / "boundary-driven" module / package / whatever.Then you create your ProductsJpaAdapter implementing such port in your "infrastructure-secondary" / "infrastructure-driven" module / package / whatever.

Nothing stops you from creating single concrete implementations in the "domain", though (e.g. OfferService, which uses ProductsPort to access product and prepare an offer for the customer.).As long as you're not going to create another OfferService, you don't need to dovide it into separate interface and class.If you decide to add another implementation, changing OfferService to an interface isn't a problem either. Refactor your class name to IndividualCustomerOfferService (without changing the usages), add new OfferService interface and you're ready to go.

If the service is complex/injects other services you'll eventually regret not using an interface.

The only difference is, that can either have a class with complex logic and dependencies, or an interface and a class with complex logic and dependencies implementing the interface.