Как стать автором
Обновить

Аналитика в декларативном стиле с поддержкой многомодульности

Время на прочтение14 мин
Количество просмотров2.9K
Всего голосов 6: ↑6 и ↓0+6
Комментарии4

Комментарии 4

Спасибо за статью. Можете, пожалуйста, сказать какие преимущества вы видите для себя от использования dsl тут вместо более простых в реализации и надёжных в плане контроля за обязательными параметрами фабрик? Также в фабриках остается возможность задать дефолтные значения для аргументов.

Если отбросить из описанных мной в статье плюсов те, что можно реализовать в других подходах, то, пожалуй, мой любимый - то, как выглядит и читается всё это на Pull Request'ах. Даже при беглом взгляде считывается структура и значения.

По поводу дефолтных значений для аргументов - в таком походе их тоже можно задать. Просто у нас в проекте их нет, поэтому я как-то забыл про них написать.

Если честно, не понял как будет в итоге выглядеть исходный класс, который у вас назван OldAnalytics, в декларативном стиле

Получится примерно так

internal class SomeEventBuilder(
   private val userId: Int,
   private val itemsIds: List<Int>,
   private val timestampProvider: () -> Long
) : EventBuilder {

   override fun buildEvent() = event {
       analytics1 {
           eventName = "SomeEventName"
           reason = "SomeReason"
           action = CommonAnalyticsAction.CLICK
           source {
               feature = Feature1AnalyticsFeature.FEATURE_1
               screen = Feature1AnalyticsScreen.FEATURE_1_SCREEN
               block = customBlock("SomeBlock")
           }
       }
       analytics2 {
           eventName = "SomeName"
           source = "SomeBlockOfUser$userId"
           action = customAction("Click")
           screen = Feature1AnalyticsScreen.FEATURE_1_SCREEN
       }
   }
}

Зарегистрируйтесь на Хабре, чтобы оставить комментарий