CODEWITHSUNDEEP
javaspringspring-mvcsoa
loyalflow
loyalflow

Reputation: 14879

Avoiding tight coupling between Service classes

Say I have 2 service classes:

UserService
ProductService

Is it wrong if within my ProductService class I inject the UserService?

public class ProductserviceImpl implements ProductService {


  @Autowired
  UserService userService;


  @Override
  public void someThing() {
      ..
      userService.otherThing(..);
      ..
  }

}

I know as an alternative I could create yet another class that injects both UserService and ProductService, but coming up with a name for this class is very tricky :) Is there a name for these types of classes in the SOA world?

Upvotes: 4

Views: 1327

Answers (5)

Arnon Rotem-Gal-Oz
Arnon Rotem-Gal-Oz

Reputation: 25909

What you describe is object oriented integration and most likely not a SOA one. The fact that you may get (and should avoid) cyclic dependencies demonstrate that.

If you're services know other service Java level Interfaces you are also in a big risk to introduce tight coupling. For instance, what's the return type from the User service? is it yet another interface that belong to the User service? do you pass it around in the code of product service?

Upvotes: 0

Jason
Jason

Reputation: 7636

1) Is it wrong if within my ProductService class I inject the UserService?

There is nothing wrong with this per se, with the following caveats:

  • Be aware that you could be potentially heading in the direction of one class doing too much (here, the ProductService)
  • Be careful that you don’t introduce cyclic dependencies (you should not have UserService also depend on ProductService)
  • Limit tight coupling by wiring your dependency to the interface rather than the concrete class (here you are autowiring UserService instead of UserServiceImpl, which is good)

2) Is there a name for this type of class (that injects both UserService and ProductService) ?

Yes, as was mentioned, you could call this class a Mediator since the Mediator Pattern seems to describe this.

You can have both low-level services and high-level services, with the low-level ones (ProductService, UserService) injected into the high-level ones (say, PurchaseOrderService or PurchaseOrderMediator). Alternatively, for this particular case you might think of the product service as being a single high-level service that depends on UserService. At that point it’s more about which construct is more cohesive in the context of your business logic and your application.

Upvotes: 2

Ganesh Ghag
Ganesh Ghag

Reputation: 169

Injecting one service into another using spring like you have mentioned will couple, the 2 services only to the extent of the interface used.

If you need more decoupling, think of using a message to pass between the 2 services.

Message can be strongly typed like a value object/xml with schema or weakly typed like a HashMap

While weakly typed messages can increase the decoupling, it means you and your client will forfeit compile time checking and debugging issues will be cumbersome at runtime

Upvotes: 0

Alex
Alex

Reputation: 25613

For me, there's no problem to inject a service into another one. That's the point with services and SOA as you said.

Services can help each others in order to give you the final result. Besides, as told JB Nizet, if there is no cyclic dependencies, no problem.

Upvotes: 1

tozka
tozka

Reputation: 3451

What you are describing is called Mediator Pattern.

Btw what is SOA?

Upvotes: 0

Related Questions