Which design pattern should I use for making 3 objects loosely coupled and encapsulated?

Question

I have tried looking at various design patterns to solve a problem that I am having. I want three objects to be loosely coupled and encapsulated.

• Object 1: Spring Data Repository:

  An object for exposing the persistence layer.

• Object 2: Rest Template Service Object:

  An object that performs actions on a REST API and contains various methods for the different End points. The JSON is deserialized to a Order class specifically tailored to this response.

• Object 3: Rest Template Service Object:

  A different object than object 2 performing actions on a different REST API. The JSON is serialized to a Order class specifically tailored to this response.

The issue I am having is that I want to be able to have the three objects loosely coupled and make it easier to add new rest template service objects or change the specified repository. Later I may add authorization such as, you can't use this service object but you can use service objects 3, 4 or 5. Currently I have an object now that acts as the middle man for service object 1 and service object 2. The middle man object contains an instance variable for the repository object. Currently the middle man object is tightly coupled to all three objects. What is the best approach to make these three objects loosely coupled? I looked at the mediator pattern but I am not sure if that is the best approach. I am practicing design patterns and stumbled across this problem.

A little more about the problem domain. The data stored locally are orders generated. The service objects are REST End points that need notification of the new order. This is just one of the end points but others would be cancel line item for order X. So when the new order is created, the database is updated with the new order. At a certain time of the day the new order is created at the various REST End points using the service objects.

If any additional information is needed I will be more than glad to include it. I am practicing design patterns and I came across this problem, so I am by no means an expert.

Answer 1

I think the sibling "Strategy Pattern" is slightly closer. Mediator is more about allowing loosely-coupled objects to talk to each other through the Mediator. Strategy is more about choosing the right loosely-coupled object to fulfill the request.

In a different playbook of patterns, there is the "Service Locator" pattern, which also seems to fit.

In practice, you would typically create a service interface, and concrete services adhering to the interface. You could leverage a DI Container as the Service Locator.

Answer 2

At first sight it looks to be a good case for using the mediator pattern.

In this pattern, a mediator manages interaction between colleague objects (which could be your repository and the different rest templates). One of the big advantage is that this replaces complex many to many interactions with a couple of one to many interactions, while at the same time decoupling the colleagues.