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.

  • 1
    Possible duplicate of Choosing the right Design Pattern
    – gnat
    Commented Feb 27, 2017 at 17:48
  • destroyallsoftware.com/talks/boundaries Commented Feb 27, 2017 at 18:08
  • 1
    Please edit your title to describe your situation specifically rather than requiring people to open the page to find out whether they have an answer to contribute.
    – jscs
    Commented Feb 27, 2017 at 18:14
  • "want", "may" -- these are not good reasons for increasing complexity by introducing loose coupling. You may be over-engineering. Commented Feb 27, 2017 at 19:06
  • I can say that I need loose coupling between the objects, I didn't notice this until after I coded all the pieces and started connecting them together in one class.
    – Grim
    Commented Feb 27, 2017 at 21:35

2 Answers 2


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.

  • After further research, the strategy pattern would be ideal as I can hide the implementation details of each service. I was almost doing this already except for the fact that I wasn't hiding the implementation details of each service through an interface.
    – Grim
    Commented Feb 27, 2017 at 22:46
  • you mentioned a different playbook, do you have a good resource for almost all of the design patterns used? The reason why I am asking is because I have never heard of the service locator pattern and I like to know as much as I can. I wonder what else I don't know :)
    – Grim
    Commented Feb 28, 2017 at 2:04
  • grimlek, please see this page - particularly the grid at the very bottom: en.wikipedia.org/wiki/Software_design_pattern Commented Mar 1, 2017 at 15:24

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.