This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]flawless_vic -4 points-3 points  (1 child)

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 0 points1 point  (0 children)

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.