Which design pattern to choose when supporting multiple analytic tools?

Question

I have spent quite some time learning all possible design patterns but I cannot find the ideal one for the following case. I am developing an iOS app where we are using multiple analytics tools like Google Analytics/Facebook Analytics and it is possible that in the future we will add some more (our company is obsessed with measuring :D).

Each of them uses their custom SDK to log an event which comes with its own method to send an event and its own parameters. I would love to refactor it and create a module where adding new analytics tool wouldn't lead to code smell and in best case scenario there would be a central place which would dispatch the events at once.

I was thinking about this:

1. Defining a protocol AnalyticsProtocol which requires implementation of sendEvent method
2. Defining AnalyticsEvent class for every tool (FacebookAnalyticsEvent, GoogleAnalyticsEvent) which conforms to the protocol above and implements sendEvent method. Each of these classes would have its own init method.
3. Cental dispatch class which takes an array of id<AnalyticsProtocol> objects and calls sendEvent on every single one of them.

Do you have any better ideas? Thanks.

Answer 1

Is it important for you to own the solution to this problem? It sounds like what you need is already available from third parties (I've used https://segment.com/).

Since you asked for a software design pattern; the Strategy pattern might serve you well. You could define a common interface for reporting events and implement a strategy for each of your analytics services. You could also create an aggregate strategy which conforms to the same interface and forwards an event to several other strategies when you are using many analytics services at once.

Answer 2

Each of them uses their custom SDK to log an event which comes with its own method to send an event and its own parameters. I would love to refactor it and create a module where adding new analytics tool wouldn't lead to code smell and in best case scenario there would be a central place which would dispatch the events at once.

---

This feels like the adapter pattern:

Intent

• Convert the interface of a class into another interface clients expect.

• Adapter lets classes work together, that could not otherwise because of incompatible interfaces.

And from the same link:

Adapter Pattern and Strategy Pattern

Adapter Pattern and Strategy Pattern - there are many cases when the adapter can play the role of the Strategy Pattern. If we have several modules implementing the same functionality and we wrote adapters for them, the adapters are implementing the same interface. We can simply replace the adapters objects at run time because they implements the same interface.