Как лучше всего обрабатывать сообщения журнала с использованием функционального способа

Я новичок в программировании на Scala. Теперь я озадачен тем, как объявить метод biz асинхронным и функциональным способом, что реализация метода должна включать много сообщений журнала. В качестве плохой практики я пишу код следующим образом:

// trait
trait StoreService {
    def create[Config]: Kleisli[Future, Config, Store]
}

// and the interpreter
trait StoreServiceInterpreter extends StoreService {
    def create[Config]: Kleisli[Future, Config, Store] = Kleisli {cfg => 
        // some implementation ...
        log.info("bla bla bla ...")
        // some implementation ...
        // return a store
        Store(...)
    }
}

Это плохо, потому что реализация имеет побочный эффект, запишите что-нибудь на место. Итак, я изменяю объявление метода следующим образом:

// trait
trait StoreService {
    def create[Config]: Kleisli[Future, Config, Writer[Vector[String], Store]]
}

// and the interpreter
trait StoreServiceInterpreter extends StoreService {
    def create[Config]: Kleisli[Future, Config, Writer[Vector[String], Store]] = Kleisli {cfg => 
        // some implementation ...
        // log.info("bla bla bla ...")
        // some implementation ...
        // return a store
        Writer(Vector("bla bla bla...", Store(...))
    }
}

С помощью Writer побочка устранена, но код не ясен:

  • Почему писатель вернулся? Writer[Vector[String], Store] имеет больше шума, чем Store, есть ли способ избежать шаблонного кода и остаться без побочных эффектов?
  • Пишите log не ad-hoc! Я должен построить вектор String для хранения сообщения, используя операцию :+ или ++ для добавления журнала. Я думаю, что это не специальное ведение журнала, как и запись log.info(...) где угодно.

scala functional-programming pure-function
person Zenhue Song    schedule 12.06.2017    source источник
comment
Лично я считаю, что логи не имеют значения для корректности моей программы. Поэтому я предпочитаю не моделировать их побочные эффекты в своем коде. Я приветствую ваше отношение к чистому FP и с нетерпением жду ответа.   -  person Stephen    schedule 12.06.2017
comment
Да, может быть, это может быть более чистым   -  person Zenhue Song    schedule 12.06.2017

Ответы (1)


arrow_upward
1
arrow_downward

Большинство известных мне разработчиков Scala для удобства считают ведение журнала «не побочным эффектом». Однако, если вы действительно хотите отслеживать их, вы можете взглянуть на концепцию «свободной монады». Дополнительная информация: общее описание, пример с логированием.

Мое грубое объяснение: «давайте смоделируем нашу программу как некоторый AST и интерпретируем ее». Итак, в AST вы определяете понятие «логирование», а не реализацию, которая приходит позже, в интерпретации. Этот подход позволяет вам следить за ведением журнала и изменять действие (от записи в /dev/null до асинхронной отправки во внешнюю службу), не затрагивая «деловую» часть вашего кода.

person dveim    schedule 12.06.2017
comment
Большое спасибо! › давайте смоделируем нашу программу как некоторый AST и интерпретируем ее. Очень хорошо! возможно, мне следует добавить свойство для конфигурации с именем log. И монада Free - лучший выбор, если с pure-fp. - person Zenhue Song; 12.06.2017