1

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.

  • Would these protocols be used anywhere outside the "central dispatch class"? I'm not that familiar with Analytics SDKs, but it sounds like in your "real code" you could simply write allTheAnalytics.sendEvent() and implement that one method using all of the concrete SDK classes. Or do you expect to use different combinations of Analytics SDKs for different programs and are looking for an easy way to construct all of those combinations? – Ixrec Jan 7 '16 at 19:20
  • These protocols would be used just within "central dispatch class". As you mentioned I am looking for an easy way to construct all of those combinations. I would like to create let's say submodule which will define some rules for new Analytics tool and it will be flexible with adding/removing these tools. To be more precise you can imagine I want to construct something like logger - you log messages just with one logger but this logger can handle output to multiple different places (stdout, file and network at once). – skornos Jan 7 '16 at 19:38
3

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.

  • thanks for the response Jonah. Yes, custom solution is needed. I will take a look at the Strategy pattern and let you know. – skornos Jan 7 '16 at 20:30
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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