I'm wondering if you would use the mediator pattern on the following scenario.

First of at all, the program must call an API, and persist this response on somewhere (it could be a database, a file, on a blog storage, and so on).

I see two responsibilities involved here:

  1. pull data from the API, and
  2. place it in some storage.

There would be a class per each responsibility (trying to following Single Responsibility Principle); and both classes must not interact directly (API's client class must don't know that their response are being persisted, and the Persistence class must don't know that the models/entities persisted are coming from an API). So here's where a mediator should come: the mediator should orchestrate the interaction between two classes's instances, and accomplish the program's purpose.

I'm trying to increase the classes cohesion the most I can, and also ensuring that I got a low coupling between both classes (responsibilities actually). By doing this, I can change to whatever API I want, and also persist on somewhere I want.

So question: do you think guys I can achieve this by implementing the mediator pattern? Or is there a better approach for achieve this? I'm totally open to any suggestion!!

  • The Single Responsibility Principle doesn't mean what you think it means. When you're working with software patterns and design principles, think about what benefits they provide to your application, not whether you're conforming to some rule. Commented May 3, 2019 at 14:36

2 Answers 2


By loose interpretation, your application is the mediator. Essentially, you just need to encapsulate access to the service, and you need to encapsulate access to storage. Your application invokes the service and interprets the results, placing data in the storage component. So, adding a special class for the mediation might be overkill since your application already has that role. It doesn't hurt though.

The main advantage I can see of creating a mediator class, is for unit testing:

  • You create the interfaces for calling the service and storing data
  • You create the mediator that consumes those interfaces
  • You write tests to mock those endpoints and verify that the data is prepared properly

The whole interchange is now testable in an isolated manner without actually calling the external service and storage parts.


I don't think you should use the Mediator pattern here. The Mediator pattern requires objects to delegate their interaction to the mediator. However, both classes that call the API and do the persistent don't have any reference to the mediator in your use case. There is no way the API class and the persistent class can call the mediator without any reference to it.

I suggest using the Bridge pattern like this:

enter image description here

Using this pattern:

  • you can add more persistent mechanism by implementing the DataPersister interface.
  • you can support more API by extending the AbstractApiFetcher abstract class.
  • your API classes only know the DataPersister interface. They don't know anything about how these interfaces are implemented (local file, database, ...).

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.